数据库异地多活相关

异地多活指分布在异地的多个站点同时对外提供服务的场景。异地多活是高可用架构设计的一种，与传统的灾备设计的最主要区别在于多活，即所有站点都是同时在对外提供服务的，以下整理自知乎和开发者头条

CAP 理论

CAP 定理，指对于一个分布式计算系统而言，不可能满足同时满足以下三点

• 一致性(Consistency)
  所有节点访问同一份最新的数据副本
• 可用性(Availability)
  每次请求都能获取到非错的响应，但是不保证为最新的数据
• 分区容错性(Partition tolerance)
  以实际效果而言，分区相当于对通信的时限要求。系统如果不能再时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在 C 和 A 之间做出选择

原理

异地多活本质上是一个分布式的 AP 方案，为了实现异地多活方案，必须要做出一部分的取舍，这个取舍就是对一致性上的取舍。

架构方案

关于数据的异地多活方案，架构通常有以下几种

• 同城异区
• 跨城异地
• 跨国异地

同城异区

同城异区下，DC 之间包含以下特点

• 延迟小于 10ms
• 搭建高速网络
• 极端灾难不能避免
• 复杂度，成本，故障发生概率是应对多机房故障最优架构

跨城异地

• 网络环境复杂，延迟不确定，大致 50ms -> 1s
• 大概率避免极端灾难
• 距离远，搭建专用网络通道复杂度和成本高
• 肯定会出现数据不一致，需要保证数据短时间不一致能提供服务
• 要求数据高度一致的服务不能跨城异地，例如支付

跨国异地

• 为不同地区用户提供服务
• 只读类业务多活

设计方面

三个原则

由于物理限制，实时一致性无法保证，这是要保证最终一致性，并且无法做到全部业务的异地多活，只需要实现核心业务的多活即可。并且要保证大部分用户的核心业务可用。

核心数据的异地多活

• 物理限制，不可能做到数据实时同步
• 减少数据不能实时同步的方案
  • 减少异地机房的距z离，搭建高速网络
  • 减少数据同步，只同步核心业务的关键数据
• 保证最终一致性，不保证实时一致性
  • 业务不依赖与数据的同步的实时性，只要最终一致性即可

采用多种手段同步数据

• 思维误区: 只使用存储系统的同步功能
  • MySQL 低版本的单线程复制，延迟时间长
  • Redis master slave 的全量同步，slave 不能对外服务
• 消息队列
• 二次读取
  • 读取本地机房失败，去另一个机房读
• 回源读取
  • 根据路由判断数据的位置，去读取
• 重新生成数据
  • session 重新生成，重新登录
• 存储系统本身机制同步