问题一：玩家登录时拉好友信息，但好友服务繁忙导致登录失败。
解决方法:
1.分离关键路径上的非关键调用，缩短事务流程，避免外围服务异常阻塞登录。
2.服务保险丝机制会在超出处理能力的情况下迅速失效，以防止雪崩。
3.根据用户隔离事务，避免阻塞单个用户的请求，影响其他用户。
问题二：试压并发登录给redis带来很大压力。
解决方案:有大量redis数据表，一个事务会产生多个redis请求，小表会合并成大表。
服务器进程的管理一般比较简单，很多都是通过配置文件静态组织的。同时往往缺乏进程间通信的手段，不使用消息队列中间件，甚至使用Redis作为通信组件。为了提高集群管理的自动化水平，ZooKeeper是一种常用的方法。
redis一般用作内存缓存，不适合在redis中存储关键数据。它的数据安全性不如一般的DB。在使用中，还需要参考性能基线来控制访问频率和流量。
问题三：外部服务延迟，被叫业务流程卡死。
解决方案:业务端加缓存:玩好友msdk+最近角色id+角色信息。
梦飞：许多团队对过载保护不够重视，往往只限制最外层访问客户端的最大连接数或会话数。但是对于许多内部进程，例如访问数据库的进程，没有太多的负载保护。因为游戏中有很多带状态的进程，负载均衡往往做的不多，基本上处理请求都是按照状态所在的进程来转发的。
注意缓存和降级处理。应尽可能多地缓存外部平台数据，以改善访问体验。当发现外部服务失败或存在负载风险时，应降级服务。
msdk midas平台权限等api访问工作，游戏业务可以建立一个隔离层专门处理这个需求，避免对游戏逻辑的过度入侵，更容易控制。
问题四：操作和客服界面对玩家数据的修改会和正常游戏的数据更新产生竞争。
解决方案：使用类似邮件的机制来修改数据。
多线程开发中，经常会出现线程池耗尽或线程死锁，导致服务质量下降。建议根据业务需求合理划分线程池，不同的业务应有合理的负载比例，互不影响。非关键流程需要延迟或异步处理，以避免阻塞关键流程。
同时，合理的线程模型可以有效减少线程间的竞争。真正需要竞争的资源统一有序的锁定在流程入口处，避免了逻辑流程中的随机嵌套和锁定竞争。此外，锁中还添加了一个超时，以避免业务中断。
确保同一时间只有一个数据修改点有助于避免数据竞争。建议设计人员采用CQRS模式，用独立的数据表和服务记录事件，并将其总结为单一的修改服务进行实现。
并发编程是服务器端最常见的问题，一般要么多线程要么非阻塞解决。对于自然支持多线程的语言，如JAVA，许多开发人员倾向于多线程。优点是代码编写简单，但是需要明确锁定各种对象，或者熟练使用java.util.concurrent之类的多线程工具库，如果使用非阻塞的话，优点是不会出现锁定问题，但是代码分为各种回调函数，可读性很差，所以有些团队会使用“协和”或者Promise之类的工具来缓解这个问题，但是这样也引入了更多的复杂性。有不懂的请咨询梦飞服务器了解。
