网络分区

沉默不说明故障，回执却可以提供证据 ​

设五个投票副本的成员列表固定为 $\{A,B,C,D,E\}$。$A$ 收不到 $D,E$ 的消息，可能因为对方崩溃、链路隔离，也可能只是很慢。仅凭沉默，$A$ 无法断言对方已经停止，更不能断言它们没有接收新的客户端请求。

但若 $A$ 已取得本次操作来自 $A,B,C$ 的有效确认，它就确实收集到了五个成员中的三个，知道自己形成了多数法定人数。无法判定远端为何沉默，不等于无法验证已经收到的多数证据。 验证还须绑定正确的成员配置、任期与操作，旧回执不能直接当作当前授权。

崩溃故障理路崩溃故障Crash failure进程停止执行且此后不再采取步骤的故障。约束的是进程此后不再执行；分区约束的是消息不能跨越某些边界。一个被隔离的旧领导者可能仍在运行，甚至仍认为自己是领导者。协议必须约束它能完成哪些操作，而不能只寄希望于它主动察觉隔离。

一次写入为什么会让另一侧的读取陷入两难 ​

五副本最初都保存 $x=0$，随后分成 $\{A,B,C\}$ 和 $\{D,E\}$。考虑下面的顺序：

若写入已完成之后，另一客户端才向 $D$ 发起读取，线性一致性理路线性一致性Linearizability每次操作可放置在调用与返回之间的单点，使历史等价于满足实时顺序的顺序规范。要求这次读反映已经完成的写入。返回旧值 $0$ 不满足该要求；凭空返回 $1$ 也不是办法，因为在另一个对 $D$ 完全相同的执行里，远端可能写入的是 $2$，甚至没有写入。

少数侧可以等待通信恢复，或拒绝这类需要新鲜状态的读取；也可以通过另一个明确标注为陈旧读取的接口返回缓存。后者改变了接口承诺。一个及时返回的“服务不可用”错误，并不等于完成了 CAP 定义中要求成功响应的读写操作。持续分区下，这个不可区分性正是 CAP 定理理路CAP 定理CAP theorem网络分区期间，系统不能同时保证所有请求可用与线性一致性。的核心。[1]

多数派解决的是协调条件，不是所有故障 ​

任意两个三成员子集必有交点，所以两个隔离部分不能同时各自取得五成员系统的新多数。但“有交点”还不够：交点副本必须遵守投票限制，保存必要状态，并在新领导者产生时传递已提交历史。Raft理路Raft 共识协议Raft consensus algorithm以任期、选主和复制日志实现崩溃容错共识的协议。把这些要求落实为任期、选举限制、日志匹配和提交规则，避免不同多数在不同时刻批准互不兼容的历史。[2]

三副本一侧也不是一恢复内部通信就立即完成所有请求。它仍可能需要选举、日志追赶和一次安全的读取确认；活性还依赖调度、稳定通信与存储进展。两副本一侧则可能继续做不依赖全局协调的本地工作。“能运行”和“有权提交”是两回事。

分区也不必是 $3+2$。若分成 $2+2+1$，任何一侧都没有多数。临时把自己看得见的节点重新定义成完整成员集，会让两边各自宣称多数；成员变更必须由另外的安全协议管理。

成员视图不一致时，稳定评分放置理路Rendezvous哈希放置Rendezvous hashing · Highest random weight hashing · HRW hashing按键与稳定节点身份评分形成全序，在成员变化中保持幸存节点相对顺序，并区分概率份额、容量权重和复制资格。也只能各自按本地候选集合算出赢家：同一键在包含A的视图中可能选A，另一视图排除A后选B。两次计算都符合输入，仍未形成共同独占授权；哈希选择不替代本页要求的成员变更与确认协议。

法定人数系统理路法定人数系统Quorum system · Quorum family以相交的副本子集族在部分参与者之间传递一致性证据的模型。把操作所需的共同证据明确化。实际设计应逐项说明写入、读取、选举各自需要什么确认，而不是用“支持分区容错”替代接口语义。

租约与 fencing token 处理的是另一层授权。租约要依赖明确的时钟和有效期假设；fencing token 则让资源接收方拒绝落后于已见令牌的旧请求。只有令牌单调生成、随操作传递且由实际资源校验，才形成隔离效果；它不会自动让所有远端机器立刻知道旧领导者已经失去资格。

分区恢复后，通信连通不代表状态已经收敛。日志型系统要追赶并处理未提交的分叉；允许并发写入的系统则需要规定合并、冲突呈现或人工裁决方式。选择什么恢复机制，取决于分区期间到底允许了哪些操作。