饿了么实现异地多活的架构设计和数据一致性解决方案

KEVINLONG 2017-10-26

异地多活是保障业务高可用非常有效的方法,在一个机房出现问题时,并不会对整体业务有太大影响,对规模大一些的互联网产品来说都很有必要。但是异地多活又被看做是技术行业中难以解决的一个问题,网络、数据、事务等各种问题混在一起,有些问题看起来没法解决。

饿了么实现异地多活的架构设计和数据一致性解决方案

今年5月9日,饿了么CTO在朋友圈发布了一条消息,宣布饿了么多活取得成功,历经半年的规划、调研、设计,又经过3个月的开发改造,继阿里巴巴之后成为第二家真正实现全网多活的互联网平台。

实现异地多活有哪些难点呢?

异地多活对网络服务的高可用是非常有效的一种方式,但是很多团队实现起来会遇到很多困难。饿了么CTO张雪峰是这么描述的,异地多活实现的难度表现在技术和实施两个方面,技术上主要是实时数据的强一致性,必须解决循环重复复制的问题。

在实施上需要全员的协同努力,再加上是在已有业务运行的基础上进行改造,任何一个环节除了问题,都会导致全局崩溃。张雪峰将这个过程誉为“给高速飞行的飞机换引擎。”

饿了么实现异地多活的架构设计和数据一致性解决方案

饿了么为什么要做异地多活?

2016年饿了么所有的服务都部署在北京机房,有四千多台服务器,灾备的服务器设置在云端,有三千多台虚拟机。当时业务订单峰值已达到千万,但是北京机房无法再次扩容。

饿了么选择在上海建一个新机房,新机房要2017年4月份投入使用,而新机房建成后,要求异地多活项目能够具备在生产环境上进行灰度。

饿了么在北京和上海建设机房,希望是将北方用户的请求和流量全部归入北京机房,南方用户的请求和流量全部归入上海机房。但是会出现的问题是外卖用户的流动性。如果用户出差,今天在北方,过两天在南方,另外还有一些分解区域不好划分,会导致一个用户的流量在南北机房同时漂移。

做异地多活更重要的原因是为了当一个机房出现故障,严重时甚至导致整个机房崩溃,这个时候可以将所有流量快速切换到另外的机房,保障整体服务的高可用。

饿了么实现异地多活的架构设计和数据一致性解决方案

为什么不能通过异地灾备的方案解决?

实现异地多活要投入很多的人力和精力,实现又很困难,那么为了保障高可用,为什么不通过异地灾备的方案呢?

异地灾备需要建设一个新机房,投入巨大,但是平时呢又不承载流量,机器空置,造成浪费。并且灾备的机房只在应急的时候使用,平时没有流量,服务的可用性、容量等问题都不能保障。

相比较来说,异地多活项目让一个机房发生故障后可以将流量切到另一个机房,提升可用性,饿了么机房切换可以在10分钟内完成。

想做多活要有什么条件?

异地多活确实也需要投入很多人力和物力,做之前要想清楚多活能够解决什么问题。实现多活要有很好的基础设施、工具和运维团队的支持,要依赖很多基础服务、工具以及框架的改造和开发,需要有各种数据的同步工具、数据校验工具、流量分发工具等等多达10余种。

饿了么是如何实现异地多活的?

实现异地多活有很多技术关键点,数据是其中比较重要的一个环节,想要实现机房与机房之间的快速切换,需要将底层数据库的数据打通,实现低延迟、数据一致性和高吞吐三个关键问题。

饿了么实现异地多活的架构设计和数据一致性解决方案

饿了么在多活之前,北京机房的数据中心有250套MySQL集群,一千多台MySQL,超过400个Redis。多活改造时按照用途分为了Global DB、多活DB、非多活DB3个部分,主要是为了做数据复制做准备。

比如像支付、订单、下单等数据,当一个机房宕机时就必须要切换到新机房,这些数据称为多活DB,是优先改造的数据,DRC进行双向复制,保持数据一致性。

异地多活是一项复杂的工程,涉及到很多的技术难点和关键点,在第六届TOP100软件案例研究峰会上,饿了么异地多活项目总架构师、中间件团队首席架构师李双涛将出席会议,首次对外分享饿了么整体服务异地多活改造的过程和关键点。

异地多活项目的核心是设计了一种分布式数据中心解决方案,让业务能够部署到多个机房,但相互之间能够没有冲突的并行运行,这是李双涛老师首次公开分享饿了么异地多活项目的实现经历,将饿了么异地多活的实践过程向技术从业者传播。

饿了么实现异地多活的架构设计和数据一致性解决方案

相关推荐