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

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

問題描述:

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

查問題過程:

經過對作業記錄的分析,程式執行到給用戶端socket寫資料的時候會一直卡住,然後報錯,具體錯誤已忘記, 大概是寫逾時之類的.

百度查詢,認為是, 服務端在給一個已經關閉的socket寫資料才導致的錯誤, 而這個"關閉"在服務端其實認為沒有關閉的. 是用戶端主動發起了close的請求, 但是服務端沒有正確處理該請求, 導致服務端一直認為該socket是正常,直到逾時.

那麼架構設計是這樣的: 一個玩家的操作會同步給其它玩家,這時是直接給其它玩家的socket發送資料, 此時如果有一個玩家用戶端寫逾時了, 那麼其後所有的玩家都會在等待該異常的寫逾時. 導致全服都卡住了. 即一個玩家的socket異常導致所有玩家的異常.

問題產生原因: 對socket機制瞭解應用不夠徹底. 架構設計不合理.不能因為一個玩家的異常導致全服卡住.

解決過程:

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

架構設計為: 如果要給每個玩家發送資料, 那麼則由該玩家的socket自行負責資料通訊, 因為每個玩家的socket處理都是一個 go程, 如果一個玩家卡住, 那麼也只是卡住該玩家,將損失減少到最小.

由此,可以總結出架構設計時. 每個玩家都是只處理自己的問題,如果有影響到其它玩家的資料, 那麼也只能是交給所影響的玩家自行處理資料.