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