多線程+同步阻塞模型

在我們的游戲項目中使用的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ò)展上.