阿里云原生內存數據庫Tair在游戲場景的應用,阿里云emr數據

阿里云原生內存數據庫Tair在游戲場景的應用

內容簡要：

一、游戲系統中的Redis

二、云原生內存數據庫Tair介紹

三、Tair的游戲場景

一、游戲系統中的Redis

（一）Redis In Gaming Servers ：分區分服

游戲的架構非常多，總結來看基本有三種，第一種是分區分服的游戲，第二種是全區全服，第三種是全球同服。最近全同服的游戲比較火，線上做了很多收割，而分區分服也適用于一些游戲場景。

Redis的使用場景可以分為兩種，一種場景是當緩存使用，另一種場景是當內存數據庫使用。Redis的使用場景在國內外的定位是不一樣的，在國外大多數Redis都是作為緩存使用，但在國內，可以說70%的用戶是當做內存數據庫。

下面就用一個分區分服的場景來介紹下Redis的典型用法。

在游戲登錄的時候，這些關系型數據，包括用戶數據、用戶賬單、計費記錄等肯定是在關系型數據庫里。這里Redis的特點是，比如有一個注冊活動或者新服開放，當大量的用戶進來后，我們就需要使用一些緩存來抗住壓力，

所以這里的Redis的使用主要是緩存場景。

第二塊是分區分服里最核心的GameServer。

GameServer是一個強內存的計算型服務，它不會有核心的服務在數據庫里面，但它的一些周邊服務，比如排行榜，還有一些通用的服務，比如分布式鎖，對戰匹配，選角記錄等都通常放到Redis里邊。

還有一塊是圖中間的部分。當GameServer變更到一些數據，如游戲用戶的經驗變化，游戲獲得的裝備，這些核心關鍵數據也是存入關系型數據庫，因為這些東西都是游戲資產，上方紅色部分的場景在RDS里是做緩存。

除此之外還有一些周邊系統，在這種分區分服游戲里，一般也有一些跨服對戰。消息隊列，mailbox等。這些數據也經常放在Redis中，使用方便，性能也很好。

還有最后一塊是上圖右下角的部分，游戲公司經常會做一些活動，比如做一些宣傳，還有類似于防作弊、防木馬的情況，需要把用戶日志落盤，這個每天生成的數據量很大，一般都會放到一個Data Warehouse或者一個分析型數據庫如ADB里面供后續挖掘。此時游戲公司還需要分析活動是否成功，是否需要做投放，Redis在這里提供工單緩存/分析加速。

以上是Redis在分區分服游戲中的一些使用場景。

（二）Redis In Gaming Servers：全球同服

另一個是最近熱門的全球同服場景，上圖是它最基本的技術架構。

全球同服的特點是，所有的國內外節點都是訪問了同一份數據庫。游戲行業的一個特點是對數據庫的性能要求并不高，但是對網絡和計算的要求非常高。在游戲行業里，我們常說最遠的距離可能不是數據到數據庫的距離，而是“電信到聯通”的距離。在這種全球同服游戲架構里，有一個很復雜的問題就是數據既然集中了存儲在一個地方，那么在長距離訪問時就會遇到嚴重的體驗問題。實際上，在這種全球同服的游戲架構里，它都會有一個Cache Svr，把遠端的數據都緩存在本地，然后讓本地的訪問去增刪查改它，降低訪問時延，這是全球同服游戲架構里的一個核心技術。在cache server技術中，由于Redis本身可以作為很好的緩存，所以這里使用得比較多一點。

由于數據是集中式存儲，當所有游戲用戶都去訪問一個大數據庫的時候，要求還是很高的。對于Redis而言，一般都有一個Redis Cluster可以提供訪問。

以上是Redis在全球同服游戲里的使用場景。

（三）游戲對Redis的要求

如果游戲要用做高速存儲、內存數據庫等，那么它對Redis有哪些要求

首先，對數據庫的要求是可靠性。對于Redis來說，在電商場景和游戲場景中可靠性要求都很高，但是在例如鏈路管理上還是差別較大。例如，對于電商體系而言，鏈路管理的特點是出問題就斷，寧可返回一個錯誤的結果，也不會Block，因為所有的電商鏈路都是No Blocking，出現問題斷了就好，下次再處理。但是游戲行業不一樣，它需要很好的鏈路保持能力，可以慢慢解決，但是鏈接不能斷，因為斷了之后后端的業務就斷掉了，業務層還掛著各種游戲的資源信息等，這是游戲行業跟電商行業不一樣的一個地方。

一般情況下，很多游戲數據庫平均的訪問量都不大，但是不能出問題，第一是鏈路不能斷，第二是如果扛不住的時候，要求能夠平滑擴縮容。它對平滑性的要求特別高，因為當一個游戲突然火了，或者剛開服時有很多用戶去注冊登錄的時候形成注冊風暴，會發生大量擴容的行為，如果在擴容速度或者平滑性上有所欠缺，那么用戶體驗就特別差。

另外，在做一個全球同服游戲的時候需要考慮容災和多活的能力。高可靠性對數據庫類似于保險，抗熱點、抗壓力是保險，平滑擴容也是保險。

游戲對數據庫有高可運維的要求。電商數據庫基本不會涉及太多的運維，因為每天的工單，包括交易，購物，交易快照等都是存下來的，最多索引一下，不會來回搬數據。但是對游戲而言，由于每天產生的數據和日志特別多，并且游戲運營迭代特別快，比如有些分區分服的游戲，尤其做滾服、合服，迅速開一個新的服務器，把數據庫導過去，然后去滾動，這些游戲運營模式對數據運維要求特別高。當游戲用戶反饋說在游戲中丟了東西，我們需要幫他進行查找，因此需要支持數據恢復，還有內省、清洗等。

此外還有低成本。游戲行業有很明確的冷熱效應，游戲剛開始特別火，等游戲熱度慢慢降下來之后，需要迅速把數據存下來換出去，降低運營成本，這也是非常關鍵的一點。低成本考察的是介質，像Redis這種數據庫，如果數據量都放到內存里，那么成本一定比較高。有一塊節省成本的措施是極致彈性，比如今天游戲做活動，我們把數據給彈上去，明天再拆下來，只要有足夠彈性，那么成本是可控的。

最后是快速開發。游戲行業的在開發上的特點是快速迭代，競爭比較激烈，推出游戲的速度特別快，如果成功，則馬上準備下一版，不成功就很快收掉做下一個游戲。所以如果有框架支持，更多的API，提供更多的封裝和語法糖，那么它可以很迅速地搭建適合自己的游戲體系。

二、云原生內存數據庫Tair介紹

云原生內存數據庫Tair（Redis企業版）是阿里云推出的支持高并發低延遲訪問的云原生內存數據庫，完全兼容Redis數據結構和API。支持主從與集群架構，采用多樣存儲介質應對不同數據溫度場景，并提供全球多活、數據閃回和豐富的數據模型等特性，致力于幫助客戶構建在線實時場景。

Tair兼容了Redis的數據結構，那么面向游戲行業，和Redis的差別主要是什么呢

首先是容災方面，開源的自建Redis沒有很可靠容災，但阿里云Tair通過可靠的高精度容災模塊，能夠做到快速容災，比如10秒級就可以切換掉一個有問題的數據庫。

第二個是鏈接保持能力，游戲領域對鏈接保持的需求很高，這和電商、直播等領域不太一樣。Tair通過代理層的熱升級能力，將鏈接盡可能保持，確保了升級、宕機等多種情況下的可用性。

第三，一般數據庫做容災就是主備容災，用Redis的時候也可以搭個主備出來，阿里云Tair除了采用多可用區容災或跨可用區容災之外，還提供了跨域多活容災的能力。注意的是跨域容災不一定是多活，但多活一定是跨域容災。

還有就是備份，備份很關鍵，可以防止刪庫跑路等情況。游戲行業的特點是發版本的速度特別快，如果版本發錯則需要快速回滾。Tair提供任意時間點的數據恢復，當游戲廠商發現發布的版本有問題，可以馬上回滾，降低影響。除此之外，Tair還支持秒級數據閃回這樣更精密的數據回滾能力，可以指定過去任意秒級時間點按key/key pattern或者全量恢復數據。

在這種日常運維中，可觀測性是需要建設的重點，業務在運行中不可避免會遇到實時熱Key、大Key。由于游戲迭代速度很快，質量方面難免偶爾出現問題，我們能夠通過實時和歷史Key分析快速找到這些瓶頸并解決問題。在Tair中除去能夠迅速觀測到熱點，還能夠迅速把熱點加速掉，我們稱之為散列技術，可以把熱點的抗壓能力輕松提升到10～30倍。

成本上，從我們的角度來看Redis，往內存里邊放的東西越多，成本就越高，內存是所有的存儲里最貴的。但是阿里云Tair有更好方式，我們有Tair持久內存型，很好地解決了存儲成本和訪問性能的矛盾。最早做持久內存的時候，它沒有什么企業級特性，后續我們把企業級能力都搬到持久內存上，如今大家去買持久內存的話，就具備這些企業級能力，包括PITR、多活、加速等。

開源Redis的好處在于它跟一般的KeyValue不一樣，它存很多結構化數據，跟數據結構更貼合一點，用得比較快一點。但是我們發現用戶真正用起來的時候，這些結果是不夠的。游戲用戶大量使用JSON，比如存用戶屬性、道具等，都是JSON結構。所以Tair引擎里已內置了JSON結構，那么用戶用起來就非常方便了。

三、Tair游戲場景介紹

（一）Tair全球多活

Tair有一個典型的場景是全球多活。

這個是線上的一個例子，例如游戲里中國用戶可以到美國的商店里去買一個光環裝備，然后這個用戶在國內服務器上就具有了一個光環。

全球多活是基于引擎高可靠的數據多活服務，Tair提供全球同服的高效Cache Server，數據庫本身具備多活，數據寫入一個地方，那么所有地方都可見。

多活在游戲里基本是用在Cache Server上，所有互聯網類的用戶都會有一個登錄Session系統，如果要去把Session系統做大，做一個很可靠的全球多活Session，Tair也能支持。

（二）數據閃回 任意時間點數據恢復

Tair另外一個經典場景是任意時間點的數據恢復，它實際上是數據安全的一部分。數據安全包括鏈路加密，也包括存儲加密，還包括多副本等。

但任意時間點數據恢復這個場景游戲客戶用得最多，大約占90%。游戲廠商在發版本的時候，如果出現問題可以快速回滾，也支持只回滾某一些東西。回滾既支持把數據恢復到源，也支持克隆一個新實例來恢復。

（三）CAS/CAD 高性能分布式鎖

剛才我們從分區分服的服務器里邊也看到了，Redis本身會作為Game Server的一些周邊服務，最簡單一個例子就是分布式鎖。多個機器同時去拿一個資源的時候，牽扯到資源競爭肯定要有鎖，業務需要通過分布式鎖來解決。但這個分布式鎖很少有人實現的對，所以我們就直接把分布式鎖做在這個引擎里面了。

分布式鎖比起一般的鎖，它除了有互斥性，還有租約性。一般會在鎖上加一個Timer，設置鎖多長時間，當租約到期后，鎖自動釋放。

分布式鎖存在的問題不是加鎖的地方，而是釋放的地方。舉個例子，比如一個應用程序去加了鎖，應用程序沒有掛，但是時間拖得長一點，然后等到引擎里面的Timer超時，鎖就釋放了。結果第二個應用程序就拿到鎖了。當這個APP又跑起來的時候，我們一刪鎖就把別人的鎖給刪掉了，會引發資源錯誤。

因此，難點在刪除這一步，刪除時的要求是只能刪自己的鎖，不能刪別人的鎖。所以很多的云上用戶，如果用去del命令去刪Key的話就刪錯了，正確的實現是一個事務操作，而Tair直接在引擎里實現了分布式鎖。

阿里內部90%的分布式鎖都是使用Tair的高性能分布式鎖，包括許多游戲客戶也經常使用。

（四）TairDoc：游戲業務快速迭代

另一個核心的module能力就是TairDoc，因為JSON數據結構是游戲用戶里最大的特征結構，我們更新JSON的時候不需要該表，直接在對應的JSON數據中增加相應信息即可。

（五）TairZset: 多維/多條件實時排序

排行榜是游戲場景的最常見應用，也是Redis的一個主要應用場景，甚至有些大型游戲公司有一個專門的排行榜組，給全平臺游戲人員提供排行榜服務，而非直接暴露一個Redis zset接口。在具體開發實現中，會遇到如下兩個主要的問題。

第一個問題是在對戰的時候，玩家選擇排行榜上的其他玩家PK，肯定也是選一個分數和時間差不多的，因此，做排行榜的時候是多維度的。例如在直播網站，可以看到在線人數，粉絲點贊數，禮物金額等。如果按照一個個維度去做的時候，那么很難做一個很精確的使用。開源的Redis只能提供一維的排行榜，而Tair則可以提供包含多個Score的多維排行榜，這樣的多維/多條件實時排序能力很好地解決了這個問題，開發者使用起來也會非常的敏捷順手。

第二個問題是當游戲特別大的時候，例如游戲用戶有2000萬人，那么2000萬人的排行榜是非常大的了，在這樣規模排行榜程序設計上把所有的用戶都存在一個Key下面，Redis就會發生數據傾斜，性能也不是特別好，而如果要把 Key拆開，因為排行榜既不符合分配率，也不符合交換率，所以拆的話也比較難。針對這個痛點，通過TairJedis更可以創建分布式排行榜，非常敏捷的構建大規模、高靈活度的排行榜應用，用戶可以根據業務容忍度和性能訴求選擇分布式精確/非精確排行榜而不用關注實現細節，讓游戲開發者能夠更加敏捷地進行游戲邏輯的開發，這些細節都是通過SDK層結合低層TairZset能力幫助用戶構建起來的。

后續Tair的產品發展過程將會針對游戲行業的更多場景提供更為靈活敏捷的能力，同時在客戶降本增效上做進一步探索。

特別聲明：以上文章內容僅代表作者本人觀點，不代表ESG跨境電商觀點或立場。如有關于作品內容、版權或其它問題請于作品發表后的30日內與ESG跨境電商聯系。