城市级别系统容灾建设方案演进（同城灾备、同城双活、两地三中心、异地双活、异地多活）

本文为文章《两地三中心数据中心和同城双活数据中心的区别？》的阅后简单备忘总结。

虽实际中可能不会从事与该话题直接相关的技术工作，但其背后的的技术原理是相同的。

=================== 以下为总结 ===================

 

 

 

城市级别的系统容灾建设方案，包括 主从副本、同城灾备、同城双活、两地三中心（伪异地双活）、异地双活、异地多活 等。

所谓城市级别，是指这些方案是面向发生城市级别灾难导致该城市内系统不可用的情形来设计的，而不是（至少初衷不是）面向通常理解的同城市内系统中单节点故障的情形。

 

1 为什么要进行系统容灾建设？

提高系统可用性。

。什么概念？想达到4个9以上的可用性，日故障时间不能多于8.6秒。

可见，想提高可用性要么减少故障时间、要么提高正常运行的时间，而故障是不可避免的，进行容灾建设的目的就是为了让系统能尽可能正常地提供服务、并在发生故障时快速恢复。

 

2 容灾方案演进是怎样的？

这些方案的本质是通过冗余来提高系统发生故障时的恢复能力（即减少故障时间），从而提高系统的可用性。

备份、主从副本、同城灾备、同城双活、两地三中心、异地双活，异地多活等都是在做冗余。

而且主要是在数据冗余而不是应用冗余上进行演进，因为前者有状态而后者没有。

 

2.1 机房内机器间冗余

单机架构

缺点：单点故障（磁盘损坏、OS异常、误删数据等）则很容易导致数据全丢失。

 

机房内主从副本

冷备：（1）

　　定期备份存在【恢复需要较多时间造成恢复期间不可用、备份的数据完整性较低（不是最新的，取决于备份周期）】的缺点，解决：数据主从库同步。

热备：（2），（3），（4）

特点：（本质上就是个分布式系统）

数据库在机器间主从冗余部署，主提供读写、从提供读；应用在机器间无差别冗余部署；机器内引入接入层来分发请求到机器内不同应用。

平时主从机器都对外提供服务，但分主次机器。

主机器发生故障时，从机器升级为主机器。

缺点：虽冗余但都在同城机房中，机房故障仍会导致系统不可用。

　　2015 年 5 月 27 日，杭州市某地光纤被挖断，近 3 亿用户长达 5 小时无法访问支付宝

2021 年 7 月 13 日，B 站部分服务器机房发生故障，造成整站持续 3 个小时无法访问

2021 年 10 月 9 日，富途证券服务器机房发生电力闪断故障，造成用户 2 个小时无法登陆、交易

解决：继续冗余——机房间甚至城市间的冗余（见后面的方案）

 

2.2 同城内机房间冗余

同城灾备（同城机房间主从副本）

冷备：（1），定期备份存在与前述同城的同样问题，解决：数据主从库同步。

热备：（2），（3）

特点：（本质上是个集群）

从机房是主机房的镜像——与主机房一样部署有接入层、应用层、存储层等所有东西，但它只是主机房的备份——从机房只有在主机房发生故障不可用后才会接管流量对外提供服务。

机房间用同城专线互通。

本质上与上节的主从副本类似，只不过由机器间的主从变成机房间的主从；但又不太一样，表现在：从机房平时不对外提供服务只有主机房不可用时才会被启用，且不是自动启用故启用需要时间。可见，是个相对比较鸡肋的方案。

缺点：

浪费资源——主机房可用时从机房虽也部署了但不分担流量对外提供服务。

故障恢复时间较长——主机房不可用到从机房启用需要较多时间。

从机房可用性得不到检验和保证——从机房未实时对外提供服务故其是否真的可在主机房不可用时立马“如期”正常工作存疑。

解决：从机房也和主机房类似实时对外提供服务（即下面的同城双活方案）。

 

同城双活

特点：（本质上是个分布式系统）

对同城灾备方案的升级，让两机房同时对外提供服务。

与同城灾备方案相比：增加DNS服务转发到不同机房，需要对业务层做改造以让应用写数据库主库。故提高了资源利用率、提高了系统并发处理能力、提高了可用性和故障恢复速度。

缺点：虽解决了同城灾备的缺点，但与前面所有方案一样存在同城故障——若整个城市发生地震、水灾等自然灾害则可能该城两机房都不可用。

 

 

2.3 城市间冗余

两地三中心（异地灾备）

特点：同城双活 + 异城一灾备

缺点：与同城灾备类似，灾备机房利用率低、启用灾备机房需要时间、启用后不确定是否能按预期工作。

通常应用在银行、金融、政企等项目中。 

 

伪异地双活

特点：同城双活的两个机房部署到不同城市。

缺点：机房间由同城专线变为跨城专线，从机房的写操作需要跨城访问主机房存储，延迟很大。

实际没用这种方案。

 

异地双活

特点：

同城双活的两个机房部署在不同城市。

不同机房内应用只访问本机房内的数据库，而不是像同城双活那样从机房的写操作需要去访问主机房的数据库。

数据同步：数据库为双主架构，互相实时同步。需要开发MySQL、Redis、MongoDB、RabbitMQ、Kafka等存储层的数据同步组件去完成数据同步，应用层只关心本机房内存储层。

数据冲突解决：为免双主架构导致的写数据冲突，两机房之上增加路由层进行请求转发。

转发规则有：按业务类型（比如订单、支付等业务）分片、按哈希分片（比如按用户ID哈希）、按地理位置分片（比如打车、外卖等适合按地理位置）等。（比如打车、外卖等适合按地理位置）。分片的核心思路是让同一用户的相关请求只在一个机房内完成所有业务闭环而不出现跨机房访问。

也有无法进行分片的情形：例如系统配置、商品库存这类需要强一致的数据，这类服务依旧只能采用写主机房，读从机房的方案，不做双活。

缺点：实施复杂、实施和维护的成本大。 路由规则、路由转发、数据同步中间件、数据校验兜底策略，不仅需要开发强大的中间件，同时还要业务配合改造（业务边界划分、依赖拆分）等一些列工作，没有足够的人力物力，这套架构很难实施。

阿里将这种实施方案称为【单元化】，即不同机房几乎完全独立、内聚，彼此间很少耦合，只有存储层依赖同步组件互相进行数据同步。

 

异地多活

（1）网状：，（2）星状：

特点：在异地双活的基础上部署多个机房即可。 可任意扩展新机房，只要最上层定义好请求的分片规则就好。

缺点：实施复杂、实施和维护的成本大。

 

3 总结

演进的目的：提高系统可用性，即发生地震、洪水等自然灾害及挖断光纤等人为灾害时仍能正常对外提供服务。

演进过程：

同机房不同机器：单机架构 -> 主从副本架构

同城市不同机房：同城灾备 -> 同城双活

同地球不同城市：两地三中心（异地灾备） -> 伪异地双活 -> 异地双活 -> 异地多活

演进的本质：设置或增加副本，来提高系统发生故障时的恢复能力（即减少故障时间），从而提高系统的可用性。

演进的方向：单机 -> 集群（部署只备份不干活的副本） -> 分布式系统（副本也干活）

方案的选择：越后者系统可用性越高，但系统也越复杂系统实施和维护的成本也越大，故并不是越后者越常用，需要结合实际权衡。

比如银行、金融、政企等项目常用两地三中心方案；而支付宝、微信等用户量大、日活大的应用则用异地多活来保证极高可用性。