在結束忙碌工作回家的地鐵上，難得閑暇的周末下午，和朋友再來一局的入睡前......游戲已經(jīng)成為了當下大多數(shù)年輕人在緊張的工作之余最普遍的放松方式和社交手段之一。

而游戲廠商想要增加用戶粘性，不僅需要在游戲類別、情節(jié)故事、關卡設計上洞察用戶喜好，讓游戲足夠新穎，更要在流暢程度上帶給用戶更極致的體驗。游戲場景復雜多樣，應用版本更新迭代，企業(yè)的運營成本也水漲船高，這讓各大廠商在游戲開發(fā)過程中都極度重視一個同樣的問題——如何選擇一款可靠的數(shù)據(jù)庫來支撐龐大的系統(tǒng)穩(wěn)定運行？??

每一款游戲都要經(jīng)歷開發(fā)、上線、運維等多個環(huán)節(jié)，在這過程中，數(shù)據(jù)庫面臨的應用場景非常豐富。不同的應用場景對數(shù)據(jù)庫的要求也不盡相同，比如跨服對戰(zhàn)對計算算力的要求，在線聊天產生的數(shù)據(jù)對存儲空間的要求，排行榜實時刷新對數(shù)據(jù)可用性的要求......這些具體的游戲場景都要求數(shù)據(jù)庫在存儲空間、彈性擴容、數(shù)據(jù)強一致保障以及成本等各方面都交出滿意的答卷。

??在《迷你世界》、《余燼風暴》等大型游戲的開發(fā)和上線過程中，這些廠商都不約而同地將 GaussDBforRedis 數(shù)據(jù)庫作為首選。為什么 GaussDBforRedis 成為了游戲行業(yè)的心頭愛呢？我們不妨先看看在游戲行業(yè)，他們都面臨著哪些共同的痛點，GaussDBforRedis 有什么錦囊妙計。

?強擴展—支持業(yè)務高峰期海量玩家在線對戰(zhàn)暢聊?

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

??比如《迷你世界》春節(jié)期間在線玩家數(shù)從平時的百萬級別突增到千萬級，玩家協(xié)同創(chuàng)作與聯(lián)機游玩產生大量實時聊天數(shù)據(jù)，需要存儲空間在線快速擴容。而之前使用的開源 Redis 基于存算一體架構，存儲擴容需要十幾分鐘，擴容期間大量玩家在協(xié)同創(chuàng)作、實時聊天時出現(xiàn)語音消息發(fā)不出、圖片傳輸失敗等問題，持續(xù)時間長達十幾分鐘，極大影響了玩家的游戲體驗，極易造成用戶流失。

??龍圖游戲的大型魔幻手游《余燼風暴》采用的是多人跨服對戰(zhàn)的游戲模式，在大量玩家跨服戰(zhàn)斗的業(yè)務高峰期，數(shù)據(jù)庫不僅需要穩(wěn)定支撐 10 萬級高并發(fā)業(yè)務，還對算力有一定的要求，需要計算節(jié)點達到秒級擴容，才能輕松應對海量用戶跨服對戰(zhàn)的流量洪峰。

??針對這些場景，GaussDBforRedis 基于業(yè)界首創(chuàng)的存算分離架構，做到了存儲空間的彈性伸縮和秒級擴容，擴容只需修改配額，最高可支持單實例 TB 級數(shù)據(jù) 1 秒擴容 8 倍，即從 1TB 擴容到 8TB，能滿足所有海量游戲聊天數(shù)據(jù)的在線擴容場景，助力千萬級玩家暢聊不卡頓，極大提升玩家交流體驗。計算節(jié)點做到分鐘級擴容，擴容僅需修改數(shù)據(jù)映射，無需搬遷數(shù)據(jù)，在業(yè)務上僅有秒級的時延抖動，支撐《余燼風暴》業(yè)務高峰期單日同時在線玩家數(shù)達到百萬級，且玩家數(shù)據(jù)訪問幾乎不受影響。

?強一致—保障多個地圖數(shù)據(jù)實時一致性

???沙盒游戲是近幾年的熱門游戲題材之一，這類游戲常見的玩法有兩種，一種是普通玩家可以進入多個地圖聯(lián)機游玩，通過“方塊”的自由組合，搭建各種場景地圖;另一種是高階玩家與各地玩家聯(lián)機，跨區(qū)域協(xié)同創(chuàng)作地圖，形成全新的小游戲。

??相信不少玩家都遇到過這樣的問題：在游戲地圖 A 購買完道具，立即切換到別的地圖以后，打開背包發(fā)現(xiàn)道具竟丟失了;遇到美女玩家，關注對方后本應自動發(fā)送招呼語，對方卻遲遲沒有收到。

??其實主要原因是兩個地圖從不同的節(jié)點讀取數(shù)據(jù)，由于主節(jié)點的數(shù)據(jù)沒有及時同步至從節(jié)點，更新存在一定的延遲性，最終導致多個地圖之間的數(shù)據(jù)不一致。這說明一個問題，無論什么條件下，游戲地圖數(shù)據(jù)必須要實時保持一致，這樣才能為玩家?guī)砹己玫挠脩趔w驗。

??面對這種數(shù)據(jù)不一致的問題，GaussDBforRedis 是怎么做的呢？首先不需要主從分離，在存儲用戶數(shù)據(jù)時，存儲層使用 3 副本保存地圖數(shù)據(jù)，基于一致性共識算法率先保證所有副本數(shù)據(jù)的一致性，避免了原有主從結構數(shù)據(jù)庫在主數(shù)據(jù)庫宕機后，從數(shù)據(jù)庫中的地圖數(shù)據(jù)跟主數(shù)據(jù)庫中不完全一致的問題。玩家不論是在多個地圖之間游玩，還是聯(lián)機協(xié)同創(chuàng)作地圖，都能實時保障數(shù)據(jù)的一致性，在游戲的體驗感上得到極大的提升。

數(shù)據(jù)高可用—支持游戲排行榜數(shù)據(jù)實時刷新

??在一款游戲熱度逐漸高漲或新游戲上線時，玩家往往對游戲排行榜的參與感會非常強烈，排行榜的刷新對數(shù)據(jù)實時性的要求更強。因為排行榜的變化，數(shù)據(jù)變動非常頻繁，需要高可用的數(shù)據(jù)庫保證積分數(shù)據(jù)的穩(wěn)定讀取和實時刷新。

??為了保證數(shù)據(jù)穩(wěn)定讀取，解決數(shù)據(jù)庫高可用問題，基于存算分離架構的 GaussDBforRedis 將玩家積分數(shù)據(jù)統(tǒng)一存儲在存儲池中，而不是存儲在計算節(jié)點中，這樣做的好處是，如果某一個計算節(jié)點發(fā)生故障后，業(yè)務將自動將該節(jié)點的業(yè)務切換到其它計算節(jié)點，如下圖所示：

??只要集群中的任一節(jié)點存活，就可訪問全量數(shù)據(jù)（友商采用的存算一體主從架構，單節(jié)點掛掉后，上面存儲的積分數(shù)據(jù)將無法讀?。?，避免了因為節(jié)點故障導致排行榜無法實時刷新的情況。

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

??游戲場景是典型的互聯(lián)網(wǎng)場景，用戶的數(shù)據(jù)日志非常之多，一旦發(fā)生數(shù)據(jù)庫宕機、機房斷電、網(wǎng)絡故障等情況造成數(shù)據(jù)丟失，玩家的游戲體驗將大打折扣。當一個可用區(qū)或整個地域意外宕機，需要有其它的可用區(qū)和補救措施來及時修復數(shù)據(jù)，這對系統(tǒng)的安全保障能力和容災能力都提出很高的要求。??GaussDBforRedis 支持跨地域雙活容災，即在兩個實例之間建立數(shù)據(jù)同步鏈路，其中主實例支持讀寫，備實例只讀。如下圖所示：

??與開源 Redis 那種簡單的命令轉發(fā)不同，GaussDBforRedis 的雙活方案是基于 WAL 日志的數(shù)據(jù)同步，原理上更類似于 MySQL 數(shù)據(jù)庫。在雙活架構中，RsyncServer 進程負責數(shù)據(jù)的全量和增量同步，數(shù)據(jù)同步鏈路采用華為云內部高速網(wǎng)絡，同 Region 內僅毫秒級延遲。

??GaussDB 已經(jīng)在游戲行業(yè)沉淀出了非常豐富、成功的經(jīng)驗。在《迷你世界》國產沙盒創(chuàng)意平臺中，GaussDBforRedis 支撐了多區(qū)域 TB 級別的地圖數(shù)據(jù)同步更新，助力億級用戶跨區(qū)域協(xié)同創(chuàng)作，在整體成本相比開源 Redis 降低 60%的同時，存儲用戶畫像總量提升了 3 倍，保障了千萬級玩家實時聊天數(shù)據(jù)毫秒級別訪問。龍圖游戲選擇了 GaussDBforRedis 作為大型魔幻手游《余燼風暴》的核心底座，不僅開服首日流水就破千萬，且在業(yè)務高峰期單日同時在線玩家數(shù)達到百萬級，收獲了眾多玩家的喜愛。

??游戲場景只是互聯(lián)網(wǎng)行業(yè)中的其中一種通用型場景，這些核心技術和實踐經(jīng)驗也只是 GaussDB 數(shù)據(jù)庫多年來發(fā)展成果的冰山一角。GaussDB 在技術上的創(chuàng)新和突破從未止步，在千行百業(yè)中的探索也一直在路上。

審核編輯：湯梓紅