一，容灾的要求#
1、服务质量协议（SLA，Service Level Agreement）的要求#
SLA 的要求一般是规定一定期限内需要恢复服务。SLA 的要求不能满足的情况下，往往需要对客户有相应金额的赔偿或说明，其风险相对可控。
2、事务正确性的要求#
我们知道事务有 ACID 四个特性，分别是原子性（ Atomicity ）、一致性（ Consistency ）、隔离性（ Isolation ）和持续性（ Durability）。金融系统中，原子性的要求最为苛刻，即事务包含的所有操作要么全部成功，要么全部失败回滚。事务正确性要求一旦不能满足，系统就会出现大的混乱，其风险相对较高。比如，在 ATM 取款的时候，显示扣款成功，但 ATM 机突然断电，来不及吐出现金，此时就要恢复到没取钱时候的状态。
容灾的要求就是针对以上两种的要求，需要结合成本，在 SLA 级别、事务正确性级别做一平衡。比如说，容灾的要求不能满足事务正确性的要求，仅仅保证 SLA 的要求，但其成本却比 SLA 所需的赔偿预算还要大，那么这样的容灾其实是没有意义的。这种情况下，用日常的利润的一部分来作为容灾的赔付基金即可以满足需求。再比如说，有些金融业务，业务量小，客户少，（但可能金额高），其 SLA 的要求较低，可以是几天，甚至是几个月。这种情况下，容灾的成本就不能很高。
二，容灾监控#
实现容灾的前提是要先有监控。金融机构，尤其是银行，往往用跨机房的容灾监控来实现。
1，监控数据本地异步备份#
监控数据本地异步备份，跨机房的监控系统彼此之间互相监控。
2，监控实时和延时#
推（push）：业务系统主动地将业务指标推送给监控系统，比如心跳线，从而实现实时监控。这种做法实时性较强，但对资源的要求也较高。
拉（pull）：监控系统定期地从业务系统中拉取监控指标，比如爱数的日志运维工具 AnyRobot，可以通过标准协议（比如 Syslog、SNMP、SSH、JDBC 等）从业务系统中拉取监控指标。
3，监控本身也会出错#
监控发现错误的时候就会启动容灾，但是监控本身也会出错，此时容灾的时候要考虑监控的伪报问题。
三、容灾处理#
1，服务容灾处理#
有状态和无状态服务是两种不同的服务架构，其判断依据 —— 两个来自相同发
起者的请求在服务器端是否具备上下文关系。
无状态的服务则可以将请求发送到任意一台 server 上，然后就可以通过负载均衡等手段，实现水平扩展。比如说通过 cookie 保存 token 的方式传输请求数据。
来源：CSDN 博主「༺鲸落༻」的原创文章
原文链接：https://blog.csdn.net/nsx\_truth/article/details/108917851
而事务的处理就需要有状态的服务，比如说电商的购物流程，从购物车 — 订单填写 — 付款等一系列操作。这种情况下可以使用 Session 来维系登录用户的上下文信息。虽然 http 协议是无状态的，但是借助 Session，可以使 http 无状态服务转换为有状态服务。
来源：CSDN 博主「༺鲸落༻」的原创文章
原文链接：https://blog.csdn.net/nsx\_truth/article/details/108917851
无状态服务的容灾相对简单，本身服务的调度算法会将服务调度到不同的节点。有状态服务的容灾则是把服务节点按照数据节点处理。
2、数据容灾处理#
1）单节点容灾
单节点的数据写入操作的过程可以分为：应用缓存 —OS 缓存 — 硬件控制器缓存 — 硬盘存储。在这个过程中，出现断电，都会导致写入的失败。目前解决方法有两种：一是使用带电池的硬盘来延缓断电的时间，保证最终硬盘存储全部完成。二是使用集群 + 负载均衡来保障业务的高可用。（这里要注意集群即可，而非分布式。两者区别可参考：《分布式与集群的区别与好处》）
2）多节点容灾
在银行的系统中，我们经常听到两地两中心或者两地三中心或者三地五中心的说法。不管是哪一种，都是利用了共识（consensus）算法，其中最著名的就是 Raft 共识算法。Raft 分主从节点，至少需要 2 个节点，如果只有一个节点了，那就谈不上分布式。Raft 的部署一般有 3 个备份节点或 5 个备份节点两个选项，至少要求一半的节点以上在线才能正常工作。
先看两地两中心（3 个备份）的情况，即一个数据中心有 1 个节点，另一个数据中心有 2 个节点的情况。此时如果单个节点出现故障，由于另外 2 个节点可以正常工作，那么是可以正常工作的。但是如果拥有 2 个节点的数据中心出现故障，由于只剩一个节点，无法满足一半的节点在线，则整个系统无法正常工作。这种设计可以满足单节点的容灾，但不能满足数据中心级的容灾。
接下来看两地三中心（3 个备份）的情况，即三个数据中心都有 1 个节点，其中两个数据中心在一个城市。这种情况下，上述两地两中心的数据中心级别的故障如果发生的话，并不会影响工作，但是如果城市级别发生故障，比如说地铁施工挖断了城市光纤，那么又会出现只剩一个节点，则整个系统无法正常工作。** 这种设计可以满足数据中心级的容灾，但不能满足城市级的容灾。** 两地三中心这种架构是目前很多银行正在使用的一种架构，因为国家针对银行的灾备能力做过要求，资产超过多少多少的一定要做两地三中心架构，以保证银行系统的稳定。但两地三中心和双活还是有一些区别，前者区分数据中心和灾备中心的角色，后者灾备中心也可以是数据中心，对技术要求比较高。
最后我们看三地五中心，即三个不同城市，建立 5 个节点。这种架构差不多是目前金融系统最高级别的容灾架构了，可以满足城市级的容灾。蚂蚁金服曾经就以此秀过一次。但是这种方案目前采用得很少，银行一般到两地三中心就差不多了，券商很多也就是双活，根本没有资源去建立庞大的多节点容灾系统。
四、容灾与灾备#
容灾和灾备并不能简单地划等号，后者的范畴更大，包括备份和容灾。不过，备份的目的仍然是为了容灾，如果备份是成功的，但当系统发生故障，需要恢复的时候，通过备份恢复需要几天的时间，即 RTO 过长，这个情况下的备份其实是没有意义的。或者说数据量太多，每天的备份时间不够，比如很多银行的数据库系统在一个晚上是备不完的，这样就谈不上容灾，更不能说灾备了。
我在之前写过一篇《备份技术概述》，介绍了 CDP 备份和 CDM 备份。这两种备份技术都可以较好地为容灾服务。前者的 RTO 近乎为 0，后者的 RTO 也很短，而且可以实现双活，有效地利用了备份数据，都是不错的选择方案。国内灾备龙头企业爱数的分级保护技术就是把定时备份、CDP 备份、CDM 备份同时应用在银行的两地三中心的灾备上。
来源：爱数学院
参考文献：#
任杰，《如何实现正确的跨机房实时容灾》