自动灾备技术分析

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

前言

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

自动灾备的基础

副本(前期准备)

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

故障转移(应对灾难)

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

代理模式

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

配置模式

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

探活(发现灾难)

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

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

有状态和无状态

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

无状态应用的容灾

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

有状态应用的容灾

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

总结

  1. 副本,故障转移,探活,是自动灾备的基础。
  2. 有状态的应用,需要保证备用副本的可靠性(和主副本一致),可靠性和延时需要取舍。
© 版权声明
THE END
广告
喜欢就支持一下吧
点赞0 分享
评论 抢沙发
头像
欢迎您留下宝贵的见解!
提交
头像

昵称

取消
昵称表情

    暂无评论内容