我不得不承認，我的能力不足以寫出一個100%不會宕機的游戲服務器程序，這也不能全怪我的能力太弱，誰讓咱國內(nèi)網(wǎng)游玩家數(shù)量龐大，哪個游戲剛上線時沒有擠的爆滿過？還有些或是獵奇，或是謀私的個人和組織，在制造著千奇百怪，匪夷所思的數(shù)據(jù)包及操作流程來試探你的服務器。這些都曾是我在服務器宕機后向老板開脫的理由。

 

當WOW終于來到中國時，我一邊欣喜著終于可以在艾澤拉斯的大陸上自由翱翔，一邊卻咒罵著9C的破服務器，動不動就宕機。當然，身為游戲程序設計師的我明知道，這大部分的錯誤都不應歸罪于代理商9C，但是，誰讓blizzard是我心目中的神，誰又讓WOW成為我游戲制作的教科書呢。好吧，我知道上面這段極力追捧blizzard跟WOW的話可能早已讓你惡心連連，不堪入目了，對不起，忘了這一節(jié)，讓我們繼續(xù)。

 

 

服務器宕機后都發(fā)生了些什么？

 

顯然的，宕機后玩家會罵，就像我在玩WOW時那樣，罵游戲公司，罵老板，罵GM。非常抱歉，我們可愛的玩家們似乎并不清楚，這個時候最該罵的其實是我們這些程序員們。長久的遺忘被我們當成了包容，以至于游戲程序員在公司里都養(yǎng)成了趾高氣揚，不可一世的壞毛病：看吧，策劃們，你們做的太爛了，數(shù)值不平衡，玩法沒新意，只會照抄WOW跟大菠蘿，能怪玩家罵你們嗎？運營不得力，買服務器的錢不知道去了哪里，游戲里卡的要死，偶爾辦個活動還沒半點吸引力，能不被玩家罵你是無良運營商嗎？GM們能不天天被罵家指著罵嗎？……呃，又扯遠了。

 

趕緊先把服務器重啟吧。老板正站在你的身后，一臉愁容，雖然暫時還沒有發(fā)作，但看得出來：老板很生氣，后果很嚴重！

玩家們很快又回來了，不得不為玩家們的毅力和執(zhí)著精神而感動，更為自己的錯誤而愧疚，凌晨時分，服務器啟了又宕，宕了又啟，如此反復，可熱情的玩家們依然陪著我在折騰。哦，當年安其拉開門的時候，我也曾這樣折騰過。

這個時候不是你一個人在戰(zhàn)斗。GM們在忙碌地處理著玩家不斷打來的投訴電話：剛買的裝備在宕機后消失了；花光了身上所有材料合成的武器回檔了，但材料卻沒有還給我……數(shù)據(jù)庫維護組的同事們也在緊張的恢復著數(shù)據(jù)，盡可能的將玩家的損失減到最少。

 

真是一件令人沮喪的事。

 

 

真的該試著做點什么了吧！

 

既然我們非常不愿意看到宕機的情況發(fā)生，但又無法100%保證寫出來的服務器程序一定不會出錯，那我們就在當機發(fā)生后的搶救措施上花點功夫，讓玩家的損失不至于太大，也讓我們的維護人員少些壓力吧。

 

一個最簡單也最有效的做法是為每一臺服務器都配備物理冗余，同步更新冗余服務器上的狀態(tài)，當宕機發(fā)生時，立即將處理切換到后備服務器上。只是，物理冗余的代價太大，從成本方面考慮，老板可能不大愿意點頭。

 

既然不能做硬冗余，那就再來考慮軟的吧。

如果只是簡單的啟動冗余進程，其實是換湯不換藥的做法。原來能跑1000人的服務器，由于同時運行了兩個相同的進程，使得CPU和內(nèi)存開銷都翻了倍，結果是只能跑500人了。還是要加服務器。

 

看來只能更深一層，從架構設計上來動手了。

假設我們的游戲世界是由多個獨立場景構成的，那么在實現(xiàn)上我們可以讓這些場景在進程上也獨立，這樣做的好處是可以使得一個場景的宕機不會影響到其他場景的正常運行。如果我們的游戲世界物理上沒有分隔，是一個無縫的大世界，我們也可以人為的將其分成多個獨立區(qū)域，所需要做的額外工作是處理好那些站在區(qū)域邊界附近的對象。事實上，現(xiàn)在的無縫大世界也都是這樣實現(xiàn)的。

 

有了這樣一個前提，我們再來看這個已宕掉的場景該如何處理。

還是老辦法，趕緊先把它拉起來吧。一個具體可行的方案是，由場景管理器，或者你也有可能叫它世界服務器，來監(jiān)視各個場景進程的運行狀態(tài)，當某個場景異常失去聯(lián)系時，由管理器來將其重新啟動。這里需要再花點心思的是，如何讓玩家數(shù)據(jù)正常地發(fā)送到新啟動的場景進程中，而且這個過程對于客戶端來說是透明的。

 

這個方案聽起來似乎不錯，只是，如果宕掉的是場景管理器進程，那該怎么辦呢？

按照前面的描述，場景管理器可以看作是整個游戲世界的中心，它以一個指揮者的身份維護著游戲世界的有序運行，所以它的宕機對整個游戲世界的影響也將會是巨大的。

有沒有什么辦法能夠使得場景管理器進程再次啟動后能夠恢復先前的狀態(tài)呢？

我們可以為管理器和場景進程定義一套協(xié)議，使得管理器不僅能夠創(chuàng)建并恢復一個已有場景，而且場景管理器還能通過現(xiàn)有的場景進程數(shù)據(jù)恢復出自己。

一個理論上可行的方案是，場景管理器與場景進程間保持TCP長連接，并以一定頻率進行心跳聯(lián)系，任意一方發(fā)現(xiàn)聯(lián)系中斷或長時間未收到心跳包后都會立即做出處理。

如果是管理器發(fā)現(xiàn)場景進程失去聯(lián)系，那就啟動新的場景，如前面所描述的那樣。如果是場景進程發(fā)現(xiàn)管理器失去聯(lián)系，那就立即啟動重連過程，直接再次連接上管理器，然后立即將自己當前的狀態(tài)和負責的場景ID報告給管理器。管理器通過這些上報的數(shù)據(jù)就能恢復出游戲世界內(nèi)的場景對應關系表，也就是恢復出了自己原來的狀態(tài)。

 

進程是恢復出來了，可我們忘了最重要的內(nèi)容：數(shù)據(jù)。當場景進程宕機后，上面保存的玩家屬性數(shù)據(jù)也隨之丟失了，雖然我們能夠再次將這個場景創(chuàng)建出來，并把原來在這個場景內(nèi)的客戶端數(shù)據(jù)重新定向過來，但這些客戶端對應的玩家對象的數(shù)據(jù)卻沒有了，游戲仍然無法繼續(xù)。

 

也許我們可以再做一點修改，把場景內(nèi)的玩家數(shù)據(jù)分離出來，保存到一個獨立的進程上，比如，我們可以把這個進程叫做數(shù)據(jù)服務器，或者數(shù)據(jù)中心之類的。一個隱含的要求是，數(shù)據(jù)服務器的邏輯實現(xiàn)非常簡單，簡單到你可以認為它是絕對安全的，不會宕機。所以，保存在這里的玩家數(shù)據(jù)也就是絕對安全的。

 

讓我們在這個問題上稍微再深入一點。

場景進程上每次執(zhí)行玩家的游戲邏輯時都要異步地到數(shù)據(jù)服務器上來存取數(shù)據(jù)，這個開銷可能太大，而且會使得一些游戲邏輯的實現(xiàn)變的很復雜，那么，把一些會頻繁使用到的數(shù)據(jù)直接保存在場景進程中，當數(shù)據(jù)發(fā)生改變時同步更新到數(shù)據(jù)服務器上，這樣可能會比較容易接受。

 

 

老板全都滿意了嗎？

 

從理論上來說，我們已經(jīng)解決了場景進程宕機和管理器宕機后的狀態(tài)恢復問題，并且在場景恢復后也不會因為丟失了玩家數(shù)據(jù)而無法繼續(xù)進行游戲，而且，只要處理得當，這個過程對客戶端來說可以是完全透明的，也就是玩家根本不知道服務器上有個進程意外結束，我們做了這么多的工作來將它恢復了。

 

事實上，這個過程的透明也是必須的，我們并不需要嚷嚷著告訴我們的用戶，也就是玩家，我們做了多少多少事情來讓你玩的更順暢，又花了多少多少精力來解決因為服務器宕機而引起的麻煩，對于最終的用戶來說，他只需要享受最好的服務。閑話少說，讓我們繼續(xù)。

 

真的已經(jīng)完全解決了所有問題嗎？

想象這樣一個場景：我?guī)е鴰讉€剛剛降臨到艾澤拉斯大陸的伙伴沖向了艾爾文森林，去開荒霍格！正在霍格只剩下一絲血的時候，服務器稍稍卡了一下，等我緩過神來，面前的霍格驟然消失，地上也不見尸體。找了一圈，它正在出生點搖頭晃腦，也在四處張望，但頭頂上的血條分明是，滿血！

怎么回事？

處理這張地圖的場景進程意外結束了，服務器的宕機處理機制很快地恢復了這個場景進程，并且把我的客戶端數(shù)據(jù)重新定向到了新場景。只是，事情并不是一切都完美。因為這個場景是完全重新創(chuàng)建的，這意味著所有的怪物也是重新創(chuàng)建并被擺放到了初始位置，所以，只剩下一絲血的霍格碰上了好運氣……

 

類似的還有，正在護送NPC返回營地，在稍微停頓了一會兒之后，NPC又重新回到了原來的地方，等等。

 

雖然這比起最初的“客戶端被迫斷開連接，服務器端數(shù)據(jù)丟失”要進步了許多，但會給我工資的老板仍然可能不太滿意，他希望，霍格應該還在我的面前，而且只有一絲血，那個跟著我的NPC也應該還在我旁邊……

 

我要是不能說服老板，這是“根本不可能完成的任務！”，那也就只能坐下來再試一試。

也許，可以考慮將所有對象的數(shù)據(jù)都保存到數(shù)據(jù)服務器上，當然，這要求每個怪物都跟玩家一樣，有一個唯一ID，這一點實現(xiàn)起來可能會有些麻煩。

再不然，為對象提供一個從已有的內(nèi)存數(shù)據(jù)構造的方法，這樣便可以使用共享內(nèi)存來保存現(xiàn)場數(shù)據(jù)，再從共享內(nèi)存中恢復出原來的對象。理論上來說，這個方法是可行的，只是，這三十多個字的文字描述要用C++來實現(xiàn)也可能將會是一項極大的挑戰(zhàn)，所以，這也僅只是可供參考的一個嘗試方案。

 

 

我想，我們走的夠遠了

 

讓我們先暫停一會兒，回過頭來看一看最初的目的。其實我們想要的只是盡可能的讓服務器進程不要宕機，如果實在是沒有辦法，就盡可能的讓宕機后的玩家損失比較小，不需要我們做大量的工作去做善后處理。

很簡單的需求，似乎我們糾纏的有些過頭了。

 

寫出能夠穩(wěn)定運行的程序是對程序員的最基本要求，如果一個程序連穩(wěn)定性都不具備，那根本都不用再去考慮功能啊、擴展啊等其他標準了。但是，正如我最開始所說的，沒有一個人能夠100%保證他寫出來的服務器程序是絕對不會崩潰的。我們所能要求的只是盡可能的仔細，盡可能的多一些必要的測試，離安全盡可能的更近一步。

 

剩下的就是在宕機后如何降低損失的問題了。

對于一般的MMOG來說，玩家在進入游戲時會從數(shù)據(jù)庫中將該玩家的所有相關數(shù)據(jù)讀到內(nèi)存，以便快速的進行游戲邏輯的處理，而在玩家下線時再將數(shù)據(jù)的改動存回數(shù)據(jù)庫。

顯然的，當服務器進程出現(xiàn)意外宕機時，內(nèi)存中所有的數(shù)據(jù)都丟失了，這也就造成了玩家數(shù)據(jù)的回檔，而且玩家在游戲中呆的時間越長，回檔的損失就越大。所以，一個被廣泛采用的做法是為玩家數(shù)據(jù)實現(xiàn)一種定時存盤的機制，就像現(xiàn)在大多數(shù)的單機游戲一樣，AutoSave。比如，每5分鐘自動為玩家存一次盤，這樣就可以使得回檔的最大損失控制在5分鐘以內(nèi)。

另外，對于一些重要數(shù)據(jù)的變動，比如玩家花大量游戲貨幣購買了一件貴重的武器裝備，這時可將玩家數(shù)據(jù)立即做一次存盤操作，這也將有效的減少玩家的重大損失。

 

聽起來這是一項不錯的技術，在意外宕機的時候最多只回檔5分鐘，而且還沒有貴重物品的損失，玩家應該是可以接受的吧。

 

 

我已經(jīng)聽到了數(shù)據(jù)庫維護員的咆哮

 

“數(shù)據(jù)庫已經(jīng)快要崩潰了，你就不能讓每秒需要執(zhí)行的SQL語句少一點嗎？”

“呃………”

 

我一直以為我們的數(shù)據(jù)庫非常強大，可以處理任何的數(shù)據(jù)，唯一的缺點就是查詢速度比直接內(nèi)存讀取要慢很多。所以我使用了異步數(shù)據(jù)存取的方法，并且開啟了多個數(shù)據(jù)庫操作線程來并行的執(zhí)行我的請求，運行的效果看起來還不錯。

 

也許，我應該來算一算，每秒種究竟丟了多少條操作請求給數(shù)據(jù)庫。

 

請允許我再自私一回，我已經(jīng)很久沒有提到WOW了……

大概可信的數(shù)字是，WOW一組服務器的玩家數(shù)量在3000到5000之間，去掉最大的數(shù)，再去掉最小的數(shù)，最后的平均值是，4000吧，就算4000。

4000人在線，假設也是每5分鐘定時存盤一次，再假設所有玩家的存盤時間是平均分布的。這樣算下來，每秒種就會有67個玩家向數(shù)據(jù)庫發(fā)出存盤請求操作。

 

才67個，數(shù)據(jù)庫維護組的同事就跟我說不堪重負了？笑話，這數(shù)據(jù)庫服務器是誰買的？

先別急，67是玩家數(shù)，但是每個玩家的存盤請求不會只有一條SQL語句。

 

雖然每個游戲的內(nèi)容都各有差別，但是一款MMOG需要存入數(shù)據(jù)庫的數(shù)據(jù)少不了會有技能、物品、任務、寵物、好友、公會這些東西。取決于游戲的類型差異，每個游戲都會有自己的存盤方式，比如我可能會把所有的技能ID作為一條數(shù)據(jù)來存儲，但是我也有可能把每個技能作為一條單獨的記錄來存儲，這樣可以方便對技能附加數(shù)據(jù)的擴展，等等。

 

但是，游戲中的物品存儲大概都是相同的，只能是一件(組)物品作為一條記錄來存儲。

而且，可以說游戲中存儲量最大的就是物品數(shù)據(jù)。算一算你的角色背包有多大，50格？ 100格？還是200格？不要忘了銀行、擺攤位、裝備攔、寵物背包和郵箱這些地方也能放物品。并且，在游戲進行過程中，玩家背包中物品數(shù)據(jù)的變動也是相當?shù)念l繁，不斷的有藥品被用掉，不斷地又有些小玩意兒被撿起來，不久后，它們又被賣給了NPC。

 

雖然你可以使用一些巧妙的比較算法來過濾掉那些實際上沒有發(fā)生變動的物品更新，另外也不是所有的玩家物品數(shù)據(jù)變動都很頻繁，但在實際運營中，尤其是當玩家的背包格數(shù)都很多的時候，物品數(shù)據(jù)的存盤的確會成為一個很大的問題。

 

除了物品，還有玩家的基本屬性存盤，社會關系存盤等等，再加上全局公共數(shù)據(jù)的存盤，如公會數(shù)據(jù)，拍賣行物品數(shù)據(jù)，如果老板也要我在游戲中開上一家拍賣行的話。

 

這么一算下來，似乎是有些多了。

 

 

再一次的挑戰(zhàn)

 

具體的數(shù)字將取決于游戲的類型和設計的數(shù)據(jù)表結構。

而數(shù)據(jù)庫服務器能承擔的每秒查詢數(shù)則取決于數(shù)據(jù)庫服務器的軟硬件配置情況。

但是一般來說，數(shù)據(jù)庫維護人員可能會告訴我，當每秒執(zhí)行的SQL語句數(shù)達到1000條時，數(shù)據(jù)庫服務器將會感受到明顯的壓力，我可能也會看到數(shù)據(jù)庫執(zhí)行隊列中的請求數(shù)一直在增長，也可能會看到數(shù)據(jù)庫服務器間歇性地拒絕響應，等等。

 

看起來我們又一次的面對到了巨大的打冷戰(zhàn)。

這個問題的起因是什么？我們不希望服務器進程宕機時回檔太久，所以我們增加了一個玩家數(shù)據(jù)定時存盤的機制，結果卻導致了數(shù)據(jù)庫請求的驟然增多。

那再退回到這個起點處，將定時存盤的時間間隔延長點，比如10分鐘才存一次？數(shù)據(jù)庫的壓力會有緩解，但最初的問題卻又會有所暴露。真是個兩難的問題。

 

既想要玩家數(shù)據(jù)存盤間隔時間短一點，又不想給數(shù)據(jù)庫造成的壓力太大。

同樣的需求似乎出現(xiàn)過很多回了：在中間加一層代理做緩沖。我們姑且稱這一層代理為數(shù)據(jù)庫代理服務器，它所要完成的工作是從場景進程收集玩家的定時存盤請求數(shù)據(jù)，再以一個低一點的頻率寫入到數(shù)據(jù)庫。

 

聽起來這又像是一個換湯不換藥的做法，寫入數(shù)據(jù)庫的時間間隔還是變長了。但實際上在前面我們就曾經(jīng)描述過，如果服務器進程不會出現(xiàn)意外的宕機，玩家數(shù)據(jù)只需要在他上線時讀取，在他下線時寫入即可，中間添加的這些定時存盤過程完全只是為了防范宕機回檔所造成的巨大損失。

 

因為這個中間代理層的加入，我們把場景進程宕機的隱患與數(shù)據(jù)丟失的后果隔離開來了，現(xiàn)在即使場景進程宕機，數(shù)據(jù)還在數(shù)據(jù)庫代理服務器上，當然這里又隱含了一個條件：數(shù)據(jù)庫代理服務器需要足夠穩(wěn)定，不會在場景進程之前先宕掉。事實上，因為這個代理進程的工作是，我們完全有理由相信，這個進程是非常穩(wěn)定的，那樣的話，多久時間才把緩存的數(shù)據(jù)真正寫入數(shù)據(jù)庫，就看你自己的喜好了。

 

 

該結束了吧

 

是否有些似曾相識的感覺？

沒錯，前面我們曾經(jīng)描述過一個數(shù)據(jù)服務器，也是這樣說的。

 

所以，數(shù)據(jù)服務器，數(shù)據(jù)庫代理服務器可以合并到一起，來共同保證數(shù)據(jù)的安全。

再加上場景進程與管理器進程的恢復協(xié)議，讓服務器的重啟對玩家保持透明。

看起來這個晚上可以睡個安穩(wěn)覺。