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