摘要： 看GaussDB（for Redis）強擴充套件、高可用、強一致、高安全如何玩轉各大遊戲場景

在結束忙碌工作回家的地鐵上，難得閒暇的週末下午，和朋友再來一局的入睡前……遊戲已經成為了當下大多數年輕人在緊張的工作之餘最普遍的放鬆方式和社交手段之一。而遊戲廠商想要增加使用者粘性，不僅需要在遊戲類別、情節故事、關卡設計上洞察使用者喜好，讓遊戲足夠新穎，更要在流暢程度上帶給使用者更極致的體驗。遊戲場景複雜多樣，應用版本更新迭代，企業的運營成本也水漲船高，這讓各大廠商在遊戲開發過程中都極度重視一個同樣的問題——如何選擇一款可靠的資料庫來支撐龐大的系統穩定執行？

每一款遊戲都要經歷開發、上線、運維等多個環節，在這過程中，資料庫面臨的應用場景非常豐富。不同的應用場景對資料庫的要求也不盡相同，比如跨服對戰對計算算力的要求，線上聊天產生的資料對儲存空間的要求，排行榜實時重新整理對資料可用性的要求……這些具體的遊戲場景都要求資料庫在儲存空間、彈性擴容、資料強一致保障以及成本等各方面都交出滿意的答卷。

在《迷你世界》、《餘燼風暴》等大型遊戲的開發和上線過程中，這些廠商都不約而同地將GaussDB（for Redis）資料庫作為首選。為什麼GaussDB（for Redis）成為了遊戲行業的心頭愛呢？我們不妨先看看在遊戲行業，他們都面臨著哪些共同的痛點，GaussDB（for Redis）有什麼錦囊妙計。

強擴充套件——支援業務高峰期海量玩家線上對戰暢聊

在一款遊戲新開服、活動推廣、重大版本上線或發放點券遊戲幣等時間段，玩家訪問量突增，同時線上人數迅速飈高，這種情況下，往往需要提前增加節點擴算力，高峰期後再縮減節點，如果處理不好，極有可能在擴容時發生長時間業務阻塞，甚至出現遊戲伺服器故障而被迫停服，面臨痛失大量遊戲玩家的風險。

比如《迷你世界》春節期間線上玩家數從平時的百萬級別突增到千萬級，玩家協同創作與聯機遊玩產生大量實時聊天資料，需要儲存空間線上快速擴容。而之前使用的開源Redis基於存算一體架構，儲存擴容需要十幾分鍾，擴容期間大量玩家在協同創作、實時聊天時出現語音訊息發不出、圖片傳輸失敗等問題，持續時間長達十幾分鍾，極大影響了玩家的遊戲體驗，極易造成使用者流失。

龍圖遊戲的大型魔幻手遊《餘燼風暴》採用的是多人跨服對戰的遊戲模式，在大量玩家跨服戰鬥的業務高峰期，資料庫不僅需要穩定支撐10萬級高併發業務，還對算力有一定的要求，需要計算節點達到秒級擴容，才能輕鬆應對海量使用者跨服對戰的流量洪峰。

針對這些場景，GaussDB（for Redis）基於業界首創的存算分離架構，做到了儲存空間的彈性伸縮和秒級擴容，擴容只需修改配額，最高可支援單例項TB級資料1秒擴容8倍，即從1TB擴容到8TB，能滿足所有海量遊戲聊天資料的線上擴容場景，助力千萬級玩家暢聊不卡頓，極大提升玩家交流體驗。計算節點做到分鐘級擴容，擴容僅需修改資料對映，無需搬遷資料，在業務上僅有秒級的時延抖動，支撐《餘燼風暴》業務高峰期單日同時線上玩家數達到百萬級，且玩家資料訪問幾乎不受影響。

強一致——保障多個地圖資料實時一致性

沙盒遊戲是近幾年的熱門遊戲題材之一，這類遊戲常見的玩法有兩種，一種是普通玩家可以進入多個地圖聯機遊玩，透過“方塊”的自由組合，搭建各種場景地圖；另一種是高階玩家與各地玩家聯機，跨區域協同創作地圖，形成全新的小遊戲。

相信不少玩家都遇到過這樣的問題：在遊戲地圖A購買完道具，立即切換到別的地圖以後，開啟揹包發現道具竟丟失了；遇到美女玩家，關注對方後本應自動傳送招呼語，對方卻遲遲沒有收到。

其實主要原因是兩個地圖從不同的節點讀取資料，由於主節點的資料沒有及時同步至從節點，更新存在一定的延遲性，最終導致多個地圖之間的資料不一致。這說明一個問題，無論什麼條件下，遊戲地圖資料必須要實時保持一致，這樣才能為玩家帶來良好的使用者體驗。

面對這種資料不一致的問題，GaussDB（for Redis）是怎麼做的呢？首先不需要主從分離，在儲存使用者資料時，儲存層使用3副本儲存地圖資料，基於一致性共識演算法率先保證所有副本資料的一致性，避免了原有主從結構資料庫在主資料庫宕機後，從資料庫中的地圖資料跟主資料庫中不完全一致的問題。玩家不論是在多個地圖之間遊玩，還是聯機協同創作地圖，都能實時保障資料的一致性，在遊戲的體驗感上得到極大的提升。

資料高可用——支援遊戲排行榜資料實時重新整理

在一款遊戲熱度逐漸高漲或新遊戲上線時，玩家往往對遊戲排行榜的參與感會非常強烈，排行榜的重新整理對資料實時性的要求更強。因為排行榜的變化，資料變動非常頻繁，需要高可用的資料庫保證積分資料的穩定讀取和實時重新整理。

為了保證資料穩定讀取，解決資料庫高可用問題，基於存算分離架構的GaussDB（for Redis）將玩家積分資料統一儲存在儲存池中，而不是儲存在計算節點中，這樣做的好處是，如果某一個計算節點發生故障後，業務將自動將該節點的業務切換到其它計算節點，如下圖所示：

只要叢集中的任一節點存活，就可訪問全量資料（友商採用的存算一體主從架構，單節點掛掉後，上面儲存的積分資料將無法讀取），避免了因為節點故障導致排行榜無法實時重新整理的情況。

高安全——跨地域雙活完整災備輕鬆應對遊戲故障

遊戲場景是典型的網際網路場景，使用者的資料日誌非常之多，一旦發生資料庫宕機、機房斷電、網路故障等情況造成資料丟失，玩家的遊戲體驗將大打折扣。當一個可用區或整個地域意外宕機，需要有其它的可用區和補救措施來及時修復資料，這對系統的安全保障能力和容災能力都提出很高的要求。

GaussDB（for Redis）支援跨地域雙活容災，即在兩個例項之間建立資料同步鏈路，其中主例項支援讀寫，備例項只讀。如下圖所示：

與開源Redis那種簡單的命令轉發不同，GaussDB（for Redis）的雙活方案是基於WAL日誌的資料同步，原理上更類似於MySQL資料庫。在雙活架構中，RsyncServer程序負責資料的全量和增量同步，資料同步鏈路採用華為雲內部高速網路，同Region內僅毫秒級延遲。

GaussDB已經在遊戲行業沉澱出了非常豐富、成功的經驗。在《迷你世界》國產沙盒創意平臺中，GaussDB（for Redis）支撐了多區域TB級別的地圖資料同步更新，助力億級使用者跨區域協同創作，在整體成本相比開源Redis降低60％的同時，儲存使用者畫像總量提升了3倍，保障了千萬級玩家實時聊天資料毫秒級別訪問。龍圖遊戲選擇了GaussDB（for Redis）作為大型魔幻手遊《餘燼風暴》的核心底座，不僅開服首日流水就破千萬，且在業務高峰期單日同時線上玩家數達到百萬級，收穫了眾多玩家的喜愛。

遊戲場景只是網際網路行業中的其中一種通用型場景，這些核心技術和實踐經驗也只是GaussDB資料庫多年來發展成果的冰山一角。GaussDB在技術上的創新和突破從未止步，在千行百業中的探索也一直在路上。

Link：https：//mp。weixin。qq。com/s/ugJux0JqcA4yMo3OpCFmVw

https：//mp。weixin。qq。com/s/PfAfm7sVisjglxtHoZ7x4Q

https：//mp。weixin。qq。com/s/Ol67LAfBJtWItiQnyb9HSQ

……