多執行緒+同步阻塞模型

在我們的遊戲專案中使用的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伺服器框架. 把架構做到簡單上手, 高擴充套件上.