問題一：玩家登錄時拉好友信息，但好友服務繁忙導致登錄失敗。
解決方法:
1.分離關鍵路徑上的非關鍵調用，縮短事務流程，避免外圍服務異常阻塞登錄。
2.服務保險絲機制會在超出處理能力的情況下迅速失效，以防止雪崩。
3.根據用戶隔離事務，避免阻塞單個用戶的請求，影響其他用戶。
問題二：試壓并發登錄給redis帶來很大壓力。
解決方案:有大量redis數據表，一個事務會產生多個redis請求，小表會合并成大表。
服務器進程的管理一般比較簡單，很多都是通過配置文件靜態組織的。同時往往缺乏進程間通信的手段，不使用消息隊列中間件，甚至使用Redis作為通信組件。為了提高集群管理的自動化水平，ZooKeeper是一種常用的方法。
redis一般用作內存緩存，不適合在redis中存儲關鍵數據。它的數據安全性不如一般的DB。在使用中，還需要參考性能基線來控制訪問頻率和流量。
問題三：外部服務延遲，被叫業務流程卡死。
解決方案:業務端加緩存:玩好友msdk+最近角色id+角色信息。
夢飛：許多團隊對過載保護不夠重視，往往只限制最外層訪問客戶端的最大連接數或會話數。但是對于許多內部進程，例如訪問數據庫的進程，沒有太多的負載保護。因為游戲中有很多帶狀態的進程，負載均衡往往做的不多，基本上處理請求都是按照狀態所在的進程來轉發的。
注意緩存和降級處理。應盡可能多地緩存外部平臺數據，以改善訪問體驗。當發現外部服務失敗或存在負載風險時，應降級服務。
msdk midas平臺權限等api訪問工作，游戲業務可以建立一個隔離層專門處理這個需求，避免對游戲邏輯的過度入侵，更容易控制。
問題四：操作和客服界面對玩家數據的修改會和正常游戲的數據更新產生競爭。
解決方案：使用類似郵件的機制來修改數據。
多線程開發中，經常會出現線程池耗盡或線程死鎖，導致服務質量下降。建議根據業務需求合理劃分線程池，不同的業務應有合理的負載比例，互不影響。非關鍵流程需要延遲或異步處理，以避免阻塞關鍵流程。
同時，合理的線程模型可以有效減少線程間的競爭。真正需要競爭的資源統一有序的鎖定在流程入口處，避免了邏輯流程中的隨機嵌套和鎖定競爭。此外，鎖中還添加了一個超時，以避免業務中斷。
確保同一時間只有一個數據修改點有助于避免數據競爭。建議設計人員采用CQRS模式，用獨立的數據表和服務記錄事件，并將其總結為單一的修改服務進行實現。
并發編程是服務器端最常見的問題，一般要么多線程要么非阻塞解決。對于自然支持多線程的語言，如JAVA，許多開發人員傾向于多線程。優點是代碼編寫簡單，但是需要明確鎖定各種對象，或者熟練使用java.util.concurrent之類的多線程工具庫，如果使用非阻塞的話，優點是不會出現鎖定問題，但是代碼分為各種回調函數，可讀性很差，所以有些團隊會使用“協和”或者Promise之類的工具來緩解這個問題，但是這樣也引入了更多的復雜性。有不懂的請咨詢夢飛服務器了解。
