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

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

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

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

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

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

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

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

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

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

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

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

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

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

想做多活要有什么条件？

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

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

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

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

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

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

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