CockroachDB中Range的Leaseholder与Raft Leader分区时的处理及过期读疑问

CockroachDB会尝试确保leaseholder与Raft Leader为同一节点，但这并非强制要求（除Leader Lease机制外）。当某一Range的Raft Leader与leaseholder分属不同节点，且二者之间发生网络分区时，会出现什么情况？
假设leaseholder将写请求转发至Raft Leader，Raft Leader将该写入操作追加至自身Raft日志，再转发至其跟随者。若该写入操作达成了法定人数（quorum），但此quorum不包含leaseholder，那么该写入会在Raft Leader及quorum内的跟随者磁盘上提交，而leaseholder因不在quorum中不会提交此写入。
对于后续由leaseholder处理的读请求，是否会返回stale read（过期读）？

结论：不会返回过期读，读请求会被拒绝而非返回旧数据 #

具体分析： #

• Lease有效性校验逻辑
  CockroachDB的leaseholder在处理任何读请求前，必须确认自身的lease仍然是集群中最新的有效租约。由于lease的变更（包括续租、转移）需要通过Raft共识提交，当leaseholder与Raft Leader所在的集群分区时，它无法获取集群的最新状态——既不知道已有新写入提交，也无法确认自己的lease是否已被集群通过共识撤销或过期。

• 分区场景下的读处理行为
  在这种网络分区状态下，leaseholder无法与Raft Leader通信以完成lease有效性校验，因此会直接拒绝读请求，而不是返回本地存储的旧数据。这是CockroachDB为保证线性化一致性的核心设计：宁可不提供服务，也不返回可能过期的结果。

• 后续集群自愈逻辑

  • 若leaseholder的租约到期且无法续租，Raft Leader所在的quorum会发起新的lease选举，将lease转移至集群内可达的节点（通常是Raft Leader自身），之后读请求可以正常由新的leaseholder处理，返回最新提交的数据。
  • 当分区恢复后，原leaseholder会同步集群的最新Raft日志，包括之前提交的写入和可能的lease变更，之后才能恢复正常服务。

内容的提问来源于stack exchange，提问作者kevcao