浅析数据高可用之异地多活

一、高可用的解决方案

• 异地多活是服务高可用的一种解决方案，具体为在不同城市建立数据中心，即数据机房，然后各数据中心之间互相同步数据，相对于“冷备”而言，“多活”是指任意一个数据中心宕机了，可以马上切换到另外一个数据中心，继续提供服务，如修改负载均衡器的配置，将流量切换到另外一个机房。
• 除了高可用外，异地多活还可以使不同地区的用户访问不同的数据中心，提高了访问速度，从而提高了用户体验。

二、适用的业务类型

• 异地多活一般适合于能容忍数据存在短暂不一致的业务，如用户中心，但是像金钱之类的业务则不太适合，如假如用户刚好取完钱，对应的数据中心挂了，没有同步到其他数据中心，则用户在访问另外一个机房，发现钱还是一样，故会给公司带来严重损失。
• 在业务落地时，同一个业务整个流程在一个机房完成，将整个业务流程的数据打包同步到其他机房。

三、数据一致性：最终一致性

• 异地多活由于需要通过网络在各个数据中心之间相互同步数据，而网络是不稳定的，可能存在网络故障或者抖动，并且两个城市之间的网络传输一般需要几十毫秒，网络不稳定时可能是几秒或者几十秒，所以各个数据中心的数据不可能做到实时一致性，即异地多活实现的是CAP理论里面的AP，不是数据强一致性，而是数据最终一致性。

四、数据同步的几种方案

1. 使用MySQL，Redis自带的主从同步，不过可能存在较大延迟，MySQL是基于binlog使用单线程进行复制的，Redis可能存在全量复制；
2. 使用mq广播到各个数据中心，如使用kafka，每个数据中心都是不同的消费者组；
3. 回源查找，当A机房发现没有数据时，去B机房查找；
4. 重新生成数据，如A机房挂了，导致session数据丢失，则切换到B机房后，重新生成这条数据。

五、落地方案分析

1. 业务内聚

• 同一个业务整个流程在一个机房完成，将整个业务流程的数据打包同步到其他机房。

2. 可用性优先

• 当某个机房挂了时，先保证可用性，然后进行数据补偿修复。如修改负载均衡器的配置，将流量切换到另外一个机房。

3. 数据正确性的保证

• 对于数据一致性要求较高的场景，如果当用户访问到另外一个机房时，发现数据不一致，则锁定该数据，避免错误进一步蔓延。

参考

1. 异地多活高可用架构设计方案
2. 异地多活没那么难