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

  1. 云栖社区>
  2. 博客>
  3. 正文

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

【云行】 2017-04-19 09:36:20 浏览3979
展开阅读全文

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

直播视频回放

以下是精彩内容整理:

RDS基本架构

a1aebd4b80549fd8234ff668803fbccd466ff80d

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

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

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

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

 

可靠性&可用性

切换策略

00b6d20bac986268b38c1b8a4609a2e6940ec877

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

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

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

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

连接保持

db86d2c3b0ecf2b6f7709880dcfd1ac072fe8859

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

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

恢复到任意时间点

5c4c08c61d0294f6a1578424ae1654238d2b7cdc

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

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

第二步,取上一个备份之后的binlog,应用;

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

雪崩场景

b571bca7fe2c0d68f2be1bca24e17d37088aabef

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

 

性能&成本

日志业务

cb7ea75b9e12b0a123f22c2be39ca197b294a0b1

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

ef23e21f714a8632757ca0bc31c1d1d74bbe2ee9

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

 

功能&形态

38fa1431d48bde98c462d26403cde050eada0118

  • 有些用户只需要一个节点随便算数据,丢了也没关系,可以用从伸展库拉数据过来,我们会选择在ECS上自建单节点版本;
  • 克隆实例就是给新开服使用的;
  • 恢复到时间点可以实现快速回档;
  • Petadata具备分库分表功能,同时还有分析功能,目前主推HybridDB,当数据量大时想做复杂查询,我们会根据需求选择产品。如果只是需要一个库跟主库一模一样,想在上面跑复杂查询,又不想影响主库业务,这种一般应用RDS只读实例即可;如果需要拷下来放到本地的hadoop上跑才行,或者做业务时分成五六个库,而分析时要合到一起,就可以将数据导到HbridDB中,分析非常快。

 

可诊断性

审计日志

055be9c24242883f1bd3345370181fd1aa4442b7

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

诊断报告

6d46b7a458f5814d66b095d5c42177cc8b359ede

d29f9394add5770b4c48e7779a3cc754382135d9

f79a252d1c32ad8ec75b8b145014fa8bcb67d32a

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

 

小结

e3c29042d2d3d7f6ce4d154e94f2815c5a3329d4

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

 

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

网友评论

登录后评论
0/500
评论
【云行】
+ 关注