如何选择合适的数据库，让游戏更高效可用

3月8日，2017游戏行业全球同服和安全攻防技术沙龙在上海举行，阿里云资深技术专家丁奇带来题为“ApsaraDB介绍—MySQL”的演讲。本文分五部分为大家介绍，首先从RDS基本架构开始聊起，进而说到了如何保障平台数据库的数据安全和高可用，接着谈及了多种数据库引擎快速适配游戏逻辑服务，包括RDS新特性:克隆实例、恢复到任意时间点、连接保持等，最后着重分享了RDS可诊断性设计并对云数据库目标做了总结。

直播视频回放

以下是精彩内容整理：

RDS基本架构

RDS上买一个实例基本可以看到一主一备的双节点场景，但双节点理论上不能保证不丢数据，

即使是异步复制也容易丢数据，如果作为内部业务分级，日志类丢一点没关系，但实际上我们不知道用户业务是什么类型的，默认认为都不能丢，可能用户会感觉新实例没有老实例跑得快，用户可以自主在控制台手动设置模式。

双节点还是有很多的不完备，假设网络抖动时主库挂掉，日志就会传不过去，B超过一秒没有返回就会退化，如果不退化B系统不可维护，可用性降低，如果刚好在退化期间A挂掉，还是会丢数据，因此我们采用三节点方案。

三节点方案不用退化，A写入时，B或C至少有一个人响应收到日志，如果A挂掉，在B和C选择日志收的多的切过去当作主库，从而提高可用性。

 

可靠性&可用性

切换策略

我们的切换策略即是主库挂了就切，需要保证三点：

首先要正确，不要不该切时切；其次要及时，该切时候一定要切；最后是最小化，可切可不切时候不要切，切了如果没有用也不要切。

我们内部演化出了三步：开始我们进行select探测，如果成功有返回就没事，没有返回即挂了，后面我们发现不对，当主库可以读不可以写的时候，比如磁盘满了，select都成功，但业务都写不下去了；接着我们考虑更新探测，自己找系统表update，如果更新成功，说明业务可写，更新超时或失败就切换，但当业务压力变大时，操作系统并不是直接罢工，还是尽力的提供服务，当磁盘IOPS达到100%时，不是突然变成零，也是有在服务的，可能会出现update语句过了但业务没过；现在我们的策略是自动报告，MySQL自己知道自己的状况，如果某一个IO响应超过多少秒就说明这个库不行了，MySQL会告诉切换系统切掉主库，MySQL自己会记录读写时间，这是一个全局信息，不会误报也不会漏报。

你会发现切换系统不再负责决策切换，它只负责查询，让数据库本身来决定谁是主库谁是备库。

连接保持

游戏也比较关心闪断问题，除了网络抖动外，日常情况下会有非常多需要主动切换连接的操作，比如机器下线、磁盘迁移和软件升级等，都需要主动切换，但此过程连接会断开，对用户造成影响，这样的动作很多，而云用户有上万个，我们不知道谁有做重连谁没做重连。

现在我们的做法是主动切换优化，用户误感知，中间的Proxy可以做很多事情，切换时先将B升级，连接从A切到B，但用户连接的是Proxy，所以不会感知，项目需要在用户离峰期切换。

恢复到任意时间点

恢复到任意时间点，指定一个时间点，起一个临时实例，把数据恢复到指定那一秒之前的数据状态，具体逻辑如下：

第一步，取上一个全量备份，恢复到临时实例；

第二步，取上一个备份之后的binlog，应用；

第三步，接上主库，追日志到指定时刻。

雪崩场景

如果失败要断开重连，但有时可能不是失败而是变慢了，比如预计一秒返回，但一秒没返回你可能就会断开，如果数据库断开会有很多重试逻辑，瞬间超时导致重试，业务会重试，然后客户会重试，但数据库里的连接还在跑，接下来又会发起一波连接，可能原来50个连接在跑，突然发生大的操作将数据库拖慢后，就会变成100个连接在跑，都超时就会都重连，越来越多进而挂掉，这时候业务kill都来不及，只能重启。在RDS中，我们提供select max_statement_time=1000的源码方案，表示语句最多执行1000ms，到了1000ms就会内部自杀，时间与业务端超时设成相同即可。

 

性能&成本

日志业务

业务发展起来后，日志占的成本比业务数据还要大，那么，日志的特性包括：数据量很大、写入量大和查询少。TokuDB十倍压缩和写数据速度不衰减可满足日志的特性。

在TokuDB上加Petadata效果更好，Petadata是RDS自己开发的中间件，可以支持分库分表和分布式事务，连接透明，客户端只需要连接Petadata即可，要扩容时只需把机器加进去，后台自己会做静默迁移，应用没有感知。

 

功能&形态

• 有些用户只需要一个节点随便算数据，丢了也没关系，可以用从伸展库拉数据过来，我们会选择在ECS上自建单节点版本；

• 克隆实例就是给新开服使用的；

• 恢复到时间点可以实现快速回档；

• Petadata具备分库分表功能，同时还有分析功能，目前主推HybridDB，当数据量大时想做复杂查询，我们会根据需求选择产品。如果只是需要一个库跟主库一模一样，想在上面跑复杂查询，又不想影响主库业务，这种一般应用RDS只读实例即可；如果需要拷下来放到本地的hadoop上跑才行，或者做业务时分成五六个库，而分析时要合到一起，就可以将数据导到HbridDB中，分析非常快。

 

可诊断性

审计日志

可诊断性可以衡量一个云服务的成熟度。审计只是其中一部分，我们做全链路监控，包括磁盘、内存、数据库、网卡以及各种链路等，当即不是上游也不是下游，而是MySQL内部出问题时就需要DBA出场了，审计日志是做可诊断性最重要的工具，记录所有的用户数据操作才有审计效果，看上去很像general_log，开启后性能下降90%，而RDS审计日志性能只下降2%，记录了源ip、用户名、线程id、扫描行数、latency、执行时间(us)、返回行数、更新行数、错误号和消耗内存，并不是所有的不是慢SQL语句都没有问题，如果记得所有数据，一个普通语句返回两行，扫描5000行，说明索引没有建好，即使语句短时间返回，也应该被处理。

诊断报告

我们推出诊断报告，在测试后我们会出某个时间段的数据库状态，有哪些潜在问题，潜在的死锁原因需要解决，告诉你哪些事务时不必要的，哪些事务已经回滚了。

 

小结

云数据库的目标是让MySQL像Orcale一样，允许DBA去逃避简单的工作，让他们有精力变成数据架构师。

 

丁奇：阿里云关系数据库服务内核开发和运维团队负责人，活跃的MySQL社区贡献者。开源分支AliSQL和《数据库内核月报》负责人。在云数据库系统开发、运维、架构优化上有丰富的经验。现致力于推动通过自动化专家系统的建设和推广，以提升云数据库用户的业务稳定性。