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