遊戲思考15：全區全服和分區分服的思考

一、全區全服特點

1）架構圖

2）特點

1）全區全服就只有一個DB
2）全區全服沒有分區的概念，但它會有一個中心通信模塊，並且整個大區在邏輯上只有一個DB
3）全區全服畫出了很多業務進程

3）關於拆分多進程業務的作用

多進程當業務進程的必要性

二、分區分服特點

1）架構圖

2）特點

1）分區分服的每個服都有獨立的DB
2）分區分服模型一般在前端會有一個導航模塊，用於區服選擇
3）區與區之間如果需要通信的話，往往會使用跨服模塊,對於一些需要跨服的功能，比如包含所有區的排行榜，可能還會為此增加一個公共DB(或直接存在對應服務器的內存上)。
4）從業務邏輯來看，分區分服架構裏每個區只畫了一個「World」
5）分區分服架構下，大家認為每個區玩家數量比較少，也有可能受限於開發時間、開發資源、技術儲備等原因，沒有把業務邏輯拆分得足够細，因此一般只有一個「World」，或者把遊戲邏輯放在少數幾個進程當中。
6）分區分服中單機容量可能受限，我們建議要適當考慮平行擴容相關的設計。像剛才說的單個「world」做平行擴容比較困難，是不是可以把核心邏輯拆分出來，也做成單個進程做單種業務的服務器
7）全區全服可以共享機器。我們知道，遊戲後臺會有很多進程，但每個進程的資源消耗其實不一樣。而我們雖然會有很多區，但做運營活動時，每個區參與的用戶數量可能會有所區別。如果采用全區全服的方式，我們就可以共享機器資源(會導致對資源調度、動態擴縮容和容灾備份的要求較高)

三、兩者的對比選擇

1）盡量選擇全區全服的設計方式，優點如下：

①後續運營運維成本會比較低，因為它物理上只有一個環境，我們投入的運維人力更可控。
②全區全服可以共享機器。我們知道，遊戲後臺會有很多進程，但每個進程的資源消耗其實不一樣。而我們雖然會有很多區，但做運營活動時，每個區參與的用戶數量可能會有所區別。如果采用全區全服的方式，我們就可以共享機器資源
缺點：

這也會導致對資源調度、動態擴縮容和容灾備份的要求較高。

2）兩者在架構上的區別

（1）存儲方式的不同，導致需要在DB層做區分：全區全服就只有一個DB，但是分區分服的每個服都有獨立的DB。
（2）遊戲類型的不同，導致數據互通性不同；邏輯服務器頁遊必要作區分，比如各個平臺需要獨立運營，獨立結算，開服活動只能針對特定服等等；
（3）單服承載的玩家數量級不同，導致架構上調整：全區全服所有玩家在一個服，分區分服玩家分攤在各個不同服，單服玩家數量不在一個級別，導致架構上的考量不同。

3）後臺壓力的區別

（1）DB層承載壓力不同：分區分服DB承載單服壓力，一般遊戲單服PCU是千級，甚至百級，DB讀寫壓力小，采用MySQL基本滿足要求；全區全服DB承載所有玩家，PCU達到百萬級別，讀寫壓力大，單一的MySQL不能滿足讀寫壓力，需要因為讀寫並發高的DB組件，比如互娛的Tcaplus，TEG的CMem等等。
（2）平滑擴容：全區全服的擴容是因為整個遊戲後臺，在外網不停機擴容中，需要考慮擴容對整個後臺的影響，而分區分服因為面臨擴容機會少，有開服情况，也是獨立的新建整個服，對其他服基本無影響；
（3）容灾方面：全區全服在某個服務器進程出現問題時，該模塊的壓力可能會偏向同等功能的其他進程，需要處理雪崩情况，避免影響全服。而分區分服因為天然的服與服之間的隔離性，在這一塊壓力小很多；

四、隨意留言

有的騰訊遊戲會利用tredis去做全區全服，redis的讀寫速度如果磁盤是500MB/s，真正的讀寫速度能達到480-490MB/s，但是之後一段時間的存儲io寫磁盤的卡頓，會掉到50-80MB/s，這樣的速度才能滿足單DB對於全區全服服務器的要求，但是普通小公司就沒有tredis這種隨時宕機都能恢複數據的平臺工具，一般都會采用mysql去存，而mysql集群的存儲速度也會控制在500MB/s，需要做成協程配合進程的方式，如果不能改成异步協程鏈接mysql，那就需要做成多進程連接mysql或開線程池連接mysql的方式