golang服務端, 遊戲公測時遇到的socket寫超時的問題, 也是遊戲框架的設計問題

問題描述:

遊戲公測,玩家大概有幾百個.運行一小段時間,大概是20分鐘左右或最多半個小時,服務端就卡住了. 卡住較長時間,以後又會變正常一小會兒

查問題過程:

通過對運行日誌的分析,程序執行到給客戶端socket寫數據的時候會一直卡住,而後報錯,具體錯誤已忘記, 大概是寫超時之類的.

百度查詢,認爲是, 服務端在給一個已經關閉的socket寫數據才致使的錯誤, 而這個"關閉"在服務端其實認爲沒有關閉的. 是客戶端主動發起了close的請求, 可是服務端沒有正確處理該請求, 致使服務端一直認爲該socket是正常,直到超時.

那麼框架設計是這樣的: 一個玩家的操做會同步給其它玩家,這時是直接給其它玩家的socket發送數據, 此時若是有一個玩家客戶端寫超時了, 那麼其後全部的玩家都會在等待該異常的寫超時. 致使全服都卡住了. 即一個玩家的socket異常致使全部玩家的異常.

問題產生緣由: 對socket機制瞭解應用不夠完全. 框架設計不合理.不能由於一個玩家的異常致使全服卡住.

解決過程:

socket機制問題暫時不處理. 應該是socket異常則直接斷開連接, 不進行重連之類的處理.雖然客戶體驗不夠友好.

框架設計爲: 若是要給每一個玩家發送數據, 那麼則由該玩家的socket自行負責數據通訊, 由於每一個玩家的socket處理都是一個 go程, 若是一個玩家卡住, 那麼也只是卡住該玩家,將損失減小到最小.

由此,能夠總結出框架設計時. 每一個玩家都是隻處理本身的問題,若是有影響到其它玩家的數據, 那麼也只能是交給所影響的玩家自行處理數據.