异地多活高可用架构设计方案

异地多活在近年越来越多大型互联网公司采用的方案，几乎也是大型应用发展到一定阶段的必然选择，综合比较一下各个互联网公司的方案，会发现有很多共性的东西，也有很多差异化的东西，这是最有意思的地方。

什么是异地多活

异地多活一般是指在不同城市建立独立的数据中心，“活”是相对于冷备份而言的，冷备份是备份全量数据，平时不支撑业务需求，只有在主机房出现故障的时候才会切换到备用机房，而多活，是指这些机房在日常的业务中也需要走流量，做业务支撑。冷备份的主要问题是成本高，不跑业务，当主机房出问题的时候，也不一定能成功把业务接管过来。

CAP原则

分布式架构设计无论怎样都绕不开CAP原则，C一致性 A可用性 P分区容错性，分区容错性是必不可少的，没有分区容错性就相当于退化成了单机系统，所以实际上架构设计是在一致性和可用性一个天平上的两端做衡量。为什么强一致性和高可用性是不能同时满足？假如需要满足强一致性，就需要写入一条数据的时候，扩散到分布式系统里面的每一台机器，每一台机器都回复ACK确认后再给客户端确认，这就是强一致性。如果集群任何一台机器故障了，都回滚数据，对客户端返回失败，因此影响了可用性。如果只满足高可用性，任何一台机器写入成功都返回成功，那么有可能中途因为网络抖动或者其他原因造成了数据不同步，部分客户端独到的仍然是旧数据，因此，无法满足强一致性。

异地多活的挑战

• 延迟 异地多活面临的主要挑战是网络延迟，以北京到上海 1468 公里，即使是光速传输，一个来回也需要接近10ms，在实际测试的过程中，发现上海到北京的网络延迟，一般是 30 ms。

• 一致性 用户在任何一个机房写入的数据，是否能在任何一个机房读取的时候返回的值是一致性的。

误区

• 所有业务都要异地多活

• 必须做到实时一致性

• 只使用存储系统的同步功能

1. 用消息队列把数据广播到各个数据中心

2. 回源读取，当A机房发现没有这条数据的时候，根据路由规则去B机房去读取该数据

3. 重新生成数据，A机房登录后生成session数据，这时候A机房挂了，可以把用户切换到B机房，重新生成session数据。

• 实现100%的高可用

饿了么异地多活方案

特点

1. 业务内聚，单个订单的所有流程保证在一个机房内完成调用，不允许进行跨机房调用。每一个机房称为一个ezone，对服务进行分区，让用户，商户，骑手按照规则聚合到一个ezone内。根据业务特点，饿了么选择了把地理位置作为划分业务的单元，以行政省界用围栏

2. 可用性优先，当机房发生故障的时候，优先保证可用，用户可以先下单吃饭，有限时间窗口内的数据不一致可以事后再修复。每个 ezone 都会有全量的业务数据，当一个 ezone 失效后，其他的 ezone 可以接管用户。用户在一个ezone的下单数据，会实时的复制到其他ezone。

3. 保证数据的正确性，在切换和故障时，检测到某些订单在两个机房不一致，会锁定改订单，避免错误进一步扩散。

通过DRC复制MySQL数据

MySQL的数据量最大，每个机房产生的数据，都通过 DRC 复制到其他 ezone，每个ezone的主键取值空间是ezoneid + 固定步长，所以产生的 id 各不相同，数据复制到一起后不会发生主键冲突。按照分区规则，正常情况下，每个 ezone 只会写入自己的数据，但万一出现异常，2个 ezone 同时更新了同一笔数据，就会产生冲突。DRC 支持基于时间戳的冲突解决方案，当一笔数据在两个机房同时被修改时，最后修改的数据会被保留，老的数据会被覆盖。

通过Global Zone保证强一致性

对于个别一致性要求很高的应用，我们提供了一种强一致的方案（Global Zone），Globa Zone是一种跨机房的读写分离机制，所有的写操作被定向到一个 Master 机房进行，以保证一致性，读操作可以在每个机房的 Slave库执行，也可以 bind 到 Master 机房进行，这一切都基于我们的数据库访问层（DAL）完成，业务基本无感知。

新浪微博异地多活方案

微博使用了基于 MCQ（微博自研的消息队列）的跨机房消息同步方案，并开发出跨机房消息同步组件 WMB（Weibo Message Broker）。

阿里异地多活方案

阿里在部署异地多活的时候同样是碰到延时问题，解决方案是访问一次页面的操作都在本机房完成，不做跨机房调用。阿里把业务划分成各种单元，如交易单元，这个单元是完成交易业务，称之为单元化。

服务延时

让操作全部在同一中心内完成，单元化

部署：

异地部署的是流量会爆发式增长的，流量很大的那部分。流量小的，用的不多的，不用异地部署。

路由一致性：

买家相关的数据在写的时候，一定是要写在那个单元里。要保障这个用户从进来一直到访问服务，到访问数据库，全链路的路由规则都是完全一致的。如果说某个用户本来应该进A城市的数据中心，但是却因为路由错误，进入了B城市，那看到的数据就是错的了。造成的结果，可能是用户看到的购买列表是空的，这是不能接受的。

延时：

异地部署，我们需要同步卖家的数据、商品的数据。能接受的延时必须要做到一秒内，即在全国的范围内，都必须做到一秒内把数据同步完中心之间骨干网。

数据一致性：

把用户操作封闭在一个单元内完成，最关键的是数据。在某个点，必须确保单行的数据在一个地方写，绝对不能在多个地方写。

在所有的异地多活项目中，最重要的是保障某个点写进去的数据一定是正确的。这是最大的挑战，也是我们在设计整个方案中的第一原则。业务这一层出故障我们都可以接受，但是不能接受数据故障。

多个单元之间一定会有数据同步。一方面，每个单元都需要卖家的数据、商品的数据；

总结

各种方案都是针对不同的业务场景设计的，所以会有一定的不同，但是基本思路都是一致的。通过各种手段避免进行跨机房调用，消除延迟，让用户无感知。必要的时候通过业务的妥协，牺牲一致性来获取更高的可用性和更低的部署复杂程度。细读CAP理论就知道，这个问题是不存在完美的解决方案的，只有尽量贴合业务，逐渐迭代出更合适的方案。

版权申明：内容来源网络，版权归原创者所有。如有侵权烦请告知，我们会尽快删除并表示歉意。谢谢。原文链接：

https://www.cnblogs.com/jaychan/p/9242325.html