在游戏开发中，我们经常会遇到一些技术难题，而其引发的bug则会影响整个游戏的品质

过载保护、集群、服务器通信、并发选型等方面的问题，是中小团队常常的技术难题，本文分享了一些专家在坐镇过程中提到的解决方法，希望对大家有所帮助

问题一：玩家登录时拉取好友信息，但好友服务繁忙导致登录失败。

解决方法：

1、分离关键路径上非关键调用，缩短事务流程，避免周边服务异常阻塞登录

2、服务熔断机制，超出处理能力快速失败，防止雪崩

3、按用户隔离事务，避兔单个用户请求阻塞影响到其他用户

问题二：压测并发登录对redis产生很大压力。

解决方法：redis数据表数量多，一次事务会产生多个 redis请求，小表合并为大表

Wade：服务器进程的管理一般比较简单，有很多还是用配置文件静态组织的。同时往往进程间通信的手段比较缺乏，没有使用消息队列中间件，甚至还有用 Redis 来做通信组件使用的。为了提高集群管理的自动化水平，使用 ZooKeeper 是一个比较常见的方法。

Zc：redis一般做为内存缓存来使用,不宜将关键数据存放在redis中.其数据安全性并不如一般的DB。在使用过程中也需要参考性能基线，控制访问频率和流量。

问题三：外部服务有延迟，调用到的业务流程中产生卡顿。

解决方法：业务侧增加缓存:同玩好友msdk+最近角色id+角色信息

Wade：很多团队对于过载保护不够重视，往往只在最外层接入客户端一侧有最大连接数或者最大会话数的限制。而对于内部的多个进程，比如访问数据库的进程，就没有太多的负载保护。由于游戏是带状态的进程比较多，所以负载均衡往往也做的不多，基本上是按状态所在进程去转发处理请求

Zc：注意缓存和降级处理。外部平台数据，尽量缓存，提高访问体验。当发现外部服务出现故障，或本身出现负载风险时，应降级服务

Jovi：msdk midas平台特权等api接入工作，游戏业务可以建立一个隔离层专门处理这块需求，避兔过分侵入游戏逻辑，更容易控制。

问题四：运营和客服接口修改玩家数据，会与正常游戏的数据回写产生竞争。

解决方法：使用类似邮件机制去修改数据。

Zc：多线程开发中，经常会有线程池用尽或线程死锁导致服务质量下降。建议将线程池根据业务需求合理分类，不同业务间有合理的负载配比，不会相互影响。非关键流程需要延后或者异步化处理，避免卡死关键流程。

同时，合理的线程模型可以有效减少线程间竞争。对确实需要竞争的资源在流程入口处统一有序加锁，避免在逻辑过程中，随意嵌套取锁竞争。并且，给锁加个超时时间，避免业务中断。

游戏服务器端架构中的调度架构，方便大家理解。

a) 单进程游戏服务器

最简单的游戏服务器只有一个进程，是一个单点。这个进程如果退出，则整个游戏世界消失。在此进程中，由于需要处理并发的客户端的数据包，因此产生了多种选择方法：

同步-动态多线程

每接收一个用户会话，就建立一个线程。这个用户会话往往就是由客户端的TCP连接来代表，这样每次从易云网络中调用读取或写出数据包的时候，都可以使用阻塞模式，编码直观而简单。有多少个游戏客户端的连接，就有多少个线程。但是这个方案也有很明显的缺点，就是服务器容易产生大量的线程，这对于内存占用不好控制，同时线程切换也会造成CPU的性能损失。更重要的多线程下对同一块数据的读写，需要处理锁的问题，这可能让代码变的非常复杂，造成各种死锁的BUG，影响服务器的稳定性。