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

內容簡要：

一、游戲系統(tǒng)中的Redis

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

三、Tair的游戲場景

一、游戲系統(tǒng)中的Redis

（一）Redis In Gaming Servers ：分區(qū)分服

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

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

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

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

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

第二塊是分區(qū)分服里最核心的GameServer。

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

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

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

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

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

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

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

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

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

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

（三）游戲對Redis的要求

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

三、Tair游戲場景介紹

（一）Tair全球多活

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

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

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

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

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

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

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

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

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

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

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

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

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

（四）TairDoc：游戲業(yè)務快速迭代

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

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

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

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

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

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