by Daly
網游服務器程序優化要解決的最主要矛盾無非就是在保證流暢游戲體驗(響應時間在可接受范圍)的前提下，容納更多的玩家，當然還要保證開發的便捷性。一個靠譜的MMOG游戲服務器基本上都是多線程或多進程的架構， 利用多個CPU核把串行處理變成并行處理，以容納更大的并發玩家規模。
然而并行處理程序會使開發的復雜度增加，一不小心很容易出一些詭異bug。為什么這樣說呢？實際環境的大部分程序，函數的執行結果與狀態數據相關(外部狀態，全局數據)，并且函數執行可能會改變這些狀態。如果把處理模塊拆成多進程，進程間的這些狀態數據的一致性和處理時序，會影響到結果的正確性。多進程狀態數據的管理，讀寫和同步更新機制，便是本文要探討的主要問題。
如果函數能變成無狀態的(結果只與輸入參數相關)，則分拆成多進程毫無壓力。于是業界開始探討erlang這種函數式編程語言，并有已有實際游戲項目（參看:http://www.qingliangcn.com/) 。不過筆者覺得，erlang的無狀態，本質上是把狀態數據通過函數參數傳遞，這樣意味著頻繁而大量的數據復制和傳遞，是否更適合于MMORPG開發很難說，本文不予討論，可見文章末尾參考資料。下面探討一下狀態數據在多進程之間的問題。
為了容易描述，整個架構如下圖
G
client <--->║ <------> A
║ <------> B
其中G表示接入網關，負責把client協議分發到內網對應處理進程，A,B是負責不同功能的處理進程，client表示客戶端，玩家狀態數據只有個v和w兩個。用reqA,reqB分別表示client對A, B的處理請求，respA, respB表示A,B返回給client的處理結果。
游戲邏輯大部分情況下需要保證狀態數據的強一致性，基于過期的數據進行處理會得到錯誤的結果（分布式數據一致性的工程問題見文末的參考資料）。舉個有點蹩腳的例子，假設client先后發出reqA, reqB兩個請求，reqA是換武器，reqB是發起攻擊，變量v是攻擊輸出量（dps）。reqB在reqA之后發出，攻擊理應是按穿上武器后的dps數值來計算的。但多進程情況下，卻有可能reqB先于reqA處理（比如A進程很忙），這時reqB的邏輯會基于還沒穿上裝備時的變量v來計算結果。下面分別討論幾種解決數據一致性問題的方案。
模式一：共享內存
適合于單機多進程或多線程的模式。
優點：數據只有一份，可以保證強一致性。
缺點：進程無法擴展到多臺服務器；
需要加鎖，加鎖相當于把處理串行化，還是有可能被某一個較忙的進程卡住。如果精心設計和劃分數據，減少鎖的粒度可以提高性能，但細粒度的鎖（設計成類似MySQL的行級鎖），在涉及多個玩家數據的交互邏輯時，稍有不慎又容易導致死鎖。隨手寫一個：
假設進程A和B同樣執行以下類似的邏輯
foreach( user in mapA) {
lock(user);
lock(user‘s friend);
do_something();
unlock(user's friend);
unlock(user_id);
}
由于遍歷的是map, 進程A和B中的user順序有可能交叉, 假設交叉的兩個user互為friend，就可能死鎖了。
參考資料[4]采用了這種模式的方案。
模式二：狀態數據只由一個進程管理
把狀態數據根據游戲邏輯進行劃分，比如變量v只由A讀寫, 變量w只由B讀寫。假如A邏輯需要用到w，則通過異步請求B獲取w。
優點：保證強一致性；數據只有一份，無需進程間復制更新。
缺點：異步請求增加了響應時間(嗯，又從并行變成了串行); 異步寫起來的代碼有點ugly，到處是callback, 回來要檢查上下文，不然又是詭異bug.
適用范圍：如果狀態數據能比較好的劃分（即絕大多數情況下，某個數據只會在某個進程的邏輯中用到），用這種方案比較適合，因為簡單。比如玩家位置只由AOI進程管理，玩家好友由聊天進程管理。
模式三：多個writer, 類似MVCC方案
這是完全的分布式設計。每個進程有自己版本的狀態數據，進程間可互相同步更新, 狀態數據v分別在A,B都有一份?；ハ鄒pdate時，根據版本信息進行merge。
這種方案不能保證強一致性，而且merge時會有可能發生沖突，需要邏輯開發者仲裁這種沖突（比如按時間先后）。不同于互聯網應用，游戲需要較強的數據一致性和實時性，這種方案比較復雜且不太可控。
模式四：Master-Slave模式
這個是對模式二的一個擴展，某個狀態數據還是只由一個進程進行寫操作，但其他進程會維持一份cache進行讀操作，比如變量v由進程A管理，v的更新會同步到進程B，進程B邏輯如果要用到v,直接讀自己的cache就可以了。對于變量v
特點：這種方式也是不能保證強一致性，只能保證最終一致性。作為模式二的補充，有些數據不需要保證更新時序，根據過期數據進行處理也可以接受(這個是代價，需要權衡玩家體驗），可以采取這種方式。而對于不能接受的，走模式二。某些需求reqA，reqB雖然先后發出，如果respA還沒反饋回來的話，即使邏輯上reqB先于reqA處理，在玩家體驗上也是可以接受的。比如reqA穿裝備, 然后reqB攻擊，但是respA還沒返回，客戶端還是看作是沒穿上裝備，這時候按照老的屬性計算攻擊值是可接受的。廣域網幾百毫秒的延遲，reqB要晚于reqA + respA這種概率很小了，如果真的發生，服務器已經很卡了。
又比如聊天進程，reqA離開場景，然后reqB發聊天消息往當前場景頻道，需要知道當前場景的玩家列表(假設場景玩家列表在AOI進程管理)，如果reqB先到達聊天進程,拿到舊的場景玩家列表, 那么這個廣播就不準確了。這種不一致性的代價可以忍受的話就沒問題(在這個聊天欄例子，在跳場景的瞬間發錯人了也可以忍），實際情況，進程間通信幾個毫秒，發生這種處理時序反轉的幾率其實非常小了。
綜上，如果要設計多進程結構，個人比較推崇模式四。這時又引申出幾個問題：狀態數據如何合理劃分？何時更新？同步給誰？
如何劃分？
有些功能很好劃分。比如聊天進程，狀態數據只與好友列表有關，這個需求可以忍受過期數據，好友關系由主進程修改，同步到聊天進程。玩家position, 由AOI進程管理，修改同步到主進程，主進程幾乎沒有需要用到position的邏輯。
但有些數據就可能很糾結，比如背包數據。玩家交易，在線獎勵，戰斗都需要修改背包物品數據，而且必須保證強一致性，否則就可能出現丟失或物品復制，該由誰做這個數據的管理者呢？如果AOI進程管理，物品使用效果可以馬上生效，但是交易和在線獎勵也需要驗證背包物品，這些邏輯也放到AOI進程么，如果放，則又牽扯出更多的變量，如果不放，則需要退化成模式2的異步請求。如果放主進程，則使用物品后產生的效果不能立刻同步到AOI進程?？梢越涍^仔細對比，AOI與背包數據交互的頻率遠高于主進程，于是背包數據可由AOI進程管理。
何時更新？
兩種選擇：一有修改立馬發送更新給其他進程；隊列buffer住所有更新，定時送出去（比如每2秒同步一次）；既然是無法保證強一致性，后者性能容易優化些。比如AOI進程中的位置信息變化很頻繁，但主進程對位置實時性不敏感（比如只用于持久化，掉線重上后的位置恢復），則更新間隔可以長一些，否則會有頻繁而大量的位置數據更新；定時更新也利于同步間隔內數據修改的合并，減少同步量。
同步給誰？
某類數據有修改時，需要通知哪些進程，意味著要維持一個映射表?？梢栽诰幋a階段，在數據定義時靜態寫死某類數據要通知哪一類功能進程； 也可以在運行期設計成pub-sub模式(或者叫observer模式), 動態增刪訂閱者。筆者覺得前者可控一點，因為進程要用到哪些數據，在編碼階段是可以清楚規劃的，根據這個原則把數據劃分成一個個模塊，比如玩家數據分為基本角色屬性，avatar, 位置/朝向, 好友數據.... 然后決定歸屬。
多進程可以提升系統并發規模，但同時有各種異步調用和數據一致性問題，帶來的代價就是bug的風險增加(尤其團隊水平不能保證個個都很高的情況下，一個菜鳥程序員就夠受了，還很難跟蹤），開發難度增大。這個需要仔細profile和實驗確定瓶頸在哪，真的跑滿CPU或者卡IO才有必要分出去，想當然的把模塊拆分很多進程，設計看上去很優雅也很牛逼，往往是麻煩的開始 ——> 開發效率降低，出bug意味著啥？加班，加班，深夜運維的奪命追魂call... ...
參考資料