工作小結和聊天系統設計

最近一段時間在做優化，繼續關注線上bug，額外是安全，壓測和容災相關的工作。

先總結下這段時間發現的問題，主要是穩定性和體驗，比較經典。其他同事加了一些功能，但在幾次測試的時候偶現玩家登陸卡住幾秒，後來再登陸就沒有出現這樣的情況。再後來加的一個功能導致登陸必定會卡幾秒鐘，後來問了該同事是配置問題，加上配置後就會跳過。但是這裡並不是配置的根本原因，因為在登陸的時候會同步走網路請求資料，那這塊是有問題的，請求次要資料可以走非同步，讓登陸儘快完成，帶資料回來後再設定，因為網路的不穩定的，這樣修改後就不會再卡，至少不是必現。

本以為找到卡的原因，後來又偶現，還是在登陸時。翻了之前的聊天記錄，檢視相關程式碼在登陸時並沒有同步請求，後來發現第一次登陸可能卡可能不，後來登陸的玩家就不會。在日誌那邊列印log跟蹤，發現在登陸時需要給這個服務傳送非同步訊息，但是該服務並沒有在程式啟動的時候建立，所以建立一個虛擬機器，雖然建立本身耗時，建立初始化的時候，去走網路請求一些資料，那麼就會卡住。第一次會建立，因為是唯一服務，後面就不會卡住。把這塊放到啟動的時候建立並請求會更合適。

還有一個問題同事那邊比較難解決，後來一起排查。從網頁運算元據，比如給玩家傳送元寶，那麼到php這邊後，php封裝請求到遊戲程式，然後處理。出現的問題時，有時候成功有時候返回失敗。後來排除資料格式問題，排除邏輯問題，排除程式負載高的情況。檢視網路連結，發現返回失敗後處於timewait，這個沒問題。然後跟蹤到比較久遠的底層程式碼，有個定時器，設定超時時間是一秒，把這個設定長一些就解決了。

包括還有些設計方案不大合理，平滑處理會更好些。

之前想聊聊遊戲系統中聊天模組和郵件模組實現的要點，系統功能的設計其實不難，關鍵在於細節，設計細節，包括穩定性，效能，儲存等這些。如果沒有相關經驗，設計之初可以不考慮效能和流量消耗，後期可以根據業務需求去優化，這樣經過幾輪迭代後面不管壓測還是安全測試獨立沒什麼問題。

之前壓力測試時，聊天系統出現一些問題。這塊程式碼和設計是沿用上一款遊戲的模組，不是我寫的。雖然後期優化什麼的把這個實現梳理了遍並做了些調整。機器配置就不說了，壓測報告出來時，四千機器人同時線上，一千個人同時發世界廣播訊息，出現了cpu負載很高，且延長較大，持續了幾秒。算了下，一秒傳送400萬訊息，不考慮內容大小和處理邏輯，僅僅轉發，都夠嗆的。之前部落格記錄過一些相關的優化點，這裡還可以再激進些優化。由於skynet框架的特點，如果優化skynet框架其實沒有必要，只能去優化使用者程式碼。

仔細分析這塊邏輯的訊息走向，然後列出瓶頸，一個個攻破，由於是多執行緒，不能因為一個非重要的聊天系統拖累整個系統和使用者體驗，這裡再次優化下。

一般客戶端只能顯示一定數目的訊息，一下子發幾千條大部分沒有必要，大部分都超時，可以做適當的丟棄，這塊還是可以優化下。

以上，可以優化的地方很多，總之是穩定，不卡頓，節省資源和頻寬。這樣設計後，模組清晰，解藕、後面可以針對性優化和替換。