MSN: [email protected]
我 不得不承認，我的能力不足以寫出一個100%不會宕機的遊戲服務器程序，這也不能全怪我的能力太弱，誰讓咱國內網遊玩家數量龐大，哪個遊戲剛上線時沒有擠 的爆滿過？還有些或是獵奇，或是謀私的個人和組織，在製造着千奇百怪，匪夷所思的數據包及操作流程來試探你的服務器。這些都曾是我在服務器宕機後向老闆開 脫的理由。
當WOW終於來到中國時，我一邊欣喜着終於可以在艾澤拉斯的大陸上自由翱翔，一邊卻咒罵着9C的破服務器，動不 動就宕機。當然，身爲遊戲程序設計師的我明知道，這大部分的錯誤都不應歸罪於代理商9C，但是，誰讓blizzard是我心目中的神，誰又讓WOW成爲我 遊戲製作的教科書呢。好吧，我知道上面這段極力追捧blizzard跟WOW的話可能早已讓你噁心連連，不堪入目了，對不起，忘了這一節，讓我們繼續。
服務器宕機後都發生了些什麼？
顯 然的，宕機後玩家會罵，就像我在玩WOW時那樣，罵遊戲公司，罵老闆，罵GM。非常抱歉，我們可愛的玩家們似乎並不清楚，這個時候最該罵的其實是我們這些 程序員們。長久的遺忘被我們當成了包容，以至於遊戲程序員在公司裏都養成了趾高氣揚，不可一世的壞毛病：看吧，策劃們，你們做的太爛了，數值不平衡，玩法 沒新意，只會照抄WOW跟大菠蘿，能怪玩家罵你們嗎？運營不得力，買服務器的錢不知道去了哪裏，遊戲裏卡的要死，偶爾辦個活動還沒半點吸引力，能不被玩家 罵你是無良運營商嗎？GM們能不天天被罵家指着罵嗎？……呃，又扯遠了。
趕緊先把服務器重啓吧。老闆正站在你的身後，一臉愁容，雖然暫時還沒有發作，但看得出來：老闆很生氣，後果很嚴重！
玩家們很快又回來了，不得不爲玩家們的毅力和執着精神而感動，更爲自己的錯誤而愧疚，凌晨時分，服務器啓了又宕，宕了又啓，如此反覆，可熱情的玩家們依然陪着我在折騰。哦，當年安其拉開門的時候，我也曾這樣折騰過。
這個時候不是你一個人在戰鬥。GM們在忙碌地處理着玩家不斷打來的投訴電話：剛買的裝備在宕機後消失了；花光了身上所有材料合成的武器回檔了，但材料卻沒有還給我……數據庫維護組的同事們也在緊張的恢復着數據，儘可能的將玩家的損失減到最少。
真是一件令人沮喪的事。
真的該試着做點什麼了吧！
既然我們非常不願意看到宕機的情況發生，但又無法100%保證寫出來的服務器程序一定不會出錯，那我們就在當機發生後的搶救措施上花點功夫，讓玩家的損失不至於太大，也讓我們的維護人員少些壓力吧。
一個最簡單也最有效的做法是爲每一臺服務器都配備物理冗餘，同步更新冗餘服務器上的狀態，當宕機發生時，立即將處理切換到後備服務器上。只是，物理冗餘的代價太大，從成本方面考慮，老闆可能不大願意點頭。
既然不能做硬冗餘，那就再來考慮軟的吧。
如果只是簡單的啓動冗餘進程，其實是換湯不換藥的做法。原來能跑1000人的服務器，由於同時運行了兩個相同的進程，使得CPU和內存開銷都翻了倍，結果是隻能跑500人了。還是要加服務器。
看來只能更深一層，從架構設計上來動手了。
假 設我們的遊戲世界是由多個獨立場景構成的，那麼在實現上我們可以讓這些場景在進程上也獨立，這樣做的好處是可以使得一個場景的宕機不會影響到其他場景的正 常運行。如果我們的遊戲世界物理上沒有分隔，是一個無縫的大世界，我們也可以人爲的將其分成多個獨立區域，所需要做的額外工作是處理好那些站在區域邊界附 近的對象。事實上，現在的無縫大世界也都是這樣實現的。
有了這樣一個前提，我們再來看這個已宕掉的場景該如何處理。
還 是老辦法，趕緊先把它拉起來吧。一個具體可行的方案是，由場景管理器，或者你也有可能叫它世界服務器，來監視各個場景進程的運行狀態，當某個場景異常失去 聯繫時，由管理器來將其重新啓動。這裏需要再花點心思的是，如何讓玩家數據正常地發送到新啓動的場景進程中，而且這個過程對於客戶端來說是透明的。
這個方案聽起來似乎不錯，只是，如果宕掉的是場景管理器進程，那該怎麼辦呢？
按照前面的描述，場景管理器可以看作是整個遊戲世界的中心，它以一個指揮者的身份維護着遊戲世界的有序運行，所以它的宕機對整個遊戲世界的影響也將會是巨大的。
有沒有什麼辦法能夠使得場景管理器進程再次啓動後能夠恢復先前的狀態呢？
我們可以爲管理器和場景進程定義一套協議，使得管理器不僅能夠創建並恢復一個已有場景，而且場景管理器還能通過現有的場景進程數據恢復出自己。
一個理論上可行的方案是，場景管理器與場景進程間保持TCP長連接，並以一定頻率進行心跳聯繫，任意一方發現聯繫中斷或長時間未收到心跳包後都會立即做出處理。
如 果是管理器發現場景進程失去聯繫，那就啓動新的場景，如前面所描述的那樣。如果是場景進程發現管理器失去聯繫，那就立即啓動重連過程，直接再次連接上管理 器，然後立即將自己當前的狀態和負責的場景ID報告給管理器。管理器通過這些上報的數據就能恢復出遊戲世界內的場景對應關係表，也就是恢復出了自己原來的 狀態。
進程是恢復出來了，可我們忘了最重要的內容：數據。當場景進程宕機後，上面保存的玩家屬性數據也隨之丟失了，雖然我們能夠再次將這個場景創建出來，並把原來在這個場景內的客戶端數據重新定向過來，但這些客戶端對應的玩家對象的數據卻沒有了，遊戲仍然無法繼續。
也 許我們可以再做一點修改，把場景內的玩家數據分離出來，保存到一個獨立的進程上，比如，我們可以把這個進程叫做數據服務器，或者數據中心之類的。一個隱含 的要求是，數據服務器的邏輯實現非常簡單，簡單到你可以認爲它是絕對安全的，不會宕機。所以，保存在這裏的玩家數據也就是絕對安全的。
讓我們在這個問題上稍微再深入一點。
場景進程上每次執行玩家的遊戲邏輯時都要異步地到數據服務器上來存取數據，這個開銷可能太大，而且會使得一些遊戲邏輯的實現變的很複雜，那麼，把一些會頻繁使用到的數據直接保存在場景進程中，當數據發生改變時同步更新到數據服務器上，這樣可能會比較容易接受。
老闆全都滿意了嗎？
從 理論上來說，我們已經解決了場景進程宕機和管理器宕機後的狀態恢復問題，並且在場景恢復後也不會因爲丟失了玩家數據而無法繼續進行遊戲，而且，只要處理得 當，這個過程對客戶端來說可以是完全透明的，也就是玩家根本不知道服務器上有個進程意外結束，我們做了這麼多的工作來將它恢復了。
事實上，這個過程的透明也是必須的，我們並不需要嚷嚷着告訴我們的用戶，也就是玩家，我們做了多少多少事情來讓你玩的更順暢，又花了多少多少精力來解決因爲服務器宕機而引起的麻煩，對於最終的用戶來說，他只需要享受最好的服務。閒話少說，讓我們繼續。
真的已經完全解決了所有問題嗎？
想 象這樣一個場景：我帶着幾個剛剛降臨到艾澤拉斯大陸的夥伴衝向了艾爾文森林，去開荒霍格！正在霍格只剩下一絲血的時候，服務器稍稍卡了一下，等我緩過神 來，面前的霍格驟然消失，地上也不見屍體。找了一圈，它正在出生點搖頭晃腦，也在四處張望，但頭頂上的血條分明是，滿血！
怎麼回事？
處 理這張地圖的場景進程意外結束了，服務器的宕機處理機制很快地恢復了這個場景進程，並且把我的客戶端數據重新定向到了新場景。只是，事情並不是一切都完 美。因爲這個場景是完全重新創建的，這意味着所有的怪物也是重新創建並被擺放到了初始位置，所以，只剩下一絲血的霍格碰上了好運氣……
類似的還有，正在護送NPC返回營地，在稍微停頓了一會兒之後，NPC又重新回到了原來的地方，等等。
雖然這比起最初的“客戶端被迫斷開連接，服務器端數據丟失”要進步了許多，但會給我工資的老闆仍然可能不太滿意，他希望，霍格應該還在我的面前，而且只有一絲血，那個跟着我的NPC也應該還在我旁邊……
我要是不能說服老闆，這是“根本不可能完成的任務！”，那也就只能坐下來再試一試。
也許，可以考慮將所有對象的數據都保存到數據服務器上，當然，這要求每個怪物都跟玩家一樣，有一個唯一ID，這一點實現起來可能會有些麻煩。
再 不然，爲對象提供一個從已有的內存數據構造的方法，這樣便可以使用共享內存來保存現場數據，再從共享內存中恢復出原來的對象。理論上來說，這個方法是可行 的，只是，這三十多個字的文字描述要用C++來實現也可能將會是一項極大的挑戰，所以，這也僅只是可供參考的一個嘗試方案。
我想，我們走的夠遠了
讓我們先暫停一會兒，回過頭來看一看最初的目的。其實我們想要的只是儘可能的讓服務器進程不要宕機，如果實在是沒有辦法，就儘可能的讓宕機後的玩家損失比較小，不需要我們做大量的工作去做善後處理。
很簡單的需求，似乎我們糾纏的有些過頭了。
寫 出能夠穩定運行的程序是對程序員的最基本要求，如果一個程序連穩定性都不具備，那根本都不用再去考慮功能啊、擴展啊等其他標準了。但是，正如我最開始所說 的，沒有一個人能夠100%保證他寫出來的服務器程序是絕對不會崩潰的。我們所能要求的只是儘可能的仔細，儘可能的多一些必要的測試，離安全儘可能的更近 一步。
剩下的就是在宕機後如何降低損失的問題了。
對於一般的MMOG來說，玩家在進入遊戲時會從數據庫中將該玩家的所有相關數據讀到內存，以便快速的進行遊戲邏輯的處理，而在玩家下線時再將數據的改動存回數據庫。
顯 然的，當服務器進程出現意外宕機時，內存中所有的數據都丟失了，這也就造成了玩家數據的回檔，而且玩家在遊戲中呆的時間越長，回檔的損失就越大。所以，一 個被廣泛採用的做法是爲玩家數據實現一種定時存盤的機制，就像現在大多數的單機遊戲一樣，AutoSave。比如，每5分鐘自動爲玩家存一次盤，這樣就可 以使得回檔的最大損失控制在5分鐘以內。
另外，對於一些重要數據的變動，比如玩家花大量遊戲貨幣購買了一件貴重的武器裝備，這時可將玩家數據立即做一次存盤操作，這也將有效的減少玩家的重大損失。
聽起來這是一項不錯的技術，在意外宕機的時候最多隻回檔5分鐘，而且還沒有貴重物品的損失，玩家應該是可以接受的吧。
我已經聽到了數據庫維護員的咆哮
“數據庫已經快要崩潰了，你就不能讓每秒需要執行的SQL語句少一點嗎？”
“呃………”
我一直以爲我們的數據庫非常強大，可以處理任何的數據，唯一的缺點就是查詢速度比直接內存讀取要慢很多。所以我使用了異步數據存取的方法，並且開啓了多個數據庫操作線程來並行的執行我的請求，運行的效果看起來還不錯。
也許，我應該來算一算，每秒種究竟丟了多少條操作請求給數據庫。
請允許我再自私一回，我已經很久沒有提到WOW了……
大概可信的數字是，WOW一組服務器的玩家數量在3000到5000之間，去掉最大的數，再去掉最小的數，最後的平均值是，4000吧，就算4000。
4000人在線，假設也是每5分鐘定時存盤一次，再假設所有玩家的存盤時間是平均分佈的。這樣算下來，每秒種就會有67個玩家向數據庫發出存盤請求操作。
才67個，數據庫維護組的同事就跟我說不堪重負了？笑話，這數據庫服務器是誰買的？
先別急，67是玩家數，但是每個玩家的存盤請求不會只有一條SQL語句。
雖 然每個遊戲的內容都各有差別，但是一款MMOG需要存入數據庫的數據少不了會有技能、物品、任務、寵物、好友、公會這些東西。取決於遊戲的類型差異，每個 遊戲都會有自己的存盤方式，比如我可能會把所有的技能ID作爲一條數據來存儲，但是我也有可能把每個技能作爲一條單獨的記錄來存儲，這樣可以方便對技能附 加數據的擴展，等等。
但是，遊戲中的物品存儲大概都是相同的，只能是一件(組)物品作爲一條記錄來存儲。
而 且，可以說遊戲中存儲量最大的就是物品數據。算一算你的角色揹包有多大，50格？ 100格？還是200格？不要忘了銀行、擺攤位、裝備攔、寵物揹包和郵 箱這些地方也能放物品。並且，在遊戲進行過程中，玩家揹包中物品數據的變動也是相當的頻繁，不斷的有藥品被用掉，不斷地又有些小玩意兒被撿起來，不久後， 它們又被賣給了NPC。
雖然你可以使用一些巧妙的比較算法來過濾掉那些實際上沒有發生變動的物品更新，另外也不是所有的玩家物品數據變動都很頻繁，但在實際運營中，尤其是當玩家的揹包格數都很多的時候，物品數據的存盤的確會成爲一個很大的問題。
除了物品，還有玩家的基本屬性存盤，社會關係存盤等等，再加上全局公共數據的存盤，如公會數據，拍賣行物品數據，如果老闆也要我在遊戲中開上一家拍賣行的話。
這麼一算下來，似乎是有些多了。
再一次的挑戰
具體的數字將取決於遊戲的類型和設計的數據表結構。
而數據庫服務器能承擔的每秒查詢數則取決於數據庫服務器的軟硬件配置情況。
但是一般來說，數據庫維護人員可能會告訴我，當每秒執行的SQL語句數達到1000條時，數據庫服務器將會感受到明顯的壓力，我可能也會看到數據庫執行隊列中的請求數一直在增長，也可能會看到數據庫服務器間歇性地拒絕響應，等等。
看起來我們又一次的面對到了巨大的打冷戰。
這個問題的起因是什麼？我們不希望服務器進程宕機時回檔太久，所以我們增加了一個玩家數據定時存盤的機制，結果卻導致了數據庫請求的驟然增多。
那再退回到這個起點處，將定時存盤的時間間隔延長點，比如10分鐘才存一次？數據庫的壓力會有緩解，但最初的問題卻又會有所暴露。真是個兩難的問題。
既想要玩家數據存盤間隔時間短一點，又不想給數據庫造成的壓力太大。
同樣的需求似乎出現過很多回了：在中間加一層代理做緩衝。我們姑且稱這一層代理爲數據庫代理服務器，它所要完成的工作是從場景進程收集玩家的定時存盤請求數據，再以一個低一點的頻率寫入到數據庫。
聽起來這又像是一個換湯不換藥的做法，寫入數據庫的時間間隔還是變長了。但實際上在前面我們就曾經描述過，如果服務器進程不會出現意外的宕機，玩家數據只需要在他上線時讀取，在他下線時寫入即可，中間添加的這些定時存盤過程完全只是爲了防範宕機回檔所造成的巨大損失。
因 爲這個中間代理層的加入，我們把場景進程宕機的隱患與數據丟失的後果隔離開來了，現在即使場景進程宕機，數據還在數據庫代理服務器上，當然這裏又隱含了一 個條件：數據庫代理服務器需要足夠穩定，不會在場景進程之前先宕掉。事實上，因爲這個代理進程的工作是，我們完全有理由相信，這個進程是非常穩定的，那樣 的話，多久時間才把緩存的數據真正寫入數據庫，就看你自己的喜好了。
該結束了吧
是否有些似曾相識的感覺？
沒錯，前面我們曾經描述過一個數據服務器，也是這樣說的。
所以，數據服務器，數據庫代理服務器可以合併到一起，來共同保證數據的安全。
再加上場景進程與管理器進程的恢復協議，讓服務器的重啓對玩家保持透明。
看起來這個晚上可以睡個安穩覺。