高可用架构：fail-over的三种经典模式 | 架构师之路（10）

《架构师之路：架构设计中的100个知识点》 10.故障转移fail-over的三种经典模式

前面的文章聊过，高可用的核心方法论是：冗余（replication） + 故障自动转移（fail-over）。

冗余很好理解，复制服务，复制数据。那故障转移有几种模式？

故障转移（fail-over）主要有三种模式。

其一：Active-Passive影子主模式。

在这种模式下，只有一个主节点（Active）在处理请求，另一个影子节点（Passive）则处于待命状态，准备在主节点故障时接管。

它的特点是，影子节点在主节点正常工作时并不参与工作，只有主节点发生故障时，影子节点才接管并参与负载。系统资源利用率最多只有50%。

无状态的服务，例如Nginx可以使用影子主模式保证高可用。

其二：Active-Active多活模式。

在这种模式下，所有节点均处于“活动”状态，平均处理负载，其优势是：

一，保证了高可用；

二，提升了吞吐量；

三，实施了负载均衡；

四，提高了资源利用效率；

但是，这类模式需要注意雪崩效应，少量节点挂掉的情况下，剩余节点能不能扛得住。

无状态的服务例如站点服务，微服务，可以采用这种高可用模式。

对于包含状态的服务，例如数据库，如果使用多活高可用。需要额外的机制来同步数据，并解决同步数据的过程中带来的数据冲突问题。对于大数据量高并发量的互联网业务最佳实践，一般不采用这种模式实施数据库的高可用，数据冲突问题根本搞不定。

那包含状态的服务，例如数据库，要怎么保证高可用？

其三：Hot-Standby热备模式。

热备份可以理解为影子模式的一种特例。

他的影子节点在平时也会工作，怎么工作呢？

影子节点只和主节点保持数据同步，但并不对外提供服务。

画外音：这里主要指写入服务，读服务不会变更数据状态，且不讨论。

这样，影子节点保持有最新的数据副本，在主节点挂掉后可以迅速接管，减少切换时间。并且影子节点在平时不对外提供服务，也不会有数据冲突。

在数据库这类存储状态，且需要快速恢复的场景，一般使用热备模式。

但需要注意的是，当主挂掉时，需要折衷一致性与可用性：

1. 如果数据同步完成之前启动影子节点，数据可能会丢失，从而丧失最终一致；

2. 但如果等数据同步完成再启动影子节点，可能会等待一段时间，从而丧失可用性；

简单总结，fail-over三种常见模式：

（1）Active-Passive影子主模式，例如：NG；

（2）Active-Active多活模式，例如：web-server，service；

（3）Hot-Standby热备模式，例如：DB；

知其然，知其所以然。

思路比结论更重要。

补充阅读材料

讲透架构设计中的fail-over：

https://blog.alexewerlof.com/p/failover

5个章节，比我讲得更细：

1. fail-over的概念；

2. fail-over的核心原理；

3. fail-over的关键技术点；

4. fail-over的几种模式；

5. fail-over示例；

文章不长，10分钟读完。