多線程+同步阻塞模型
在我們的游戲項目中使用的golang服務器開發方式如下
1.多線程邏輯
2.同步阻塞. 也就是說, 每個人一個線程(goroutine), io線程=邏輯線程
這種方式的優點:
1. 同步阻塞方式與人的思維方式類同
2. 邏輯處理性能有一定提升
在大規模使用這種模式編寫邏輯后, 我們發現了這種模式只有1個缺點: 編寫者需要處理多線程關系
但這本身確實直接致命的, 回想C++時代, 多線程處理時, 調試重現的困難… 腦補景象太慘不敢直視
單線程+異步多進程模型
在C++時代, 我曾經編寫過一套asio的C++服務器框架. 采用io多線程, 邏輯單線程, 依賴著C++高性能的優勢, 讓開發便捷簡單且無需關心線程問題.
那么到了golang時代, 為什么不能試下單線程異步多進程方式來編寫邏輯?
與多線程同步阻塞對比后, 我們發現, 兩者優缺點互補. 那這就回到了領域選型問題了. 對于游戲服務器需要的上手簡單, 開發便捷, 壓力降低(非MMO)這些特點來說, 單線程異步多進程再合適不過了
那么, 我們在用golang編寫單線程異步多進程服務器應該注意哪些點呢?
1. socket處理完全封裝, 只通過channel拋出到邏輯線程排隊處理
2. 數據庫, rpc及其他io處理, 一律改為異步回調模式, 不使用同步接口
3. 玩家存盤提交數據可以考慮復制并提交到存盤線程方式, 提高性能.
4. 采用多進程架構, 比如設網關進程, 把io壓力分散到進程中
5. 邏輯編寫中, 不允許使用go開線程及channel, 有需要提高性能部分需要單獨編寫
Actor模型的痛
cellnet在開發時本來考慮使用actor模型來進一步簡化多線程邏輯的麻煩, 經歷了一段時間的原型開發后, 發現了一些問題, 列舉如下:
1. golang的強類型不適合actor模型這種經常需要動態生成各類消息的模型, 但skynet(C+lua)/erlang就有天生優勢
2. actor模型本身不是萬能的, 不能解決所有需求, 特別是游戲
3. actor模型理解到應用有一定的難度. 本身還需要搭建框架, 上手復雜
總之, 看過一些erlang及skynet的用例, 沒有應用的很純正且成熟的成功actor模型案例, 從傳統socket服務器框架跨越到actor模型會扯到蛋, 因此, 后期cellnet會考慮回歸到成熟的socket服務器框架. 把架構做到簡單上手, 高擴展上.