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