第5章 容错与共识

故障类型、检测与恢复,以及 Paxos、Raft、PBFT。

下载本章 PDF

5.1 为什么要容错

1. 知识点论述

「5.1 为什么要容错」是《分布式计算系统》容错共识部分的核心知识点。回答故障后如何继续服务,以及如何在多数派下达成一致。本知识点首先把握:节点断电、磁盘损坏、网络分区都会发生。学习时请把它放回整门课主线——把独立计算机组织成对用户像一台机器的系统,并用通信、数据放置、复制、容错与调度把这件事做可靠。

2. 视频教程

为什么故障之后还要达成一致:共识算法的前生今世

在B站观看

3. 知识点详解

  1. 节点断电、磁盘损坏、网络分区都会发生。
  2. 目标:故障后自动恢复,同时继续提供服务。

4. 应用场景

  • 任何集群都会遇到断电、坏盘、分区。
  • 目标是自动恢复并继续对外服务。
  • 容错是后续共识与事务的前提。

5.2 故障类型

1. 知识点论述

「5.2 故障类型」是《分布式计算系统》容错共识部分的核心知识点。回答故障后如何继续服务,以及如何在多数派下达成一致。本知识点首先把握:按影响范围:单点故障、网络分区、相关故障。学习时请把它放回整门课主线——把独立计算机组织成对用户像一台机器的系统,并用通信、数据放置、复制、容错与调度把这件事做可靠。

2. 视频教程

拜占庭将军问题是什么

在B站观看

3. 知识点详解

  1. 按影响范围:单点故障、网络分区、相关故障。
  2. 按性质:崩溃停机、遗漏消息、时序异常、拜占庭(任意甚至恶意行为)。

4. 应用场景

  • 区分崩溃故障与拜占庭故障决定协议选型。
  • 网络分区下要警惕脑裂。
  • 相关故障(同机架断电)影响副本放置策略。

5.3 检测与恢复

1. 知识点论述

「5.3 检测与恢复」是《分布式计算系统》容错共识部分的核心知识点。回答故障后如何继续服务,以及如何在多数派下达成一致。本知识点首先把握:心跳:固定周期简单,频率过短会误报,过长会发现得慢。学习时请把它放回整门课主线——把独立计算机组织成对用户像一台机器的系统,并用通信、数据放置、复制、容错与调度把这件事做可靠。

2. 视频教程

HTTP/TCP 长连接与心跳检测

在B站观看

3. 知识点详解

  1. 心跳:固定周期简单,频率过短会误报,过长会发现得慢。
  2. 也可根据历史心跳预测故障。
  3. Gossip:无中心交换邻居状态,适合大规模。
  4. 恢复:冗余接管、回滚到正确状态、把负载从故障节点迁走。

4. 应用场景

  • 心跳与超时是 K8s、云监控的基础。
  • Gossip 适合大规模成员管理。
  • 恢复策略:接管、回滚、迁移负载。

5.4 Paxos

1. 知识点论述

「5.4 Paxos」是《分布式计算系统》容错共识部分的核心知识点。回答故障后如何继续服务,以及如何在多数派下达成一致。本知识点首先把握:角色:Proposer、Acceptor、Learner。学习时请把它放回整门课主线——把独立计算机组织成对用户像一台机器的系统,并用通信、数据放置、复制、容错与调度把这件事做可靠。

2. 视频教程

十五分钟带你了解 Paxos

在B站观看

3. 知识点详解

  1. 角色:Proposer、Acceptor、Learner。
  2. 准备阶段:更高编号的提案让 Acceptor 承诺不再接受更小编号,并带回已接受的值。
  3. 接受阶段:若多数 Acceptor 接受同一值,该值被选定,Learner 学习它。
  4. 要点:在崩溃故障下,多数派保证不会选出两个值。

4. 应用场景

  • 理解多数派表决与“只选出一个值”。
  • 为学习 Raft/Zab 打基础。
  • 配置变更、命名服务等强一致控制面场景。

5.5 Raft

1. 知识点论述

「5.5 Raft」是《分布式计算系统》容错共识部分的核心知识点。回答故障后如何继续服务,以及如何在多数派下达成一致。本知识点首先把握:状态:Follower、Candidate、Leader。学习时请把它放回整门课主线——把独立计算机组织成对用户像一台机器的系统,并用通信、数据放置、复制、容错与调度把这件事做可靠。

2. 视频教程

动画:Raft 选举、脑裂、日志复制与安全性

在B站观看

3. 知识点详解

  1. 状态:Follower、Candidate、Leader。
  2. 选举:Follower 超时后成为 Candidate,任期加一,发 RequestVote。获得多数票成为 Leader。
  3. 投票时还要比较日志新旧,避免日志落后的节点当选。
  4. 日志复制:Leader 追加日志,复制到多数后提交,再应用到状态机。
  5. 安全性:已提交日志不能在新 Leader 上丢失,任期单调递增。

4. 应用场景

  • Etcd、Consul、TiKV 等基于 Raft。
  • 选主与日志复制保证已提交数据不丢。
  • 用 Raft 为 2PC 协调者做高可用。

5.6 PBFT

1. 知识点论述

「5.6 PBFT」是《分布式计算系统》容错共识部分的核心知识点。回答故障后如何继续服务,以及如何在多数派下达成一致。本知识点首先把握:假设节点可能撒谎,不只是崩溃。学习时请把它放回整门课主线——把独立计算机组织成对用户像一台机器的系统,并用通信、数据放置、复制、容错与调度把这件事做可靠。

2. 视频教程

PBFT 共识:预准备、准备、提交

在B站观看

3. 知识点详解

  1. 假设节点可能撒谎,不只是崩溃。
  2. 流程包含预准备、准备、提交,用法定人数掩盖恶意节点。
  3. 代价高于 Raft,只在不能信任故障模型时使用。

4. 应用场景

  • 联盟链、不可信多方协作场景。
  • 理解相对 Raft 的更高消息与延迟代价。
  • 仅在故障模型包含恶意行为时采用。

本章练习(18 题)

1. 容错要面对的典型事件包括?

2. 容错的目标是?

3. 把系统做成容错,不是为了?

4. 崩溃停机和拜占庭故障的差别是?

5. 网络分区属于?

6. 遗漏故障是指?

7. 心跳周期过短的风险是?

8. 用 Gossip 做故障感知的特点是?

9. 检测到故障后的恢复手段包括?

10. Paxos 的三类角色是?

11. 准备阶段里,更高编号的提案让 Acceptor?

12. 多数 Acceptor 接受同一值之后?

13. Follower 超时后会?

14. Raft 投票时还要比较日志,是为了?

15. 日志条目何时可以提交?

16. PBFT 相对 Raft 多应对的是?

17. PBFT 的主要阶段包括?

18. 什么时候才值得用 PBFT?