自动灾备技术分析

这是最常用的高可用技术，简单有效可靠。

前言

灾备，又称灾难恢复(disaster recovery)。指的是， 发生灾难时恢复业务的能力。这就意味着已经发生了灾难，进行补救。它的流程是，前期准备，发现灾难，应对灾难。 大多数系统的自动灾备依赖外部系统实现，一些关键模块则使用分布式共识算法实现内部灾备。

自动灾备的基础

副本（前期准备）

副本是灾备的基础，没有副本拿什么容灾呢。

故障转移（应对灾难）

在当前副本不可用时，需要将流量转移到备用副本上。流量的切换可能是借助某种代理，或通过配置中心来通知上层客户端实现。

代理模式

SLB，Proxy等都是属于代理的方式。代理的好处是上游可以无感知(理论上)，坏处就是代理本身会成为单点，通常需要别的系统保障。

配置模式

比如使用DNS进行切换，DNS生效存在延迟，但也没有更好的办法，因为需要切换DNS时通常是Region级别的故障。 还有一种情况是应用间交互是直连的方式，比如TDDL。配置的更新被同步到Client，会很快生效。

探活（发现灾难）

多副本冗余是前提，故障转移是修复能力。在一切就绪后，什么时候进行故障转移呢？ 所以我们还需要探活，用于判断是否存在故障。通常，探活模块通过租约或心跳检副本是否可用，不过也存在问题。 1. 探活存在间隔，有真空期。 2. 探活模块本身如何保证可用性。

虽然存在探活的间隔，但目前间隔可以压缩至秒级，常见业务可以接收。至于探活模块本身可用性的保证，通常会使用分布式共识算法在模块内部解决。

有状态和无状态

在目前架构中，分布式系统中的应用可以分为两种，有状态和无状态。有状态的应用在无状态应用之上，增加了一个存储并保证数据准确的能力。 最常见的就是数据库和业务应用。通常业务应用都是设计成无状态的，有状态的应用最典型的就是数据库和分布式存储。 那缓存系统属于哪种呢？缓存系统也属于无状态的应用。因为缓存系统并不保证数据准确。

无状态应用的容灾

因为是无状态的应用，所以它可以可以快速扩容(Scale Out)，在故障转移上也非常便捷。 它的关键在于: 1. 有足够的可用副本。 2. 故障转移简单，前置条减少。

有状态应用的容灾

首先，有状态系统需要具备无状态系统的能力。让可靠的副本承接流量是最优方案。 相比无状态应用，有状态应用的故障转移有前置条件，就是副本数据可靠。否则会影响数据质量。所以数据库中有个很重要的模块就是数据同步，数据同步决定副本数据是否可靠，也影响服务的延时。这里需要取舍。

总结

1. 副本，故障转移，探活，是自动灾备的基础。
2. 有状态的应用，需要保证备用副本的可靠性(和主副本一致)，可靠性和延时需要取舍。