內存房間管理在多人游戲中的研究與設計

◆邵 嵐 隋玉亮 李 真

內存房間管理在多人游戲中的研究與設計

◆邵 嵐 隋玉亮 李 真

(CLO 北京 100000)

多人玩法允許多個人在同一個房間中互動游戲。本文主要描述了內存房間的業務邏輯和功能，多個房間在內存中的實現方式和效率優勢，研究了內存房間列表、超時事件列表和異步任務隊列的原理及設計實現。

內存管理；多人游戲；超時處理

0 引言

目前，我公司開發的游戲玩法均以單人玩法為主，無論是目前線上的游戲，還是后續開發的新游戲，盡管在游戲題材、游戲類型、游戲風格、動畫效果（3D）、屏幕顯示（雙屏）等方面進行了諸多創新，但是在游戲模式上，仍然都是單人參與的游戲，玩家之間的操作獨立互不影響，無法看到彼此的游戲狀態，無法分享中獎的喜悅，無法體驗和朋友共同游戲的樂趣。

如今的游戲行業，從早期的棋牌室、QQ游戲大廳[1]，到紅極一時的MUD網頁游戲，再到現在蓬勃發展的各類手機游戲，則是多人玩法的天下。這些游戲玩法中，除了需要完成本身游戲邏輯的實現，還額外需要解決多人游戲玩法特有的問題，如系統架構的設計[2]、虛擬游戲房間的分配與管理、內存及數據庫協同、游戲數據一致性與實時性、大并發量情況下如何解決系統的性能瓶頸[3]等。諸如此類的技術難點，需要在多人玩法中逐個實現。

本文研究并實現了一套支持多人游戲玩法的架構設計，首次使用內存（而非傳統的單純依賴數據庫）對游戲數據進行管理，通過映射、雙向鏈表、異步隊列等技術手段實現對虛擬游戲房間的分配、管理、數據同步、事件響應、回收、轉發等功能。本文的研究成果填補了我公司缺乏多人游戲玩法的空白，為今后的多人游戲策劃開發提供了技術借鑒與支持。

1 項目整體架構

該項目系統由客戶端、游戲服務器、通知服務器、大廳服務器、數據庫等組成，是在原有的單人玩法系統中增加多人玩法，本文研發實現的房間管理功能位于游戲服務中，各模塊間的關系如圖1所示。

圖1 項目整體架構圖

游戲終端和游戲服務器原有功能及連接不變，增加大廳服務器和通知服務器。游戲服務器使用FastCGI向通知服務器發送消息，通知服務器通過Corba把消息推送給大廳服務器，大廳服務器與游戲終端之間使用tsl加密的WebSocket互相通信。游戲服務器之間新增了轉發連接。

1.1 游戲終端

完成游戲的GUI展現和處理邏輯，負責調用游戲服務器的通信接口，根據收到的報文類型，把部分（或全部）報文轉發給大廳服務器，并接收大廳服務的廣播信息。

1.2 游戲服務器

游戲服務器負責完成游戲邏輯控制，保存游戲數據。在每個游戲服務器上新增了內存房間管理模塊，主要負責以下功能：虛擬房間的創建、管理、刪除；房間數據的同步與更新；對房間內各玩家進行監控，處理超時事件；將不屬于本服務負責的游戲請求轉發給其他游戲服務；服務異常之后的房間接管等。

1.3 通知服務器

在原有系統中增加通知服務器。通知服務器負責接收各個大廳服務器的注冊消息，以及各個游戲服務器發來的通知請求，并將消息推送給指定的大廳服務器。經過重新設計后，通知服務器不再負責任何游戲邏輯及處理超時事件等，僅負責消息的推送，進一步和游戲服務器解耦，使得模塊定位更加清晰準確。

1.4 大廳服務器

在原有系統中增加大廳服務器。大廳服務器接收各游戲客戶端的注冊，并向通知服務器注冊，收到通知服務器的通知信息后，解析消息內容中目的地址字段，將通知信息通知到對應的游戲客戶端。同時大廳服務器接收注冊過的客戶端發來的轉發消息，解析消息內容中目的地址字段，將消息廣播給對應的游戲客戶端。大廳服務器只負責信息轉發，不處理任何游戲邏輯。

1.5 數據庫

為多人游戲提供數據支持，包括玩家信息，游戲狀態，投注數據，房間信息，組隊信息等。

2 房間管理業務邏輯和功能

在多人玩法中玩家進入游戲房間后有兩種游戲場景：一種是房間內各玩家的投注互不干預但是可以互相觀看游戲結果，另一種是房間內所有玩家處在同一畫面相互配合贏得游戲獎勵。如果玩家在游戲房間中長時間不操作，游戲服務器會根據不同游戲場景將玩家踢出房間或者自動幫玩家完成游戲。同一房間內任何一個玩家游戲狀態或者房間狀態發生變化時都會產生通知信息，并由系統推送給房間內每個玩家，實現游戲畫面信息同步展示。

與房間管理相關的玩家業務操作主要有：玩家投注，加入房間，退出房間，超時。如圖2所示。

玩家發起投注請求時，會在房間列表中找到對應的玩家房間，以原子性的方式完成本玩家的一次投注過程，更新房間內玩家的投注信息。

玩家進入房間時，系統自動將該玩家匹配到當前人數最多且未滿員的游戲房間，并在此游戲房間數據中增加本玩家信息和超時事件，如果沒有滿足條件的房間，則為玩家新建一個房間并加入房間列表，同時在超時列表中加入一個針對本房間的超時計時器。

圖2 房間業務處理圖

玩家退出房間時，會在房間列表中找到對應的玩家房間，將玩家信息從房間里刪除。如果玩家退出后，房間內還有其他玩家，則在房間列表中保留本房間；如果玩家退出后，房間內沒有玩家了，則將本房間從房間列表中刪除，同時從超時列表中刪除本房間計時器。

在房間中的玩家，如果長時間不操作，會觸發超時事件。系統每隔1秒鐘會輪詢一次超時列表，發現對應房間的計時器超時，則將房間中的超時事件加入任務隊列執行。觸發超時事件后，根據游戲場景不同將玩家踢出房間或者幫玩家完成游戲。

在以上業務操作中，如果玩家信息或者房間狀態發生變化需要同步到房間內的所有玩家，則會生成同步信息，由推送系統推送到房間內各玩家客戶端。

3 房間管理技術原理及設計

內存房間管理將房間數據保存在內存中，主要設計并實現了以下內存數據結構及管理機制：房間列表，超時列表，異步任務隊列，房間數據轉發與異?；謴?。

3.1 房間列表技術原理及設計方式

為了快速的查找及增刪元素，房間列表采用map結構，對于每種游戲玩法，以房間編號作為key，以房間對象作為value形成map；為了使系統支持同時管理多個種類的游戲，本文進一步以游戲編號作為key，以上述map結構作為value，組成了新的map結構，即一個兩層結構的map嵌套，如圖3所示。

圖3 房間雙層map圖

另外，本文設計了三個房間相關的互斥鎖，分別為map鎖、房間數據鎖、引用計數鎖。map鎖在增刪房間、查找房間以及獲取房間對象個數時使用，完成相應操作后，先釋放map鎖，再返回得到的房間對象。在后續對房間對象進行業務操作時，調用房間數據鎖，保證房間數據的一致性，因為已經釋放了map鎖，因此不會阻塞其他線程的查找等操作。引用計數鎖使用的場景為：當成功創建或者找到房間時引用計數加1，當清除數據資源時引用計數減一?？傮w來說，通過在不同場景調用三個功能不同的互斥鎖，可以在保持數據一致性的前提下，最大限度的提高訪問效率，減少等待時間。

3.2 超時列表技術原理及設計方式

假設一個房間有n個玩家，每個玩家都會存在超時情況，房間本身也存在超時情況。這樣，一個房間中就會存在n+1個超時事件。如果每個超時事件對應一個超時計時器，一個房間需要n+1個超時計時器，過多的超時計時器會增加管理難度并引起業務處理的混亂。

為了解決以上問題，采用兩級列表的方式處理超時，第一級列表是每個房間的所有超時事件以雙向鏈表的方式按照超時時間排序掛入本房間數據結構下；第二級列表是只將房間超時鏈表最近一個超時事件放入全局超時列表中，從而保證了每個房間在全局超時列表中只存在一個超時計時器，如圖4所示。

圖4 超時鏈表設計圖

系統每秒鐘輪詢一次全局超時鏈表，將超時事件放入異步任務隊列；當異步任務隊列的超時事件執行后，會從房間超時鏈表中取出下一個本房間的超時事件，放入全局超時鏈表。

3.3 異步任務隊列技術原理及設計方式

在多人游戲業務中，即存在實時任務，如投注請求，也存在異步任務，如超時事件，通知事件。這些任務都是針對一個具體的房間執行的，為了保證內存房間數據的一致性，保證實時任務和異步任務的正常執行，防止異步任務的阻塞與丟失，引入了異步任務隊列。所有的異步任務全部放入異步任務隊列，只有在當前任務執行完成后，才會從異步任務隊列取得下一個任務執行，既保證了實時任務的及時處理，也保證了異步任務的處理，完整的實現了多人游戲的業務邏輯。如圖5所示。

圖5 實時與異步任務執行圖

實時任務或異步任務執行時，都會從房間列表查找對應房間，并鎖定房間數據，執行完成后才允許其他任務操作本房間數據。引入異步任務隊列后，把異步任務緩存到隊列中，只允許本房間的一個異步任務對房間數據加鎖，不會引起過多的任務同時對同一房間加鎖而阻塞，同時還能保證當前任務執行完后，就會執行實時任務。異步任務隊列通過sem信號監聽當前隊列中是否有需要執行的任務，如果有則執行，沒有則不做操作。

3.4 房間數據轉發與異?；謴?/h3>

在現有系統架構下，每個游戲客戶端可能連接到不同的游戲服務，而這些客戶端因為參與多人玩法又被分配到同一個游戲房間，這會導致部署在不同游戲服務的內存房間管理模塊互相爭搶游戲房間的控制權，造成數據沖突與錯誤。為了解決這一問題，本文新增了游戲服務之間的轉發連接，如圖1所示。該轉發消息通過iona中間件實現，收到客戶端的請求后，先查詢數據庫，判斷該客戶端歸屬的房間服務url是否和本機的相同，如果相同則繼續處理業務請求，如果不相同，則需要向目標url發送轉發的消息，交由目標服務接管。

如果在上述轉發過程中發現目標url的連接不存在，即表明目標服務出現了異常，則需要本服務接管起目標服務負責的所有房間，從數據庫讀取數據并恢復。待出異常的服務重新上線后，其會嘗試從數據庫恢復房間數據，繼續提供服務。通過異?；謴团c房間服務互相接管的設計，保證了即使有部分房間服務發生異常，剩余的房間服務仍可以保持服務不中斷。

4 總結

本文在公司現有單人玩法系統的基礎上，新增了通知服務器和大廳服務器，擴展成可以支持多人游戲玩法的系統，首次嘗試用內存房間管理游戲數據，通過雙層map映射、雙向鏈表、任務隊列等技術完成開發，完整的實現了多人游戲的業務邏輯，既保證了數據一致性，又減少了對數據庫的頻繁讀取，提高了系統效率。通過本次多人游戲系統的研發，不僅增加了公司技術儲備，同時也拓寬了游戲設計的角度與方式。

由于是首次進行多人游戲系統的設計，本項目在開發過程中不可避免的存在若干不足，如解決在消息推送過程中偶發的丟包現象；在長時間、大并發的情況下系統的響應時效與穩定性；如何監控各服務的狀態及發生異常后的處理等，均需在今后的研發過程進一步的完善，并不斷探索新技術、新方式，以滿足未來游戲的需求。

[1]QQ游戲大廳體驗報告.https://www.jianshu.com/p/df5 b66077949.

[2]從QQ游戲分布式架構設計看“分而治之”等原則.http://tech.it168.com/a2009/1019/762/000000762733.shtml.

[3]QQ游戲百萬人同時在線服務器架構實現.https://blog.csdn.net/akunshouyoudou/article/details/56682869.