极客时间：《从 0 开始学架构》:异地多活设计4大技巧
技巧 1：保证核心业务的异地多活
“异地多活”是为了保证业务的高可用，优先实现核心业务的异地多活架构
技巧 2：保证核心数据最终一致性
异地多活本质上是通过异地的数据冗余，来保证在极端异常的情况下业务也能够正常提供给用户，因此数据同步是异地多活架构设计的核心。
数据冗余是要将数据从 A 地同步到 B 地，从业务的角度来看是越快越好，最好和本地机房一样的速度最好。因此一个矛盾的地方：业务上要求数据快速同步，但物理很难做到数据的快速同步。有以下几种方法可参考：
- 尽量减少异地多活机房的距离，搭建高速网络
- 尽量减少数据同步，只同步核心业务相关的数据
- 保证最终一致性，不保证实时一致性
最终一致性指的是BASE理论中，业务不依赖数据同步的实时性，只要数据最终能一致即可。
技巧 3：采用多种手段同步数据
数据同步是异地多活架构设计的核心。采用如下几种方式同步数据：
- 消息队列方式
将数据通过消息队列同步到其他业务中心 - 二次读取方式
某些情况下可能出现消息队列同步也延迟了，用户在 A 中心注册，然后访问 B 中心的业务，此时 B 中心本地拿不到用户的账号数据。为了解决这个问题，B 中心在读取本地数据失败时，可以根据路由规则，再去 A 中心访问一次（这就是所谓的二次读取，第一次读取本地，本地失败后第二次读取对端），这样就能够解决异常情况下同步延迟的问题。 - 存储系统同步方式
通过数据库的同步机制将数据复制到其他业务中心 - 回源读取方式
对于登录的 session 数据，由于数据量很大，我们可以不同步数据；但当用户在 A 中心登录后，然后又在 B 中心登录，B 中心拿到用户上传的 session id 后，根据路由判断 session 属于 A 中心，直接去 A 中心请求 session 数据即可；反之亦然，A 中心也可以到 B 中心去获取 session 数据。 - 重新生成数据方式
技巧 4：只保证绝大部分用户的异地多活
异地多活也无法保证 100% 的业务可用，这是由物理规律决定的，光速和网络的传播速度、硬盘的读写速度、极端异常情况的不可控等，都是无法 100% 解决的。
虽然我们无法做到 100% 可用性，但并不意味着我们什么都不能做，为了让用户心里更好受一些，我们可以采取一些措施进行安抚或者补偿，例如：
- 挂公告
说明现在有问题和基本的问题原因，如果不明确原因或者不方便说出原因，可以发布“技术哥哥正在紧急处理”这类比较轻松和有趣的公告。 - 事后对用户进行补偿
- 补充体验
核心思想
异地多活设计的理念可以总结为一句话：采用多种手段，保证绝大部分用户的核心业务异地多活！