騰訊QQGame游戲同時在線的玩家數量極其龐大，為了方便組織玩家組隊游戲，騰訊設置了大量游戲室（房間），玩家可以選擇進入屬意的房間，并在此房間內找到可以加入的游戲組（牌桌、棋盤等）。玩家選擇進入某個房間時，必須確保此房間當前人數未滿（通常上限為400），否則進入步驟將會失敗。玩家在登入QQGame后，會從服務器端獲取某類游戲下所有房間的當前人數數據，玩家可以據此找到未滿的房間以便進入。

如上篇所述的原因，如果待進入房間的人數接近上限時，玩家的進入請求可能失敗，這是因為服務器在收到此進入請求之前可能有若干其他玩家也請求進入這個房間，造成房間人數達到上限。

這一問題是無法通過上篇所述調整協作分配的方法來解決的，這是因為：要進入的房間是由玩家來指定的，無法在服務器端完成此項工作，游戲軟件必須將服務器端所維護的所有房間人數數據復制到玩家的客戶端，并讓玩家在界面上看到這些數據，以便進行選擇。

這樣，上篇所述的客戶端與服務器端協作分配原則（誰掌握數據，誰干活），還得加上一些限制條件，并讓位于另一個所謂"用戶驅動客戶端行為"原則--如果某個功能的執行是由用戶來推動的，則這個功能的實現應當放在客戶端（或者至少由客戶端來控制整個協作），并且客戶端必須持有此功能所依賴相關數據的副本，這個副本應當盡量與服務器端的源保持同步。注意：點擊圖片可以放大觀看

圖一"進入房間"失敗示意

QQGame還存在一個明顯的不足，就是：玩家如果在游戲一段時間后，離開了某個房間，并且想進入其它房間，這時QQGame并不會刷新所有房間的當前人數，造成玩家據此信息所選的待進入房間往往實際上人數已滿，使得進入步驟失敗。筆者碰到的最糟情形是重復3、4次以上，才最后成功進入另外某個房間。此缺陷其實質是完全放棄了客戶端數據副本與服務器端的源保持同步的原則。

實際上，QQGame的開發者有非常充分的理由來為此缺陷的存在進行辯護：QQGame同時在線的用戶數超過百萬甚至千萬數量級，如果所有客戶端要實時（所謂實時，就玩家的體驗容忍度而言，可以定為不超過1秒的延遲）地從服務器端獲取更新數據，那么最終只有一個結果--系統徹底崩潰。

設想一下每秒千萬次請求的吞吐量，以普通服務器每秒上百個請求的處理能力（這個數據是根據服務請求處理過程可能涉及到I/O操作來估值的，純內存處理的情形可能提高若干數量級），需要成千上萬臺服務器組成集群方能承受（高可用性挑戰）；而隨著玩家不斷地進入或退出游戲房間，相關數據一直在快速變化中，

正向來看，假設有一臺中心服務器持有這些數據，那么需要讓成千上萬臺服務器與中心保持這些動態數據的實時同步（數據一致性挑戰）；

相對應的，逆向來看，玩家進入房間等請求被分配給不同的服務器來處理，一旦玩家進入房間成功則對應服務器內的相關數據被改變，那么假定中的中心服務器就需要實時匯集所有工作服務器內發生的數據變動（數據完整性挑戰）。

同時處理上萬臺服務器的數據同步，這需要什么樣的中心服務器呢？即使有這樣的超級服務器存在，那么Internet網較大的（而且不穩定的）網絡通訊延遲又怎么解決呢？

對于軟件缺陷而言，可以在不同的層面來加以解決--從設計、到需求、甚至是直接在業務層面來解決（例如，08年北京奧運會網上購票系統，為了解決訂票請求擁塞而至系統崩潰的缺陷，最后放棄了原先"先到先得"的購票業務流程，改為：用戶先向系統發訂票申請，系統只是記錄下來而不進行處理，而到了空閑時，在后臺隨機抽選幸運者，為他們一一完成訂票業務）。當然解決方案所處的層面越高，可能就越讓人不滿意。

就上述進入房間可能遭遇失敗的缺陷而言，最簡便的解決方案就是：在需求層面調整系統的操作方式，即增加一個類似上篇所述"自動快速加入游戲"的功能--"自動進入房間"功能。系統在服務器端為玩家找到一個人數較多又未滿的房間，并嘗試進入（注意，軟件需求是由用戶的操作目標所驅動的，玩家在此的目標就是盡快加入一個滿意的游戲組，因此由系統來替代玩家選擇目標房間同樣符合相關目標）。而為了方便玩家手工選擇要進入的房間，則應當增加一個"刷新當前各房間人數"的功能。另外，還可以調整房間的組織模式，例如以地域為單位來劃分房間，像深圳（長城寬帶）區房間1、四川（電信）房間3、北美區房間1等，在深圳上網的玩家將被系統引導而優先進入深圳區的房間。

不管怎樣，解決軟件缺陷的王道還是在設計層面。要解決上述缺陷，架構設計師就必須同時面對高可用、數據一致性、完整性等方面的嚴峻挑戰。

在思考相關解決方案時，我們將應用若干與高性能服務器集群架構設計相關的一些重要原則。首先是"分而治之"原則，即將大量客戶端發出的服務請求進行適當的劃分（例如，所有從深圳長城寬帶上網的玩家所發出的服務請求分為一組），分別分配給不同的服務器（例如，將前述服務請求分組分配給放置于深圳數據中心的服務器）來加以處理。對于QQGame千萬級的并發服務請求數而言，采用Scale Up向上擴展，即升級單個服務器處理能力的方式基本上不予考慮（沒有常規的主機能處理每秒上千萬的請求）。唯一可行的，只有Scale Out向外擴展，即利用大量服務器集群做負載均衡的方式，這實質上就是"分而治之"原則的具體應用。點擊圖片可以放大

圖二 分而治之"下的QQGame游戲服務集群部署

然而，要應用"分而治之"原則進行Scale Out向外擴展，還依賴于其它的條件。如果各服務器在處理被分配的服務請求時，其行為與其它服務器的行為結果產生交叉（循環）依賴，換句話講就是共享了某些數據（例如，服務器A處理客戶端a發來的進入房間#n請求，而同時，服務器B也在處理客戶端b發來的進入房間#n請求，此時服務器A與B的行為存在循環依賴--因為兩者要同時訪問房間#n的數據，這一共享數據會造成兩者間的循環依賴），則各服務器之間必須確保這些共享數據的一致完整性，否則就可能發生邏輯錯誤（例如，假定房間#n的人數差一個就滿了，服務器A與B在獨自處理的情況下，將同時讓客戶端a與b的進入請求成功，于是房間#n的最終人數將超出上限）。

而要做到此點，各服務器的處理進程之間就必須保持同步（實際上就是排隊按先后順序訪問共享數據，例如：服務器A先處理，讓客戶端a進入房間成功，此時房間#n滿員；此后服務器B更新到房間#n滿的數據，于是客戶端b的進入請求處理結果失敗），這樣，原來將海量請求做負載均衡的意圖就徹底失敗了，多臺服務器的并發處理能力在此與一臺實質上并沒有區別。

由此，我們導出了另外一個所謂"處理自治"（或稱"行為獨立"）的原則，即所有參與負載均衡的服務器，其處理對應服務請求的行為應當不循環依賴于其它服務器，換句話講，就是各服務器的行為相對獨立（注意：在這里，非循環依賴是允許的，下文中我們來分析為什么）。

由此可見，簡單的負載均衡策略對于QQGame而言是解決不了問題的。我們必須找到一種途徑，使得在使用大量服務器進行"分而治之"的同時，同時有確保各個服務器"處理自治"。此間的關鍵就在于"分而治之"的"分"字上。前述將某個地域網段內上網的玩家所發出的服務請求分到一組，并分配給同一服務器的做法，其目的不外乎是盡可能地減少網絡通訊延遲帶來的負面影響。但它不能滿足"處理自治"的要求，為了確保自治，應當讓同一臺服務器所處理的請求本身是"自治"（準確的說法是"自閉包"Closure）的。同一臺服務器所處理的所有請求組成一個服務請求集合，這個集合如果與其它任何與其無交集的（請求）集合（包含此集合的父集合除外）不循環依賴，則此服務請求集合是"自閉包"的，而處理此請求集合的服務器，其"行為獨立"。

我們可以將針對同一房間的進入請求劃分到同一服務請求分組，這些請求相互之間當然是存在循環依賴的，但與其它分組中的請求卻不存在循環依賴（本房間內人數的變化不會影響到其它房間），而將它們都分配給同一服務器（不妨命名為"房間管理服務器"，簡稱"房間服務器"）后，那個服務器將是"處理自治"的。點擊圖片可以放大

圖三 滿足"處理自治"條件的QQ游戲區域"房間管理"服務部署

那么接下來要解決的問題，就是玩家所關注的某個游戲區內，所有房間當前人數數據的實時更新問題。其解決途徑與上述的方法類似，我們還是將所有獲取同一區內房間數據的服務請求歸為一組，并交給同一服務器處理。與上文所述場景不同的是，這個服務器需要實時匯集本區內所有房間服務器的房間人數數據。我們可以讓每個房間服務器一旦發生數據變更時，就向此服務器（不妨命名為"游戲區域管理服務器"，簡稱"區服務器"）推送一個變更數據記錄，而推送的數據只需包含房間Id和所有進入的玩家Id（房間服務器還包含其它細節數據，例如牌桌占位數據）便可。

另外，由于一個區內的玩家數可能是上十萬數量級，一個服務器根本承擔不了此種負荷，那么怎么解決這一矛盾呢？如果深入分析，我們會發現，更新區內房間數據的請求是一種數據只讀類請求，它不會對服務器狀態造成變更影響，因此這些請求相互間不存在依賴關系；這樣，我們可以將它們再任意劃分為更小的分組，而同時這些分組仍然保持"自閉包"特性，然后分配給不同的區服務器。多臺區服務器來負責同一區的數據更新請求，負載瓶頸被解決。

當然，此前，還需將這些區服務器分為1臺主區服務器和n臺從屬區服務器；主區服務器負責匯集本區內所有房間服務器的房間人數數據，從屬區服務器則從主區服務器實時同步區房間數據副本。

更好的做法，則是如『圖五』所示，由房間服務器來充當從屬區服務器的角色，玩家進入某個房間后，在玩家進入另外一個房間之前，其客戶端都將從此房間對應的房間服務器來更新區內房間數據。要注意的是，圖中房間服務器的數據更新利用了所謂的"分布式對象緩存服務"。

玩家進入某個房間后，還要加入某個游戲組才能玩游戲。上篇所述的方案，是讓第一個加入某個牌桌的用戶，其主機自動充當本牌桌的游戲服務器；而其它玩家要加入此牌桌，其加入請求應當發往第一個加入的用戶主機；此后開始游戲，其對弈過程將由第一個加入用戶的主機來主導執行。

那么此途徑是否同樣也符合上述的前兩個設計原則呢？游戲在執行的過程中，根據輸贏結果，玩家要加分或減分，同時還要記錄勝負場數。這些數據必須被持久化（比如在數據庫中保存下來），因此游戲服務器（『圖六』中的設計，是由4個部署于QQ客戶端的"升級"游戲前臺邏輯執行服務，加上1個"升級"游戲后臺邏輯執行服務，共同組成一個牌桌的"升級"游戲服務）在處理相關游戲執行請求時，將依賴于玩家游戲賬戶數據服務（『圖六』中的所謂"QQGame會話服務"）；

不過這種依賴是非循環的，即玩家游戲賬戶數據服務器的行為反過來并不依賴于游戲服務器。上文中曾提到，"處理自治"原則中非循環依賴是允許的。這里游戲服務器在處理游戲收盤請求時，要調用玩家游戲賬戶數據服務器來更新相關數據；因為不同玩家的游戲賬戶數據是相互獨立的，此游戲服務器在調用游戲賬戶數據服務器時，邏輯上不受其它游戲服務器調用游戲賬戶數據服務器的影響，不存在同步等待問題；所以，游戲服務器在此能夠達成負載均衡的意圖。點擊圖片可以放大

圖四 存在"非循環依賴"的QQ游戲客戶端P2P服務與交互邏輯部署

不過，在上述場景中，雖然不存在同步依賴，但是性能依賴還是存在的，游戲賬戶數據服務器的處理性能不夠時，會造成游戲服務器長時間等待。為此，我們可以應用分布式數據庫表水平分割的技術，將QQ玩家用戶以其登記的行政區來加以分組，并部署于對應區域的數據庫中（例如，深圳的玩家數據都在深圳的游戲賬戶數據庫中）。

點擊圖片可以放大

圖五 滿足"自閉包"條件的QQ分布式數據庫（集群）部署

實際上，我們由此還可以推論出一個數據庫表水平分割的原則--任何數據庫表水平分割的方式，必須確保同一數據庫實例中的數據記錄是"自閉包"的，即不同數據庫實例中的數據記錄相互間不存在循環依賴。

總之，初步滿足QQGame之苛刻性能要求的分布式架構現在已經是初具雛形了，但仍然有很多涉及性能方面的細節問題有待解決。例如，Internet網絡通訊延遲的問題、服務器之間協作產生的性能瓶頸問題等等。筆者將在下篇中繼續深入探討這些話題。