https://cloud.tencent.com/developer/article/1993847?areaSource=&traceId=
今天看到一篇写的很不错的文，想着自己总结一下。
异地多活到底是什么？为什么需要异地多活？它到底解决了什么问题？究竟是怎么解决的？
让我们从最基础的开始往上垒。
这个图我想会点开这篇博客的朋友应该都不陌生了，就不需要我多做解释了。
我很喜欢的一句话和大家分享一下：很多模式是不能直接复制的。当数量级直线上升的时候，其背后的难度是几何增长的。
图中小数点后的一个9，对系统的要求那绝对是更上一层楼了。
难点一般体现在3个方面： 1、硬件故障：CPU、内存、磁盘、网卡、交换机、路由器等 2、软件问题 3、不可抗力：天灾人祸
这些风险随时都有可能发生，在面对故障时，我们的系统能否以最快的速度恢复，成为了可用性的关键。
我们来走一走这条艰难发展之路，感受一下前辈们的智慧。在发展的过程中都出现了什么问题，以及思考前辈们为什么会选择当初那个方案。
早期发展的架构模型，如果你的业务量比较少的话可以用这个。客户端请求进来，业务层读写数据库，返回结果。 不要看不上这个架构，我个人觉得目前这个架构在跨界领域还是应用面比较广的。
随着互联网业务量的增长，瓶颈开始出现了。这里的数据库是单机部署的，所以一旦这个数据库遭遇意外，那这个损失将是巨大的。
于是，一个新的方案出来了：备份。
你可以对数据做备份，把数据库文件定期备份到另一台机器上，这样，即使原机器丢失数据，你依然可以通过备份找回数据。
这个方案自己玩玩就好了，真要铺开来使用存在两个问题： 1、耗时长。 2、数据不完整。
那有什么更好的方案，既可以快速恢复业务？还能尽可能保证数据完整性呢？
但是呢，作为商业型公司要获利就要开源节流嘛，平白整个数据库在那边是不是要利用起来，这时候考虑到主库既要读又要写，压力有点大，从库闲着也是闲着，那就让它分担掉绝大部分读的压力吧。
这就是 “读写分离”。 这里有个误区：读写分离并不是完全分离的干干净净，因为主从之间毕竟还是存在延迟的，所以有些核心数据还是需要从主库获取第一手数据的。
流量高了，既然数据库都可以部署多个，那业务层是不是也可以部署多个嘞？
既然是分摊流量，则需要一个分摊的规则，不然可就乱套了，于是出现了 负载均衡。
到这里，已经基本成型成为现在的主流方案了。但是，这样就可保万全了吗？
让我们把眼界往上提升一个档次。
一个机房有很多服务器，这些服务器分布在一个个的机柜上，如果你使用的这些机器，恰好在一个机柜上，且连接这个机柜的 交换机/路由器 发生了故障，那么你的应用依旧有 GG 的风险。
部署在一个机柜有风险，那把这些机器打散，分散到不同机柜上，是不是就没问题了？
这样确实会大大降低出问题的概率。但我们依旧不能掉以轻心，因为无论怎么分散，它们总归还是在一个相同的环境下：机房。
有的人可能会觉得有点小题大做了。 （如果觉得没有必要，那就没有必要吧）
体量很小的系统，它会重点关注「用户」规模、增长，这个阶段获取用户是一切。等用户体量上来了，这个阶段会重点关注「性能」，优化接口响应时间、页面打开速度等等，这个阶段更多是关注用户体验。 等体量再大到一定规模后你会发现，「可用性」就变得尤为重要。像微信、支付宝这种全民级的应用，如果机房发生一次故障，那整个影响范围可以说是非常巨大的。
所以，再小概率的风险，我们在提高系统可用性时，也不能忽视。
分析了风险，再说回我们的架构。那到底该怎么应对机房级别的故障呢？
一个数据库会出问题，那就两个数据库。一个机房会出问题，那就两个机房。 简单起见，你可以在同一个城市再搭建一个机房。原机房为A，新机房为B，两个机房之间的网络用一条专线连通。
A机房的数据，定时在B机房做备份（拷贝数据文件），这样即使是A机房遭到严重损坏，B机房的数据也不会丢失。这种方案被称之为冷备。
但是前面单机冷备会出现的问题（慢 + 数据缺失 + 闲置）这里依然会出现，于是我们把那个模式复制到这里来看看：
这样的话，即使整个A机房挂掉，我们很快就能恢复服务： 1、B 机房所有从库提升为主库。 2、DNS 指向 B 机房接入层。
这种方案，我们称之为 热备。
同城灾备的最大优势在于，我们再也不用担心「机房」级别的故障了，一个机房发生风险，我们只需把流量切换到另一个机房即可。
虽然我们有了应对机房故障的解决方案，但这里有个问题是我们不能忽视的：A 机房挂掉，全部流量切到 B 机房，B 机房能否真的如我们所愿，正常提供服务？
To be,or not to be,it’s a question.
都说用进废退，没有扛过那么大压力的 B 机房，是否不孚众望谁也说不准。而且这不还有个 闲置 的问题要解决一下嘛。
因此，我们需要让 B 机房也接入流量，实时提供服务。一是可以实时训练这支后备军，让它达到与 A 机房相同的作战水平，随时可切换；二是 B 机房接入流量后，可以分担 A 机房的流量压力。
业务改造完成后，B 机房可以慢慢接入流量，从 10%、30%、50% 逐渐覆盖到 100%，你可以持续观察 B 机房的业务是否存在问题，有问题及时修复，逐渐让 B 机房的工作能力，达到和 A 机房相同水平。
这种方案我们把它叫做「同城双活」。
我们的架构随着风险等级的提升在不断的升级，现在也该到了可接受的最高的风险等级了吧：天灾人祸。 （这里不考虑什么星际问题哈）
如果是整个城市发生自然灾害，那 2 个机房依旧存在「全局覆没」的风险。
但这次冗余机房，就不能部署在同一个城市了，你需要把它放到距离更远的地方，部署在「异地」。
按照前面的思路，把 C 机房用起来，最简单粗暴的方案还就是做「冷备」。
这种方式称之为两地三中心。这会儿不用我多言了吧，该改进。
按照上面的思路，只要把 “同城双活” 那一趴的图里的 “A机房”、“B机房”放到两个不同的城市好了。但是现实是如此的吗？
因为是异地，两个机房之间的专线也将升级为 跨域专线 了。受物理距离的限制，两地之间的网络延迟就成为了不可忽视的因素。
不止是延迟，远距离的网络专线质量，是远远达不到机房内网络质量的，专线网络经常会发生延迟、丢包、甚至中断的情况。总之，不能过度信任和依赖「跨城专线」。
既然「跨机房」调用延迟是不容忽视的因素，那我们只能尽量避免跨机房「调用」，规避这个延迟问题。
这时候就不能再采取原先的 “主从架构”了，因为两地的服务器都要提供读写功能，且要保持数据的一致性。
MySQL 本身就提供了双主架构，它支持双向复制数据，但平时用的并不多。而 Redis、MongoDB 等数据库并没有提供这个功能，所以，你必须开发对应的「数据同步中间件」来实现双向同步的功能。
此外，除了数据库这种有状态的软件之外，你的项目通常还会使用到消息队列，例如 RabbitMQ、Kafka，这些也是有状态的服务，所以它们也需要开发双向同步的。
于是乎，整个架构改版成为这个样子了：
那么，这个架构又存在了什么样的问题呢？分布式的数据一致性问题。
麻烦吧。其实这个解决方案倒是直观，直接划分流量即可。打游戏的时候还有分：华东区、华南区、华中区等，这不就是个很现成的解决方案嘛。
或者也可以通过别的方式，如哈希分片等，反正只要确保让同一个用户的相关请求，只在一个机房内完成所有业务「闭环」，不再出现「跨机房」访问。，从源头避免数据冲突！
当然，最上层的路由层把用户分片后，理论来说同一个用户只会落在同一个机房内，但不排除程序 Bug 导致用户会在两个机房「漂移」。安全起见，每个机房在写存储时，还需要有一套机制，能够检测「数据归属」，应用层操作存储时，需要通过中间件来做「兜底」，避免不该写本机房的情况发生。
这里还有一种情况，是无法做数据分片的：全局数据。 例如系统配置、商品库存这类需要强一致的数据，这类服务依旧只能采用写主机房，读从机房的方案，不做双活。 == 双活的重点，是要优先保证「核心」业务先实现双活，并不是「全部」业务实现双活。==