【容灾架构】淘宝网/支付宝 异地多活 架构原理学习笔记

【学习背景】

最近在看一本书《蚂蚁金服-科技金融独角兽的崛起》，正看到第七章“技术攻坚”简单介绍了一下支付宝的架构从第一代的烟囱架构、第二代的分布式架构，第三代的云计算架构，其中有个词“异地多活”出现了一次，但没有详细描述。

之前接触的容灾方案，顶多就是两地三中心的双活架构+异地备份，特地从一些公开的资料中尝试学习一下阿里巴巴“异地多活”的架构是什么样的？

 

【为什么两地三中心架构满足不了阿里巴巴的要求】

1、异地节点是冷数据，和最新数据有时差。如果2各生产中心出问题后，没有人有多强的信心能够保障异地起用后是可以正常服务的。因为异地备份中心是冷的，平时没有用户流量进去，意味着拉业务需要时间，也不一定能拉起来。模式看起来很安全，也可用。事实上不一定是这样。

2、异地备份中心因为不对外提供服务，所以整个资源会处于浪费状态，成本比较高。

3、阿里的用户规模非常大，虽然是两地三中心，数据也是在同一个城市写，比如“双十一”的场景中压力非常高的情况下，所有数据都是单点写，由于双十一的用户访问量每年都增幅很大，数据库和业务层面的伸缩面临非常大挑战。

 

【异地多活的技术需求】