β

在游戏运维实战中摸索前行的“异地双活”架构

运维军团 5 阅读

1. 写在前面

最近由于游戏业务的迫切需求,我们需要启用一套可靠的异活双活方案,降低业务的单点。大世界类型游戏的特点是组件模块化,战斗节点、数据节点、登录认证服务器多为独立部署,这样的设计有利于高在线的承载能力。但问题来了,这样的架构要求在同一个内网里通信,我们常规部署都是把所有服务器集中在一个机房里。这样一来,一旦机房受到攻击或者机房出口异常再加上国内骨干网的间歇性抽风,这会对业务将带来全局的影响,严格来说存在一个非必然但不合理的单点。在经济学里有一句谚语“Don’t put all your eggs into the same basket!”——不要鸡蛋全部放在一个篮子里。

2. 异地双活之演进

2.1 第一阶段(伪异活)

由于大世界架构的游戏有个很明显的特征,功能性的服区分比较明显,例如有战斗节点server、日志节点log、登录节点center、数据节点data、缓存节点cache,其中有些功能服需使用数据库,有些服不需要使用数据库只承担玩家的战斗功能。这些不同的功能服无论部署在南方机房还是北方机房都存在着以下2个比较严重的问题,具体如下:

为了保障业务在单机房遭受DDOS攻击、南北骨干网抖动故障场景下的正常运行和稳定,于是我们构思出了如下方案:

我们采取用一些技术手段:

这个方案虽然在设计上显得草根,但在线上正式应用后,已经取得了一些效果,最严重的情况就是专线中断,这时我们的业务仍然可以保证正常的运行,由反向代理服务自动切换到公网转发。当然我们只能称它为“伪异地双活方案”。如下图所示:

2.2 第二阶段(理想的异活)

随着业务的长久运行,第一阶段的方案虽然能解决机房遭受DDOS攻击、南北骨干网抖动等故障场景,但也暴露了不少其他问题。例如:

要解决“真正异地双活”的问题,实际上主要是解决数据同步的问题,底层的数据要求强一致性同时实现多写。而在我们的业务场景,数据有缓冲层数据、非缓冲层数据。缓冲层数据“双活”我们计划采用redis集群+Sentinel的方案来实现。非缓冲层的数据“双活”我们计划采用MySQL集群方案。那么问题来了,业界上主流的MySQL集群方案有 MySQL Cluster Percona Xtradb Cluster

为什么不是Mysql Replication或MySQL Group Replication?

因为无论是MR、MM、MGR架构都是基于Binlog同步原理,涉及Mysql Binlog复制机制的方案均有延时的可能性。因为我们需要实现多写,如果无法保证数据实时一致性,业务将无法正常运作。

于是我们针对MySQL集群选型采取了一些压测,主要对比两种集群在高并发下写场景下的吞吐量、数据一致性、平均操作延迟等情况。

我们来看看压测结果:

单看测试结果,当数据量和并发数越大,mysql cluster集群的插入吞吐量、平均操作延时都越优于percona xtradb cluster集群。这一点也不意外,因为NDB引擎主要使用内存存储数据,而PXC是需要落地磁盘的。但是NDB引擎有很多劣势,例如巨耗内存、管理维护麻烦、容易崩溃出错、容易丢数据等,Oracle MySQL官网也强调NDB不建议应用于生产环境。这点有些纳闷…

PXC与传统MySQL区别不大,大部份日常的维护是相同的,也比较贴合游戏的应用场景。关于性能方面,我们可以用SSD来代替普通机械盘,提高IO性能。最终认为Percona Xtradb Cluster更适用于我们的业务场景。

因此,我们衍生出了第二阶段的方案,具体实现的架构:

基于第一阶段之上,新增一些关键技术点:

目前第二阶段方案虽然仅是测试阶段,但也通过了内部业务的测试,验证了方案的可行性。我们也计划在近期正式应用到线上。

期待第二阶段 “理想的异地双活”能给业务带来真实的价值!

3. 参考资料

https://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-install-linux-rpm.html

https://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-ndbd-definition.html

https://www.percona.com/doc/percona-xtradb-cluster/5.7/index.html

http://galeracluster.com/documentation-webpages/mysqlwsrepoptions.html

http://www.cnblogs.com/lizhi221/p/7325401.html

http://www.cnblogs.com/52php/p/5675374.html

END

作者:运维军团
运维技术与开源架构交流

发表评论