Part 01
容灾介绍
我们通常会把故障分为三类，一是主机故障，二是机房故障，三是地域故障。每类故障都有各自的诱发因素，而从主机到机房再到地域，故障发生概率依次越来越小，而故障的影响却越来越大。
图片
容灾能力的建设目标是非常明确的，就是要能够应对和处理这种机房级和地域级的大规模故障，从而来保障业务的连续性。近几年，业界也发生了多次数据中心级别的故障，对相关公司的业务和品牌产生了非常大的负面影响。当前容灾能力已经成为众多企业建设信息化系统的必选项。
Part 02
容灾架构演进
容灾架构从最早期的同城主备到同城多活形态，再演化到异地多活，根据这个过程可以将容灾分为容灾1.0、容灾2.0、容灾3.0三个阶段。
- 容灾1.0：容灾体系围绕数据建设，多以主-备的方式部署，但备用机房不承担流量，基本上都是单活结构。
- 容灾2.0：容灾视角从数据转换为应用系统，业务具有同城双活或同城多活能力，采用同城双活或同城双活加异地冷备（两地三中心）的部署架构，除冷备以外的每个机房都有流量处理能力。
- 容灾3.0：以业务为中心，多采用单元化架构，容灾基于单元间的两两互备实现，根据单元的部署位置可以实现同城多活和异地多活。采用单元化架构的应用本身具有很好的容灾能力和扩展能力。
Part 03
常见节点故障处理过程
（1）计算节点故障
分布式数据库的计算节点多采用多实例部署。所以当一个计算节点故障后，负载均衡通过心跳检查识别到故障，自动把请求分发到其他的计算节点上。等到该节点恢复后，负载均衡检测到节点正常服务，会将请求重新均衡到该计算节点上。
（2）存储节点主库故障
当分布式数据库的存储节点集群出现主库故障，集群的健康检查会监测到主库发生故障，并通过多次探测确认故障。如果主库故障确认，系统会控制存储节点集群进行主从切换，将一个从库节点选举为新的主库节点，并调整集群的主从同步关系。同时集群拓扑的元数据会进行更新，推送到集群的各节点，包括查询路由相关信息。这样应用层的写操作会发送到新的主库。此时存在故障的副本节点，根据集群的副本策略和恢复机制，恢复系统会触发一个恢复任务，重新恢复一个新的从库节点加入集群。
（3）存储节点从库故障
当分布式集群的一组主从出现从库节点故障，集群的健康检查模块会监测到从库故障，并通过多次探测来确认故障。如果确认从库故障，系统会将该从库进行下线处理。同时集群拓扑的元数据会进行更新，将该故障的从库节点从集群信息中删除，并推送到集群的各节点进行更新。查询路由相关的信息更新后，应用层的读操作不再发送到故障的从库。此时由于存在一个故障的副本节点，根据集群的副本策略和恢复机制，系统的恢复系统会触发一个恢复任务，重新恢复一个新的从库节点加入集群。
（4）网络故障
专线网络抖动异常一般会带来延时和丢包，集群的计算服务节点、存储服务节点、管控节点之间的通讯都有完备的超时重试机制，少量的延时丢包不会影响查询性能，跨专线的主从延时会增大，待网络质量恢复后即恢复正常。
Part 04
容灾架构案例介绍
（1）美团数据库容灾方案
美团的容灾架构主要包括两种，一种是N+1容灾架构，一种是SET化架构。
N+1架构：在业界也称散部或者多AZ部署⽅案，将容量为C的系统部署在N+1个机房，每个机房能提供至少C/N的容量，挂掉任何一个机房时，剩余系统仍能支撑C的容量。该方案的核心是把容灾能力下沉到PaaS组件来完成，在出现机房级或者地域级故障的时候，由各个PaaS组件独立完成容灾切换，实现业务恢复。整体架构如下图所示，业务上表现是多机房、多活形态，数据库采用这种主从架构，单机房处理写流量、多机房的负载均摊读流量。下面要讲“数据库容灾体系建设实践” 就是面向N+1架构的。
图片
SET化架构：这是一种偏应用层的容灾架构，它将应用，数据，基础组件按照统一的维度切分成多个单元，每个单元处理一部分闭环流量。业务以单元作为部署单位，通过单元互备方式实现同城容灾或者异地容灾。一般金融业务或者超大规模的业务会选择此类架构，它的好处就是流量可以闭环且资源隔离，具有很强的容灾能力和跨域扩展能力，不过SET化架构的落地需要业务系统做大量的改造，运维管理也较为复杂。简化示意图如下：
图片
（2）阿里数据库容灾方案
DT大淘系数据是阿里巴巴集团典型的数据中台，DT引入了Hologres的读写分离能力，并结合全链路的主备双链路，在降低单库出问题概率的同时构建异地主备容灾，建立产品核心指标的“复活甲”，通过秒级切换的高可用容灾方案，高吞吐写入和灵活查询互不干扰，分析查询QPS增长80%的同时，查询抖动明显减少，让业务拥有底气和信心去应对随时可能出现的不可控风险，为整个产品和业务决策分析提供稳定支持。
图片
（3）浪潮数据库容灾方案
与传统的数据灾备和复制技术不同，浪潮K-DB和DSG SuperSync方案是针对Oracle数据库的异构灾备和数据复制方案，提供了基于逻辑的交易复制方式。该方式通过直接捕获Oracle数据库的交易，将数据库的改变逻辑复制到K-DB数据库中，实现Oracle系统数据库和K-DB系统数据库数据的一致性，从而提高系统数据的安全性和灵活性，降低灾备系统TCO，系统架构如下：
图片
K-DB Standby Cluster提供同构数据库的高可用性、数据的保护、灾难恢复功能，DSG SuperSync提供异构数据库的高可用性、数据的保护、灾难恢复功能。
（4）腾讯数据库容灾方案
客户业务场景最常用腾讯云数据产品主要是redis，cdb，mongoDB以及TDSQL。
图片
Part 05
结束语
系统建设过程中高可用自动切换、容灾能力运营治理、大规模故障观测、故障止损预案、容灾恢复等方面都会有很多的需求和挑战，也是所有公司业务发展壮大后必须面对的一件事，欢迎大家能跟我们一起交流这个过程，共同进步。
