- A+
这是最常用的高可用技术，简单有效可靠。
前言
灾备，又称灾难恢复(disaster recovery)。指的是， 发生灾难时恢复业务的能力。这就意味着已经发生了灾难，进行补救。它的流程是，前期准备，发现灾难，应对灾难。
大多数系统的自动灾备依赖外部系统实现，一些关键模块则使用分布式共识算法实现内部灾备。
自动灾备的基础
副本（前期准备）
副本是灾备的基础，没有副本拿什么容灾呢。
故障转移（应对灾难）
在当前副本不可用时，需要将流量转移到备用副本上。流量的切换可能是借助某种代理，或通过配置中心来通知上层客户端实现。
代理模式
SLB，Proxy等都是属于代理的方式。代理的好处是上游可以无感知(理论上)，坏处就是代理本身会成为单点，通常需要别的系统保障。
配置模式
比如使用DNS进行切换，DNS生效存在延迟，但也没有更好的办法，因为需要切换DNS时通常是Region级别的故障。
还有一种情况是应用间交互是直连的方式，比如TDDL。配置的更新被同步到Client，会很快生效。
探活（发现灾难）
多副本冗余是前提，故障转移是修复能力。在一切就绪后，什么时候进行故障转移呢？
所以我们还需要探活，用于判断是否存在故障。通常，探活模块通过租约或心跳检副本是否可用，不过也存在问题。
1. 探活存在间隔，有真空期。
2. 探活模块本身如何保证可用性。
虽然存在探活的间隔，但目前间隔可以压缩至秒级，常见业务可以接收。至于探活模块本身可用性的保证，通常会使用分布式共识算法在模块内部解决。
有状态和无状态
在目前架构中，分布式系统中的应用可以分为两种，有状态和无状态。有状态的应用在无状态应用之上，增加了一个存储并保证数据准确的能力。
最常见的就是数据库和业务应用。通常业务应用都是设计成无状态的，有状态的应用最典型的就是数据库和分布式存储。
那缓存系统属于哪种呢？缓存系统也属于无状态的应用。因为缓存系统并不保证数据准确。
无状态应用的容灾
因为是无状态的应用，所以它可以可以快速扩容(Scale Out)，在故障转移上也非常便捷。
它的关键在于:
1. 有足够的可用副本。
2. 故障转移简单，前置条减少。
有状态应用的容灾
首先，有状态系统需要具备无状态系统的能力。让可靠的副本承接流量是最优方案。
相比无状态应用，有状态应用的故障转移有前置条件，就是副本数据可靠。否则会影响数据质量。所以数据库中有个很重要的模块就是数据同步，数据同步决定副本数据是否可靠，也影响服务的延时。这里需要取舍。
总结
- 副本，故障转移，探活，是自动灾备的基础。
- 有状态的应用，需要保证备用副本的可靠性(和主副本一致)，可靠性和延时需要取舍。
