遊戲服務端架構 - 社交服架構設計之幫會系統

© 內容版權所有，轉載或複製需附源站地址 www.tanjp.com 謝謝合作。

變更記錄

2020-04-27, tanjp, 以幫會系統為例，初步進行社交類系統的架構設計。

在前兩次 分區分服與大規模跨服功能 和 百萬在線的角色服承載能力分析 的設計分析的基礎上，再進入服務端架構的內部進行分析，社交功能服和路由總線的設計分析。

一、需求預設

在進行社交功能服的設計和分析前，要設定一個需求場景，我們就以遊戲中常見的幫會系統來進行討論分析。選擇幫會系統也是有原因的，畢竟遊戲服務端處理的業務場景不同於其他互聯網業務（如 微博，IM聊天，直播，等等），遊戲內的玩法更加註重強交互。下面以幫會系統為例，來分析社交類功能系統的架構設計。

1.1 幫會系統需求

• 玩家可以創建幫會。
• 可以查找一個幫會來加入。
• 可以看到幫會內其他玩家的狀態。
• 幫會內每個玩家都能為幫會做點事情（如 捐獻，做一個小活動A，B，C，等等）。
• 幫會能還能組織一場大型活動玩法（如 幫會成員一起打BOSS，幫會A與幫會B之間的群體戰爭，等等）。

NOTE: 在幫會系統實現上會有很多細節問題，在這裡不是討論怎麼做一個幫會系統，而是藉助幫會系統的設計，來分析如何進行社交類功能系統的架構設計。

1.2 數據預設

還是以之前設定的數據進行分析，【百萬用戶在線】，【千萬日活用戶】，【億級用戶量】。

設定每個幫會的人數上限是 500人，也不可能每個幫會的都會滿員，從以往的經驗來看，也不是所有玩家都會加入幫會。假設 90%的人加入了幫會，也就是 9000萬用戶，每個幫會平均有 300個成員，所以幫會的數量 = 9000萬 / 300個 = 30萬，也就是說1億用戶量，大概就有30萬個幫會。

幫會系統是一個社交系統，它記錄幫會內的所有成員的基本信息，如 名字，等級，職位，捐獻，上下線時間，等等。當然點開每個成員還能看到更加詳細的資料，但是這不是幫會系統的職能，由另外的系統功能來實現，這裡不再深入。

假設一個幫會成員的基本信息，內存佔用 1KB(偏大)，300個幫會成員就是 300KB。加上每個幫會都有一些公共的信息，如幫會名，公告，捐獻值，職位，等等全部加起來估計也不超過 10KB，還有一些歷史數據記錄也算 10KB。

幫會內的聊天信息，其實不屬於幫會系統存儲的數據，一般在實現上幫會只是把人員組織起來，而聊天是交由聊天系統的，幫會聊天的信息是屬於聊天系統的幫會頻道，所以聊天數據不能算進來。

從上面的分析，單個幫會成員數據佔用 300KB，單個幫會的整體數據佔用 10KB + 10KB = 20KB，到目前為止也就是 320KB。為了能夠更徹底的分析社交功能服的設計，我們把幫會玩法數據也計算到幫會數據中來，譬如幫會成員一起打BOSS，需要記錄每個成員的傷害、獎勵、進度，等等。一般來說也不是所以幫會的成員都能參加的，以往的經驗來看，多數是要篩選一部分精英來參加幫會活動玩法，但是我們就不做這種假設。設定所有成員都能參加幫會活動，每個成員都會記錄一些玩法數據，還是設定每個成員 1KB，300個幫會成員就是 300KB。

還有，幫會活動玩法本身的數據，這種數據可能會很大也可能很小，比如如果生成一個非常大的地圖，那就很大了，如果每個地圖，只是簡單的狀態信息，那就很小。這裡還是往更大的壓力去預設，設定為 1MB。

彙總以上的數據進行梳理

• 幫會總的數量為：30萬
• 每個幫會平均人數為：300人(上限是500)
• 單個幫會成員數據佔用：300KB
• 單個幫會的整體數據佔用：20KB
• 單個幫會每個成員進行活動玩法佔用：300KB
• 單個幫會活動玩法進行時環境數據佔用：1MB
• 單個幫會內存佔用為：300KB + 20KB + 300KB + 1MB 約等於(往大算) 2MB

二、幫會系統承載分析

有了上面的數據為依據，就可以分析來如何設計幫會系統。

每個幫會的內存數據佔用 2MB，30萬個幫會，就是 30萬 x 2MB = 600000MB，也就是 600GB左右。

2.1 邏輯功能承載分析

每個進程是由多個 Actor組成（如果不瞭解Actor模式，可以暫且把 Actor 理解為一個線程），我希望每個 Actor 佔用的內存不能太大，不能超過 1GB。因為幫會玩法可能也會有不小的運算量，為了穩妥起見，在一臺 16核的機器上，我們只分配 10個 ActorGuild 用於幫會邏輯。也就是一個幫會邏輯進程佔用 10GB，總的內存佔用為 600GB，也就是需要 60個幫會邏輯進程。這些內存數據，如果全部要落地到數據庫的話，也就是 600GB，每個數據庫 20GB的話，30個庫即可。

前面已經分析得到結論，用 60個幫會邏輯進程(每個進程10個ActorGuild，每個Actor內存佔用 1GB)，來承載 30萬個幫會的邏輯運算和數據處理。然後，我面來分析分析，幫會大廳怎麼來做？

在加入幫會之前，用戶要麼加入已有的幫會，要麼創建新的幫會，所以需要一個幫會大廳的功能。總共30萬個幫會，要通過搜索（可通過算法來提高效率）查找到自己想要加入的幫會，這就是幫會大廳的功能。每個幫會的概要信息，一般來說都很小，我們就假設為 1KB，30萬 x 1KB = 300000KB，也就是 300MB左右。用 MongoDB 存儲的話，一個 document 足夠。

先來，確定幫會大廳的職責是什麼？

2.2 幫會大廳的職責

• 創建新的幫會。
• 給用戶推薦一批幫會，讓他們選擇加入。
• 提供搜索功能，讓用戶找到自己想加入的幫會。
• 提供接口服務，如 用戶在哪個幫會？哪個幫會進程上？

以上的需求，邏輯上並不複雜，當然也不能輕視，一不小心就搞砸了。

方案一：由一個單點幫會大廳進程來負責上面的功能，如果進程掛了，頂多就是創建不了幫會，加不了幫會。對於已經加入幫會的玩家，也沒太多影響（當然用戶在哪個幫會，哪個進程，要預先用 Redis 緩存起來）。然後通過故障處理機制，重新啟動新的幫會大廳進程即可又重新提供服務。這個方案的優點就是簡單，缺點是有可能部分功能不可用，還有如果推薦和搜索算法優化不夠好的話，性能上也會有點問題。

方案二：由多個幫會大廳進程也就是幫會大廳集群來負責上面的功能，很明顯，一個進程掛了，還有另一個，可用性非常高。很明顯，這個方案的優點就是可用性非常高，如果負載均衡做好的話，性能也很高。缺點也很明顯，就是複雜。譬如，創建幫會要進行分佈式鎖（幫會名要唯一不？），仔細想想，也沒有太複雜，也是挺好做的。

三、幫會系統整體架構設計

3.1 數據彙總

• 在線1百萬，日活1千萬，總用戶量1億
• 用戶加入幫會百分比：90%(9000萬人)
• 每個幫會平均人數為：300人(上限是500)
• 幫會總數量：30萬
• 單個幫會內存佔用為：2MB
• 幫會系統總內存佔用：600GB
• 幫會邏輯進程的數量：60個
• 單個幫會邏輯進程內存佔用：10GB
• 單個幫會邏輯服的單個ActorGuild佔用：1GB(10個Actor)
• 幫會邏輯數據庫數量：30個
• 單個幫會邏輯數據庫大小：20GB
• 幫會數據存儲進程DBS數量：15個
• 單個幫會信息在幫會大廳中的內存佔用：1KB
• 幫會大廳總的數據量：300MB

3.2 架構設計圖

3.3 幫會大廳集群

三個節點的幫會大廳，提供無狀態服務，由路由總線負責負載均衡和服務治理。幫會大廳中必要的數據狀態，緩存在 Redis 集群，大廳的邏輯數據通過幫會主存儲GuildDBS來讀寫到 MongoDB。

3.4 幫會邏輯功能

一旦確定了玩家要與之交互的某一個幫會（在哪個幫會ID，在哪個進程ID），邏輯功能就轉向具體的某一個幫會邏輯進程，後面的運算壓力就轉向了某個進程，也就達到了壓力分攤的效果。

4個幫會邏輯進程連接 1個幫會存儲DBS，1個幫會存儲DBS連接兩個幫會數據庫，也就是說 1個DBS有可能讀寫 40GB的數據。

為了更加統一和高效地獲取【角色ID】，【幫會ID】，【進程ID】的三者之前狀態信息，將狀態數據分散緩存到 Redis 緩存中。

3.5 可用性如何

從上面的架構圖中，可以看到，如果 DBS1由於各種原因，無法提供服務了，那怎麼辦？導致的結果就是 幫會邏輯進程1，2，3，4的數據讀寫失敗，也就是說四個幫會進程無法正常提供服務。每個進程5000個幫會，4個進程就是2萬個幫會，2萬 / 30萬 = 6.67%的用戶受到影響。如果覺得不能接受，可以把 DBS 的數量增多，可以跟幫會邏輯進程一樣多，也就是 60個，如果一個DBS無法提供服務，那就是 1.67%的用戶受影響。甚至也可以把DBS的數量增多到是幫會邏輯進程的 2倍，2個DBS為一個邏輯進程提供服務，這時一個DBS進程無法服務，另一個DBS還能繼續。

但是，這樣會導致整體架構非常龐大臃腫，幫會系統只是整個遊戲玩法中的一小部分，還有很多其他玩法系統，如果每一個都提供冗餘功能的話，整體維護成本會非常高，從而導致整體的經濟效益反而減少。

四、衡量遊戲架構的【可用性】

在做架構設計時，高可用往往都是我們追求的目標，可是面向遊戲服務端的架構，不能一味追求最高的可用性，要有整體的經濟效益考慮。

一款遊戲其中的玩法系統，可能會有幾個核心玩法，十幾個輔助玩法，又有很多基礎組件（如聊天，郵件，好友，等等）。能直接產生流水的，往往就是最基本功能，如商店，消費活動，抽卡，等等。想幫會的玩法可能會掉落一些稀有物品，對玩家來說這是有效益的。但是，對於遊戲研發或者運營，這只是非常間接的虛擬商品，如果玩家由於系統崩潰導致物品丟失，隨時可以通過GM進行補發，甚至可以說多發一些彌補也是很正常的，也就是說遊戲內的生態是虛擬的，是間接的經濟效益，可以通過很多手段來彌補。而對比於電商平臺，直播平臺，這些系統的運作是真真實實的經濟效益。

當然啦，間接的經濟效益只是說明我們可以有很多手段來彌補，而跟實際經濟效益相關的就是充值流水和活躍人數。

在設計遊戲服務端的整體架構時，要考慮整體的經濟效益，也就是說，登錄和充值必須是優先保證高可用的。而像上面所說的幫會系統，如果是一個單點的幫會大廳，如果出問題就是所有人都不可用，這帶來的用戶體驗非常差。並且在設計上，也是比較容易實現多點的集群，所以幫會大廳採用了集群的模式。而幫會邏輯進程，存儲進程，幫會邏輯數據庫，等都只是提供了一小部分的用戶服務，如果這些不可用，可以通過其他很多手段來彌補或者修復。所以，在設計這類型的功能玩法時，不是通過冗餘的方式來提高可用性，因為冗餘會帶來整體架構的複雜度大增。

遊戲服務端的可用性設計原則

1. 影響在線活躍和充值流水的，儘可能高可用。
2. 影響大多數用戶體驗的，儘可能高可用。（如 幫會大廳）
3. 關鍵核心的玩法，要求整體可用性較高，允許部分不可用，最好重試能恢復。（如 王者榮耀開啟一次PVP失敗了，再點一次又可以）
4. 非核心功能，不做冗餘，不嚴格要求高可用，只要儘量通過各種手段進行恢復。（如 幫會系統的部分邏輯進程）

© 內容版權所有，轉載或複製需附源站地址 www.tanjp.com 謝謝合作。