摘要：而滾服游戲則一般會設計游戲在線上限，比如，達到上限則新開一組服務器，并引導用戶進入新區。這就導致了新服一開，玩家即蜂擁而至，爭先恐后練級升裝備，以求最快速進入排行榜前列，如果努力一番發現落后了，可能就只能坐等下一個新服。

原文地址-石匠的Blog:http://www.bugclosed.com/post/12

近幾年的游戲行業中，出現了各種各樣的滾服游戲，包括頁游，手游，H5游戲等等。滾服游戲和大服游戲的區別在于同時游戲人數，大服游戲是有很多用戶在一起玩，甚至幾十上百萬玩家。而滾服游戲則一般會設計游戲在線上限，比如3000，達到上限則新開一組服務器，并引導用戶進入新區。

滾服模式是游戲類型，技術架構和急功近利的坑錢策略等因素共同決定的，大服游戲包括絕大部分端游，以及類COC這樣類型的游戲。另外，雖然像英雄聯盟，王者榮耀這樣的游戲也分服架構，但是這個并不是我理解中的“滾服游戲“，首先他們雖然分服，但是每個服的人數上限也是可以高達幾十萬，他們并不會發生頻繁的合服情況。而滾服游戲更多是通過游戲策略設計，鼓勵玩家花錢走捷徑透支游戲生命周期，甚至幾天即可獨霸一個服務器。從而導致其他玩家望塵莫及，即使是花錢追也性價比極低，還不如進入一個新服重新開始。這就導致了新服一開，玩家即蜂擁而至，爭先恐后練級升裝備，以求最快速進入排行榜前列，如果努力一番發現落后了，可能就只能坐等下一個新服。這也導致了新服人數火爆，老服慢慢變成人煙凋零的村服，甚至沒人的死服。 為了能夠節約服務器帶寬資源，同時讓少數剩余的玩家能夠玩得起來，就必須要要進行頻繁的合服，把若干個互不相干的服務器玩家，合并到一個服里面；這樣又開啟一波玩家競爭和收割。

前面提到滾服和大服兩種模式，不管是哪種模式，合服的是時候，是需要將多個服的游戲數據合并在一起。不論數據庫采用的是mysql，redis或者mongodb，數據庫表的合并都是需要做到多服數據合并后的相容問題，不發生沖突或者遺漏。比如mysql，需要保證各個表合并時主鍵不沖突，如果業務有昵稱不重復的設定，還需要保證昵稱不重復。有時候合并還需要刪除僵尸數據，此時需要注意刪除的數據之間的邏輯關系是否一并清除，不能導致數據不一致，比如清除了一個半年不上線的玩家賬號數據，但是在好友或者幫派中還殘留關系。

業務模式在一定程度上會決定技術的選型，在滾服模式里面，游戲的在線人數要求都比較低，通常一個單進程架構就足以支持。所謂單服架構，并不一定整個后臺只有一個服務器進程，可能會有其他輔助進程，但是主游戲邏輯只會有一個進程，同時架構也不支持游戲進程伸縮，達到該進程或者物理服務器上限，即從運營上重新開服，引導新的玩家進入新區，單服架構可以簡單理解為如下架構模式：

從圖中可見，每組服務器有自己獨立的游戲進程和數據庫，不同服務器之間的用戶是物理隔離的。該架構的優勢是簡單易開發，服務器獨立隔離，某組服務器需要停服調整或者宕機，不會影響其他服。缺點也來自單服獨立部署，每次開新服都要重新部署數據庫和游戲服務整套環境。合服的時候需要進行數據庫的物理合并和遷移。

單服架構下的合服，需要進行物理數據庫表的硬合并，需要注意主鍵字段是否沖突?？梢酝ㄟ^兩種方法防止主鍵沖突：

合服的時候對所有主鍵進行修改，特別是uid，保證他們來自不同空間。

在設計之初即考慮合服的問題，從而數據在分配唯一uid的時候，即可為每個服進行分段處理，保證從一開始各個服的主鍵uid即不會沖突。

合服的步驟和操作一般都比較固定，成熟后可以針對自己特定的業務模式和表結構寫腳本統一處理。

大服架構區別于單服架構是可以承載更多在線玩家，同時還有一定的伸縮性，一定程度上可以通過不斷部署新服務器來擴充在線容量。在滾服模式的游戲中，也可以采用大服的設計思路和架構，從而在運維管理和合服方面得到極大便利，架構示意如下：

當然，該示意圖和端游的分布式架構圖有相似之處，但是也有所區別，因為此處的業務場景是用在滾服游戲中。該架構是一個原理說明示意，并非是線上運營架構，不同開發者會有不同的具體思路和設計偏好，比如還有類似好友，工會等并未列出，此處僅進行原理說明分析。
從圖中可以看出，有多個不同的角色，說明如下：

數據庫，整個架構下只有唯一的DB，所有數據都集中保存；

DBServer，所有對數據庫的操作都是通過DBServer進行，確保業務邏輯對數據庫設計細節的分離;

Account/Name，對用戶ID或者昵稱的唯一性做保證，這個服務是全大區唯一;

GameServer，游戲邏輯服務，此處每個GameServer即是一個邏輯服，通過不斷部署新的GameSever即實現了開服；

Login，登錄邏輯和選路分配，此處是一鍵合服的關鍵所在，在合服策略配置里面保存了哪個服分配的哪個GameServer游戲進程地址，只需要通過調整這個策略配置即可控制用戶進入的GameServer進程；

大服架構用戶登錄流程：

用戶在客戶端能登陸界面選擇3服的入口，并點擊進入游戲。

Login模塊收到用戶進入s3的請求，從合服策略配置中查詢到s3的GameServer入口地址，返回。

客戶端收到s3的GameServer地址，直接發起到s3的鏈接請求。

GameServer3 處理登錄請求，并從DBServer獲取用戶信息返回給用戶，沒有信息則創建新角色。

登錄完成，進入了s3服。

單服架構的合服，之所以要進行數據處理和遷移，主要是2個原因：

各個服數據庫處于分離狀態，需要物理合并到一起

主鍵唯一ID等信息有沖突，需要數據庫修復處理

因為這2個原因，導致單服合服需要做大量的數據處理，導出，拷貝，遷移等，加大了合服操作的流程復雜度和出錯的可能。從大服架構圖可以發現，單服架構的2個合服難處已經自然消除了。Account分配唯一ID，在DB里面存儲自然不會沖突；而且數據本來就放在一個庫里面的，不存在需要遷移的問題。

通過以上分解可以發現，現在合服會極其方便；不用修改和遷移數據，甚至都不用停服，只需要通過一個工具在合服策略配置庫里面對選路信息進行修改，修改用戶的登錄的游戲服務器。比如提供一個web修改頁面，選擇s1，s2，s3服合并，默認合并后由gameserver1提供服務，gameserver2和gameserver3即可停止下架，只需要一個http請求，將s2，s3的gameserver地址修改成gameserver1，即實現了合并。
合服后用戶登錄流程：

用戶還是選擇3服的入口登錄游戲。

Login模塊得到用戶要進入s3服，查詢合服策略配置，得到s3服的服務地址，即gamesrver1，返回。

用戶得到gameserver1的地址，發起鏈接請求，進行登錄。