本文从三个方面来为大家介绍数据库游戏行业最佳实践：
- 游戏架构中数据库的应用和需求分析
- 游戏中Redis/Tair的技术水位
- MongoDB的游戏最佳实践
一、游戏架构中数据库的应用和需求分析
游戏主流架构有三种：1.分区分服。2.全区全服。3.全球同服。
1.1 Alibaba Cloud Database in gaming servers （分区分服）
见上图从上、中、下三路来介绍：
上路是当用户登陆获取游戏帐号时，能获取服务器的分区信息和版本信息等，用户的帐号和订单等存在关系型数据库PolarDB里。用户分区分服和信息缓存到Redis/Tair的数据库里，红色是数据库用法，黄色是缓存的使用场景。
中路是游戏核心GameServer强计算型数据结构。游戏中的经验和装备会定期刷入数据库中。游戏数据的人物角色存储以Json半结构化写到数据库里，数据可以使用PolarDB和MongoDB。在GameServer有分布式锁、排行榜、选角记录等，会引入Redis 服务或阿里云的Tair。
下路很重要，游戏中有很多活动，大量的日志记录被存放到一个分析性数据库中。比如游戏投放活动后想看是否有效果，就要分析数据库形成的报表。分析性数据库很重要的作用是反作弊，防黄牛/防刷等。要做数据分析需要导入不同源，比如日志、角色、账号等。阿里云的AnalyticDB最适合做这个工作。
见图片右上角，分区分服游戏有点到点和跨服对战等互动信息，这种消息系统使用Lindorm服务区存储。
1.2 Alibaba Cloud Database in gaming servers （全球同服）
全球同服是各大游戏厂商重点投入的一个的架构。因为使用多种游戏平台比如PC、手机、Switch和PlayStation等游戏主机进行无缝的游戏和互动，会将用户的体验提升到一个非常出色的水平，国内也有这种游戏在全球大卖。
全球同服的架构特点是使用集中式的数据库，前端不同区域的游戏中心会将数据集中的写到统一的数据库中。全球同服技术的核心是每个区域的Cache Server，它是提升游戏体验的核心，会定期的将数据批量刷入后端数据库，也会将数据库中更新的条目更新到其他服。
1.3游戏行业对数据库的整体需求
游戏行业本身高度依赖内存计算和网络资源，然后才是数据库。我走访过很多游戏客户，记得有一位游戏大厂CTO和我说：“游戏里最远的距离，不是数据到数据库的距离，而是联通到电信的距离”。
但虽然游戏行业整体上对数据库性能要求并不高，但是它对数据库的稳定性、平滑性和可运维程度要求非常高。
首先就是扩缩容的平滑性。由于阿里的数据库技术开始是围绕电商发展起来的，而电商系统和游戏系统这两个行业在使用缓存和内存数据库的方式上却高非常不一样。举个例子说，电商对数据库容错的需求大都是“早死早超生”的哲学，做fast fail。如果访问数据失败，数据层需要做快速失败而不能卡住。这样用户才能快速重试，但是如果我们把这个逻辑套到游戏服务中，如果访问一次两次数据库库失败了就把连接给断了游戏用户可能就直接被踢出这局游戏了。
所以我们专门在可扩展和高可用上做了连接保持能力，不但扩缩容不断链接，在阿里云集群版Redis/Tair上即使高可用事件发生，比如Tair后端数据库做了切换，前端仍然可以保持连接不断。在Tair的扩缩容事件中，对业务侧的抖动可以达到100ms左右，基本接近无感。像PolarDB存储计算分离的云原生数据库也具备切换和HA不断链接的能力。这样在平滑性上就有保障了，对于用户的游戏体验来说也是一个非常大的进步。
另外一个场景是，虽然游戏行业对数据库的整体性能要求并不太苛刻。但是游戏用户也有万人团战、新区上线等热门活动，这种对数据库整体的抗压能力和平滑可扩展能力要求很高。
全球同服的游戏对数据库的需求逐步走向了跨域多活，现代数据库的跨域多活也成为数据库内置的核心能力之一，能够极大的简化用户的使用场景。
1.4游戏行业更青睐云数据库
游戏行业是一个迭代速度极高的行业。在一些核心的服务能力上，比如在阿里云Tair上，它的存储结构更接近客户的数据更接近ORM，它提供了一些封装好的分布式锁、分布式排行榜、计数服务等能够让游戏高速迭代起来。
同样，游戏用户是数据库运维操作最多的行业之一。这和游戏本身的业务特点相关，比如有些分区分服的游戏，它的运营和拉新模式就是开新服，合旧服这种。游戏的运营活动频繁，运维大量数据搬迁、数据清洗，有些分区分服的服务要经常合服、滚服和版本更新，发上去也要经常备份、回档等。数据库本身就要在数据库内核上做增强，也要和周边生态做互动。当代数据库如果不把运维系统和生态系统当成一等公民去建设，逐步的就会被市场淘汰。
在成本上池化数据库能够更好的在资源上做配置，达到更好的资源配置。在游戏行业有两块成本被显著低估了，一块是运维成本，具备很高的弹性扩缩容的能力，可以极大的降低业务的成本开销，比如Tair就可以随着用户业务选择内存引擎，如AEP引擎和SSD引擎。另外一块是错误成本，本质上还是属于研发成本的一部分，具备更好的可观测性，能够通过高效标准的生态工具同样可以降低错误成本。
二、游戏中Redis/Tair的技术水位
2.1 Redis/Tair当前游戏能力技术水位大图
在面临稳定性，高速迭代和成本等问题时，云数据库有很大的优势。在NoSQL数据库领域，Tair和Mongo都支持Json的原生结构。另外非关系型数据库针对游戏高速迭代非常友好，比如在运维上Tair可以做任意时间点的数据恢复， Tair在扩缩容和容灾上都具备连接保持能力。数据库也支撑存算一体的能力，在Tair上具备非常多的数据模块，可以方便游戏用户做分析和计算等。
Tair云原生内存数据完全兼容了Redis协议和命令。Redis是游戏服务中必不可少的数据库之一，上面的架构图已经介绍过了，它可以服务缓存和内存数据库两种场景。
但是在原生的社区Redis上，它的探活和扩缩容都非常不平滑。在云Redis上做有很大改良但是还是闪断；到了Tair上就可以做到连接保持、高精度探活和切换；如果自运维Redis在备份恢复上，就只能全人肉运维了。云Redis可以通过很好的基础设施无感知和自动化搞掉，Tair可以很好的保证数据安全和任意时间点的恢复。针对AEP/SSD引擎，还有可调节的版同步能力在上线中，可以更好的适应数据无损场景。
云数据库具备更好的可观测性，比如Redis里面一旦遇到大Key，热Key就很难观察到。云数据库在内核上极大的提升了可观测性，在Tair上就有更好的可控制性，比如热点在云Redis上可以被发现，在Tair上就可以使用加速能力能够瞬间将单个Key的读能力提升几十倍。这个能力来自于电商系统中的热点散列技术，是一个简化版，但在与服务中针对游戏的场景做了更灵活的优化配置能力。游戏中并不会出现像电商系统中出现全民抢茅台这种数百万级别的热点访问，而查询缓存足以让游戏业务更好的应对突发事件和洪峰挑战。
Redis经常工作在同步链路，慢了就会直接影响体验。游戏里面遇到就要先顶过去再说，后续慢慢查慢慢修。还是那句话，虽然游戏对数据库性能要求并不高，但是保险一定要有。
在加速开发上，自运维的Redis可以运行一些Redislabs设计的企业级模块，但是这些模块云厂商不能用。Tair上做了特别多的业内常用的多数据模块，有一些是完全兼容Redislabs模块，比如游戏里面常用的Json模块完全兼容reJSON。TairZset是一个多维度排行榜，也可以使用我们提供的SDK做一个可扩展、高性能的分布式排行榜，它也是基于TairZset。在上线中的是TairSearch，它兼容Elasticsearch的语法，可以对存放在Tair的内容做全文索引和分词，这样结合Tair引擎的强大能力可以做到一个非常好的游戏体验。
2.2场景: Tair的全球多活在游戏中的使用
下面介绍几个场景，第一个场景就是数据库多活。这个场景在全区全服的游戏里面应用的非常广泛。
说一个切身体会，就是最近一个老牌的游戏大厂，上线了一个全球同服的游戏。它把一个20年前的游戏重制了一下，把分区分服改成了全球同服，结果非常不成功，直到今天，就是现在你去玩的时候，登陆的时候都在排队。很遗憾我是这个游戏的骨灰级玩家，我的黑眼圈大多数是因为工作导致，最近加重了其实和这个游戏很有关系。
前两天在论坛上，他们的技术经理写了一篇非常长大概3000多个单词的文章，解释了为什么会出问题。我仔细去阅读体会了好几遍，其实都是在解释业务数据在面临全球多活时的技术挑战。既要好的体验，又要保证数据一致。如果没有一个全球多活的数据库，那么即使是一个技术和策划都非常强的老牌游戏公司也同样会陷入困境。
如果我不是因为情怀，真的就把这个游戏退掉了，天天掉线回档是无法忍受的。使用Tair等全球多活数据库能够给用户一个很好的体验，可以让全球多活游戏有非常好的体感。
图中就是一个游戏客户的典型用法，中美游戏服务器的商场漫游。
2.3场景: 任意时间点数据恢复（PITR）
第二个场景是任意时间点的数据库恢复。这个场景最早是防止删库跑路的场景。在游戏行业里用途非常广泛，比如游戏发版本，出问题能够迅速回滚。同时我们也挖掘了游戏客户的反馈和建议，在任意时间点恢复的时候，可以选择性的恢复部分Key/Key Pattern，也可以选择性的丢弃某种类型的Key/Key Pattern都支持。这个Key级别的PITR就是专门为游戏行业定制开发的，数据库产品能够多贴着游戏的业务场景做一些能力，那么业务的幸福感提升还是很高的，也降低了犯错机会。
2.4 Tair(Redis企业版）支持的数据结构模块 (modules)
Tair作为企业级的Redis，它的一个典型的特点就是支持非常多的扩展模块，既包括简单易用可以提升幸福感的数据结构，也包括一些行业级整体解决方案。在本次分享中我只简单说一下画圈的这几个，它们在游戏开发中经常遇到。
2.5场景：高性能分布式锁（CAS/CAD）
所有互联网应用都需要分布式锁做类似于资源竞争的处理。我们在Redis场景下发现业内有非常多的分布式锁的实践案例，但很多都实现的有问题。主要技术点就是分布式锁删除不对，有可能会导致业务侧的资源争抢失效。我们在Tair引擎里做了分布式锁，只需要设置一下就能减少犯错的成本。阿里集团内部、游戏和互联网行业分布式锁用得很多，这个Tairstring模块已经开源没有限制了，用户用Redis套上去就可以用，可以获得比较好的收益。
2.6场景：多级排序和分布式排行榜
Redis的排行榜是所有游戏绕不开的问题，排行榜的问题是大Key很难做并行的扩展，游戏里的排行榜会故意设计地比较深，特别不容易点到，Redis的排行榜最痛的是容易形成大Key和只能为一维数据进行排序，携带的额外数据有限。
我们也给游戏里多维度的排序做了模块，通过模块的扩展做分布式排行榜，服务能力通过分片数和整体的资源上升做到平衡扩展，为游戏用户解决大查询的问题。
同样TairZset模块也已经开源了，结合着Tair的SDK中分布式排行榜，用户可以很容易的应用可扩展高性能排行榜这个基础设施。也不需要维护一个专门的排行榜团队，毕竟一些中小型游戏公司并没有精力去投资一个专业的排行榜团队。
从以上的介绍我们可以看到，数据库内核能够帮助沉淀一些能力到引擎中，那么就能够极大的简化业务的开发，这对于游戏行业的高速迭代是非常重要的。在2017年曾经在数据库行业内掀起过一场轰轰烈烈的Multi-Model运动即多模数据库。多模能力大背景上就是数据库在对行业做深耕，而Tair提供的这些能力即是阿里云上诸多客户的真实需求，也同样是阿里内部系统使用最多的数据结构。
2.7游戏的云数据库周边设施（DTS/DAS）
关于游戏的合服、滚服操作，过去都做的非常原始。要么是自己做备份、清洗和合并，要么就是自己写个长SQL去做数据变更。这些工具、方法要么是按照约定，要么就是祖传脚本口口相传。有些原始的云服务还要提个合服工单什么的。在当代数据库生态里数据的订阅（CDC）和转换清晰（ETL）已经是数据库生态的一部分，它通过标准的全量和增量订阅，可视化的进行过滤、映射等算子标准化的支持掉。
阿里的DTS即完整的支持Tair的Binlog协议。整个数据滚动和运维的成本会非常低廉，并且可控制。生态工具仍旧是诸多数据库的护城河，也同样是一等公民需要建设。
像Redis或Tair高速数据库服务时可观测性很重要。游戏出现大Key可能稍纵即逝，我们DAS平台提供非常好的可观测服务可以看到实时场景。DAS的可观测、可控制、审计优化件的动态带宽可以帮助用户减轻运维操作。
三、MongoDB的游戏最佳实践
3.1使用MongoDB应对游戏数据库常见痛点
MongoDB游戏框架原生是Mongo去支持，Mongo是原生支持Json结构，适合游戏存用户数据。
3.2从开发运维视角看阿里云MongoDB
MongoDB适合游戏的结构化存储，无论分区分服场景还是全球同服，规格比较全可以自己配置。MongoDB到了阿里云的云上后，结合云化设施能力会更强，做快照备份恢复云化设施实现秒级快照。扩缩容能力弹性好，云化设施做Scale、up down等都是非常平滑的。同时MongoDB端到端的安全解决方案也非常多，也更加标准化和便捷，同样可以用作很好的防作弊，防机器人场景。
以上就是我对阿里云数据库在游戏行业使用的一个简单总结，谢谢大家！
