10分鐘看懂，遊戲伺服器端資料儲存的特異性

導語：在遊戲伺服器端開發領域中的很多重要問題，都有其特異性，需要專門對待。騰訊遊戲學院專家Wade將在本文介紹具體有哪些特異性，方便遊戲伺服器架構後續形成更好的標準化和複用性。

在中國的網際網路諸多業務領域中，遊戲一直是充當“現金牛”而存在的。但是，在遊戲伺服器端開發領域中的很多重要問題，並沒有被明確的分辨出其特異性，從而得到專門的對待。我們不管是在業界開源領域，還是內部分享中，很少會有專門針對遊戲業務特徵進行專門設計的元件、類庫或者框架。我們從遊戲的客戶端方面來看，一款專業的遊戲客戶端引擎，已經是遊戲開發的標配，比如最早的Flash Builder，到後期的Cocos2d-X，Unity，Unreal；但是伺服器端，我們幾乎找不到同樣重量級的產品。

在遊戲伺服器端開發所有要面對的問題中，有兩個是最核心和最普遍的：一是和客戶端的通訊；二是遊戲登入使用者的資料處理。對於和客戶端通訊的這個問題，大量的遊戲開發者會使用“通用”的開源元件，比如Protocol Buffer，Thrift，Jetty，Node.js等等通訊或RPC框架。雖然針對遊戲，還是要做大量的改造，但一般都有很多現成的程式碼可供修改。但是對於第二個問題，不管是memcache還是MySQL，或者是Redis，都不能完全滿足遊戲開發者的需求。很多團隊嘗試過各種組合和修改，試圖創造出利用現有開源軟體，建設既能迎合靈活的需求變化，又具備高延遲和高可用的資料處理系統，但最後這些努力基本上都很難圓滿成功。因此我們在遊戲伺服器端程式碼中，還是充斥著大量的記憶體、快取管理，資料同步、落地等等程式碼。而且每個遊戲都要重新去寫一遍這些類似的功能，不能不說一種浪費。

如果我們要想出一種能滿足“遊戲”這個業務領域的資料系統設計，那麼就一定要搞清楚為什麼在如此之多的開源專案和遊戲團隊中，沒能實現完美契合的原因。

01 電子商務/一般網際網路類業務的資料處理流程

Memcache、Redis、MySQL在一般網際網路業務中的應用非常廣泛。而且基本上能很好的應對各種常見的應用場景，包括類似BBS的社群、新聞門戶、電子商務類系統。在企業內部資訊系統中（Intranet），這一類資料軟體也能發揮非常好的功效。由於電子商務類是其中最複雜的系統，所以我在這裡以此為例說明，一般資料處理的流程是如何的。


假設我們瀏覽了一個網店，選中了一個商品，點選了下單這個流程，實際上需要的後臺流程可能是下圖所示：


從上面的分析大概可以總結出幾個特點：

一、忍受延遲：每個操作的延遲要求較低，操作頻率不會太高。一般我們頁面在5秒內開啟，都不會引起太多客戶的抗議。所以，就算我們處理一個請求的時候，後臺進行多次的程式間呼叫，產生的延遲和頻寬消耗也是可以忍受的。

二、線上互動少：網際網路業務大多數是基於瀏覽器的，所以線上使用者之間很少實時互動。

三、資料分散：一般來說，網際網路應用的資料可以在多個不同的業務系統中共用，但是需要專門的業務模組來做管理，以維持資料的一致性。

四、資料變更面廣：系統需要持續處理很多資料變更，網際網路業務有很大一部分資料是來源於普通使用者、網路編輯、店主等等使用者，在使用的過程中，他們會大量的修改系統所儲存的資料。

以上四個特點，導致了我們一般會把後臺要處理的資料，分別用Cache系統和DB系統來處理。並且，我們一般會按業務功能劃分模組，同時也劃分業務系統。由於延遲和線上互動的需求較弱，所以使用大量程式來做模組隔離，依然是非常可行的，總體來說，就是一種比較“分散”的資料使用方式。

02 遊戲類業務的資料處理流程

在各種遊戲中，MMORPG是資料處理最為複雜的一類，也是最典型的一種“重伺服器端”的遊戲型別，因此可以作為遊戲業務中通用性的參考標準。在MMORPG中，我們可以發現，資料的處理需求，和一般網際網路業務大相徑庭，它體現出的是一種明顯的“集中”式的資料處理需求。我們可以從一般MMORPG的伺服器架構中體現出來：


在遊戲業務中，一般我們都會發現以下的特點：

一、延遲敏感：遊戲中使用者會產生大量操作，都要求“實時”進行反饋，所以一般都不能忍受1秒以上的延遲，在大量動作型別的遊戲中，一般都會要求伺服器的反饋時延在50ms左右。因此遊戲開發者都習慣於儘量減少後臺程式間的互動，儘管這對提高系統吞吐量很不利。所以大部分遊戲伺服器端都有一個所謂“GameServer”，裡面執行了遊戲70%以上的功能。

二、大量實時互動：線上遊戲的特點，就是很多玩家可以通過伺服器“看見”彼此，能實時的互動。因此我們必須要把使用者的線上資料，集中到一起，才能提供互相操作的可能；而且A使用者操作B使用者的資料，是最常見的資料操作，所謂戰鬥玩法，就是互相修改對方的資料的過程。

三、資料集中：遊戲是一個幾乎完全虛擬的世界，在遊戲中的資料，實際上很少能在其他系統中產生價值。而遊戲邏輯也禁止通過遊戲以外的方式，修改遊戲的資料。所以遊戲中的資料，一般都會集中存放在單獨的資料庫中。由於沒有資料共用的需求，所以也不需要把GameServer裡面集中的邏輯劃分出很多單獨的程式模組來。

四、資料變更少：實際上游戲的資料變更還是很快的，比如遊戲中的每次中彈，都要減少HP的數值。但是遊戲裡的資料，一般都遵守這樣一個規則：“變化越快的資料，重要性越低”。也就是說，遊戲中是可以容忍一定程度的資料不一致和不完整的。而遊戲中的資料，一般會分成兩類：玩家存檔和遊戲設定。對於玩家存檔來說，其單條資料量一般不大，但會有大量的記錄數，因為每個玩家都會有一個存檔。但是其讀取、修改，一般很典型的和玩家的登入、登出、升級等業務邏輯密切關聯，所以其快取時機是比較容易根據業務邏輯來把握的。而對於遊戲設定資料來說，幾乎只有升級遊戲版本的時候才會修改，大部分執行時是隻讀的，其快取簡單的讀入記憶體就解決問題了。

03 一般的快取系統的特點在遊戲中的問題

根據以上的分析，我們可以看到，普通的快取系統，如memcache和Redis，實際上其特點是不太適合遊戲業務的：

一般跨程式的快取系統，無法解決遊戲要求的低延遲問題。級別是同機房，每次資料存取都需要10-20ms的時間，對於遊戲戰鬥中大量的資料讀、寫來說，是很難接受的。（但是一些回合制戰鬥、低頻操作還是有用的）

通用型的快取系統或者資料庫，一般都比較難集結多個程式，形成一個完整的資料儲存網格。這讓玩家間的互相互動產生了額外的難度，開發者必須先想辦法確定玩家的資料在哪個後臺程式上，然後才能去讀寫。一般的資料庫或快取系統，為了保證資料的一致性或者完整性，往往會需要犧牲一些分散式的能力。而這種犧牲在遊戲業務中，其實是一種浪費，因為遊戲的很多資料都無需這種能力。

通用性資料系統一般不依賴於特定的語言，所以很少能直接把某種“物件”存入到資料系統中。在遊戲開發中，需要儲存的資料結構數量往往是非常大量的：一個普通的遊戲，基本上都會超過100種資料結構。對於每個資料結構，都去建表或者編寫序列化/反序列化配置，是一種非常累人的工作。——明明在程式碼中，已經用程式語言定義了他們的結構，還要重複的搞一次。

根據上面說的這些問題，我們實際上是需要另外一種完全不同設計思想的資料系統。

04 本地分散式快取服務的特點和優勢

對於遊戲業務來說，一個好用的資料系統，應該包括這樣一些特點：

可以利用GameServer程式內的記憶體進行自動化的快取管理。由於GameServer程式往往集中了大部分的邏輯運算，所以大部分的資料快取也應該在這個程式中，這樣才能符合遊戲所需的延遲要求。

自動進行資料落地和容災管理。由於遊戲資料中有大量的“過程資料”，所以其一致性和完整性要求會稍微低於其他業務，所以應該利用這一點，讓GameServer本身也可以是分散式的程式，從而提高系統整體的吞吐量。

具備良好的程式設計易用性。最好是能直接存取程式設計中的物件，避免反覆對資料結構的描述，節省大量的開發時間。

作者：韓大  
來源：騰訊GWB遊戲無界
原地址：https://mp.weixin.qq.com/s/oD_XKrbsp4RnzPyHUdkU6A