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

一、高可用的解决方案

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

二、适用的业务类型

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

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

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

四、数据同步的几种方案

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

五、落地方案分析

1. 业务内聚

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

2. 可用性优先

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

3. 数据正确性的保证

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

参考

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

你可能感兴趣的:(分布式架构)