主页（http://www.zhonghuagame.com）：GaussDB为什么成为游戏行业的心头爱？
【天极网IT新闻频道】摘要： 看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)支持跨地域双活容灾，即在两个实例之间建立数据同步链路，其中主实例支持读写，备实例只读。如下图所示：
