当ISR故障或写入失败、消息已写入leader时的处理及consumers访问规则

核心前置认知 #

所有场景的判定都基于Kafka副本机制的两个核心边界：

• 生产者消息发送到leader后，会先追加持久化到本地日志文件，再触发其余ISR副本的同步拉取流程
• 消息的「已提交」判定，以leader维护的*高水位（HW）*为界：只有被所有ISR副本同步完成的消息，才会被划入高水位以下，标记为可对外交付的安全消息；高水位以上的消息即使已经持久化在leader上，也属于未提交状态

场景1：ISR副本宕机但消息已成功写入leader #

• Kafka Controller会定期巡检所有副本的存活状态与同步进度：如果宕机副本的日志进度落后leader超过replica.lag.time.max.ms配置的阈值，会被正式移出ISR集合
• 如果宕机后剩余ISR集合规模仍满足min.insync.replicas的最低副本数要求，已经写入leader的消息会正常等待剩余副本同步，达到生产者配置的acks标准后正常标记为已提交
• 宕机副本后续重启后，会从本地日志的最后同步点开始追拉leader的消息，直到进度追平leader的LEO（日志末端位置）后，会被重新加回ISR集合
• 如果宕机后ISR集合规模低于min.insync.replicas要求，该topic的写入请求会直接返回失败，直到有足够的副本恢复同步、回到ISR集合

场景2：向所有ISR副本写入消息失败，但消息已持久化到leader #

• 这类场景下，leader不会主动删除已经持久化到本地的该条消息，会将其保留在日志中等待后续恢复的副本追数
• 对生产者侧来说，这次写入因为没达到配置的acks同步要求，会被判定为失败，返回对应的超时、副本同步不足类错误码
• 后续流程分两种走向：如果ISR副本恢复正常、追平了该条消息的进度，之前留在leader本地的这条消息会正常被标记为已提交；如果leader后续发生故障触发换主流程，新选举的leader只会基于已提交的高水位范围做日志对齐，这条未被同步的消息会在后续的日志截断流程中被清除

场景3：写入请求失败时，消费者能否获取已持久化在leader的这条消息 #

• 默认配置下：消费者仅能读取高水位以下的已提交消息，因为写入请求未完成ISR同步，消息处于高水位以上，所有消费者都无法读到
• 特殊配置下：如果消费者将isolation.level设置为READ_UNCOMMITTED，会绕过高水位的读取限制，可以直接读到leader本地已持久化、但未完成ISR同步的这条消息

场景4：消费者能否读取"未提交"的数据 #

• Kafka默认的消费逻辑是高水位约束下的只读已提交消息，正常生产配置下消费者完全无法读到未提交的数据
• 只有主动将消费者的isolation.level参数调整为READ_UNCOMMITTED时，才能放开未提交消息的读取权限；该配置仅用于本地调试、特殊容错流处理场景，生产环境不推荐开启

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