Raft读屏障与ReadIndex

读路径需要两种不同证据。“我拥有正确日志”不能证明“我仍有权给这次读排位置”；“刚才多数回复了我”也不能证明执行线程已经处理完日志。ReadIndex分别用新一轮多数确认和应用屏障解决这两个问题。

当前任期提交把前任遗留的已提交前缀接到本leader已知的提交位置。随后的新轮确认与任何新任期选举多数相交：若在这轮探测发出前已经有更高任期leader，交点至少已有更高任期，不会提供本轮所需的有效旧任期确认。因此不能让早已失权的leader凭一份过期心跳读旧状态。

这并不表示收到最后一份确认时leader永远不会失权。它可能随后立刻被替换。线性一致只要求为这次已经开始的读找到合法位置，并不要求它在回复瞬间仍是最新leader。若实现选择在失权时取消未回复的读，也应明确这是更保守的处理。

旧leader为什么能读错 ​

三副本A、B、C起初都在索引10，x=0，A是任期4的leader。先隔离A，B与C在任期5选出B；B把索引11的set(x,1)复制到B、C，提交并应用，然后客户端收到写成功。此后另一客户端才向A调用read(x)。A虽然还自认为leader、本地lastApplied=10，却只能读出0。

实时顺序要求写在读之前，顺序寄存器又要求读返回1，因此没有合法线性化。A的磁盘没有损坏、旧日志完全正确也无济于事；缺的是这次读取的权限证据。A向B、C发新轮探测时，要么收不到多数，要么看到任期5，不能返回本页承诺的成功读。

有多数，还要等应用 ​

B在任期5已提交索引11，但执行线程只到10。读到达后B取r=11，本轮q=37得到B、C两票，仍不能读。应用11后lastApplied=11,x=1，才可以返回1。若把最后一步等待删掉，即使leader真实有效，仍会返回0。

下一次读与索引12的set(x,2)重叠。若读取受保护的状态11，可返回1并放在写12之前；若已应用12，可返回2并放在其后。不能读取“x来自12、另一字段来自11”的混合版本。需要锁、不可变版本或其他一致查询接口保证一次查询对应一个前缀。

为什么本任期no-op不能省 ​

B新当选时可能有前任已提交的条目11，却暂时只知道commitIndex=10。若此刻直接取r=10，即使它刚获得多数心跳，也可能允许执行层停在10读旧值。提交本任期no-op 12会同时提交之前的连续前缀；随后r>=12，查询便不能绕过11。no-op不是修改业务数据，而是补齐leader对于提交前缀的知识。

把读下界记为r后，在该读调用前已完成的写都位于它必须覆盖的前缀中；一致查询至少应用到r。与读重叠的写可按查询实际采用的前缀放在读前或读后。再结合写按日志排列、每次查询只有一个前缀版本，便得到符合实时顺序的顺序历史。不能把所有读的线性化点都机械标成“最后心跳到达”：查询若包含此后才提交的并发写，见证点也要相应后移。

Follower也可代读，但要为这批新读向leader取得按上述步骤产生的r，并在本地等待应用到r；从旧心跳缓存一个commitIndex不能代替这次读的证据。成员正在变化时，本页固定多数必须替换为当前有效配置的相应quorum理路Raft联合配置与成员交接Joint consensus · Raft membership change · Joint configuration用旧新两套多数和有序配置项连接成员变化，计算直接切换的分叉反例、联合提交及新配置生效的时机。，不能默默沿用旧多数。

稳定leader、无丢包、已提交本任期条目的情况下，一批ReadIndex读增加一轮多数往返、O(n)控制消息及执行层追赶等待，不新增每读日志条目。日志读则另有复制payload、日志持久化和后续压缩成本。批大小为b时可把控制消息摊到每读O(n/b)，但批等待会增加延迟；这些不是固定墙钟上界。

租约读用时钟和有效期代替逐批确认，必须另证时钟漂移界、暂停处理、选举和提前移交规则。普通超时配置或“机器已经对时”不是这份证明。本页的异步安全论证不依赖租约。