读请求应该选择哪个副本？
简化版
副本选择应先满足读一致性，再优化延迟与负载：线性一致读走经过确认的 Leader 或协议支持的安全副本，读己之写要求副本达到会话水位，有界陈旧读过滤 lag 超阈值的副本，最终一致读才可直接选近端健康副本。候选内再按 RTT、队列、错误率和故障域评分。
详细版
只做 round-robin 会把请求发到落后、过载或正在恢复的副本。选择器需要健康、应用水位、角色、路由 epoch、网络距离和负载等信息。
例如会话 token 为 index 500，副本 A/B/C 的 appliedIndex 为 505/498/480；读己之写只能选 A，或者等待 B 追到 500，不能因为 B RTT 更低就返回旧值。
候选副本内可用 EWMA 延迟与 outstanding requests 做 power-of-two choices。跨 AZ 流量有成本，但不能为了省流量违反故障切换和一致性约束。
失败重试要排除已失败副本并传递总 deadline。Hedged read 可降低尾延迟，但会放大负载，必须延迟触发、限额和取消输家请求。
完整版教学
一、选择顺序为什么重要
一致性是资格条件，性能是排序条件。先按最快节点排序再检查语义，容易在高压时选择落后但空闲的副本。正确流程是过滤不合格候选，再在合格集合内做负载均衡。
二、不同读语义的候选集合
| 语义 | 资格条件 | 常见代价 |
|---|---|---|
| 线性一致 | 安全 Leader/读屏障 | 多数确认或租约假设 |
| 读己之写 | applied ≥ session token | 等待或回主 |
| 有界陈旧 | lag ≤ SLO | 可能读旧 |
| 最终一致 | 健康即可 | 无最新值保证 |
“Follower read”不是单一语义。有的系统让 Leader 下发安全时间/closed timestamp，有的只提供陈旧读；必须说明产品协议。
三、用水位保证会话语义
写成功时返回 commit index 或版本 token，后续读携带该 token。副本只有应用水位达到 token 才可服务，否则短暂等待、换副本或回 Leader。
token=500
A.applied=505 -> eligible
B.applied=498 -> wait or reject
C.applied=480 -> reject固定“写后 5 秒读主”是经验窗口；水位判断才是基于实际复制进度的保证。
四、合格副本如何排序
静态就近忽略实时拥塞。可综合 RTT 的 EWMA、在途请求、错误率、磁盘队列和熔断状态。Power-of-two choices 随机取两个候选，选择负载更低者，常以较小元数据成本获得较好均衡。
评分要设陈旧期限，节点上报中断后不能永久使用旧的低负载数据。恢复节点还应渐进放量，避免缓存未热时瞬间接满流量。
五、重试和 Hedged Read
总 deadline 为 100 ms，首次读用掉 70 ms 后，重试只剩 30 ms，不能重新获得完整 100 ms。重试要换故障域并限制次数，否则节点故障会让流量倍增。
Hedged read 可在超过历史 P95 后向第二副本发送相同读，先成功者胜出并取消另一个。它适合幂等读和少量尾请求，不应从请求开始就双发。
六、拓扑、成本与降级
同 AZ 访问便宜且快，跨区副本提供容灾。正常时优先近端，近端全部不满足水位时，业务可选择跨区、等待或返回明确陈旧结果，不能静默降低语义。
监控候选过滤原因、每副本流量、lag、跨区比例、重试放大、hedge 胜率、取消成功率和 P99。若大量请求因水位被过滤，问题在复制/apply，而不只是负载均衡。
记忆钩子：先问“它有没有资格回答”，再问“谁回答最快”；一致性过滤永远在延迟打分之前。
七、常见误区与追问
- 误区：最近副本一定最好。 它可能落后、过载或已失去服务资格。
- 误区：Follower 读都一样。 安全时间读、有界陈旧读和最终一致读语义不同。
- 误区：读重试没有副作用。 会放大故障节点和下游负载，并消耗 deadline。
- 追问：如何保证读己之写？ 携带写入水位，只选 applied 已达到该水位的副本。
- 追问：Hedged read 何时启用？ 只对幂等尾请求延迟触发，并设置额外流量预算。
- 追问：跨区和一致性冲突怎么办？ 一致性优先，跨区成本只能在合格候选间优化。
八、加强记忆
副本选择是两阶段决策：角色、epoch 和应用水位决定资格，RTT、队列、错误率与拓扑决定排名。再用统一 deadline 控制重试，用小比例 hedge 治理尾延迟。若业务允许降级，必须显式返回所提供的一致性等级。