Kafka两阶段提交中途故障：事务状态与恢复机制问询

场景背景：在Kafka两阶段提交的第8步执行中途，已成功向分区P0、P1提交事务标记，但尚未完成P7的提交标记写入时，出现两种故障场景：Coordinator宕机，或底层存储节点故障。当前状态为P0、P1的事务消息对read_committed隔离级别的消费者可见，P7的事务消息不可读。

问题与解答 #

1. 是否会失去“要么全有要么全无”的事务原子性特性？ #

不会丢失事务原子性。Kafka事务的原子性靠Coordinator维护事务状态的最终一致性：

• 不管是Coordinator还是底层节点故障，未完成提交的P7都会被后续恢复流程识别为事务未完成状态
• 最终所有参与事务的分区要么全被标记为提交（对read_committed消费者可见），要么全回滚（全部不可见），不会出现部分可见、部分不可见的永久状态。

2. 系统将如何进行故障恢复？ #

两种场景的恢复逻辑存在差异：

场景一：Coordinator宕机

• 新选出来的Coordinator会读取事务日志恢复该事务的元数据，包括所有参与分区（P0、P1、P7）以及当前事务处于提交中途的状态
• 新Coordinator检查所有分区的事务标记状态后，会发现P0、P1已提交，P7未完成
• 它会重新向P7发送提交标记，直到写入成功；如果多次尝试失败，会触发事务超时机制，最终决定回滚整个事务（但通常会优先完成提交流程）

场景二：底层节点故障（存储P7的Broker宕机）

• P7所在Broker宕机后，Kafka会先触发分区副本选举，选出新的Leader副本
• 原Coordinator（或故障恢复后的新Coordinator）会继续推进未完成的提交流程，向P7的新Leader发送提交标记
• 待P7的提交标记写入成功，整个事务完成，所有分区的消息对read_committed消费者可见；如果副本选举后仍无法完成写入，会触发事务超时回滚，所有分区的事务消息都会被标记为aborted，消费者无法读取。

3. 若Coordinator宕机，未标记提交的P7消息是否会导致read_committed级别的消费者无法推进？ #

不会导致消费者永久卡壳。read_committed消费者处理到P7所在分区时，会发现这里有未完成的事务，此时会暂停消费该分区，等待事务状态明确（提交或回滚）：

• 当新Coordinator完成P7的提交标记写入后，消费者会识别到事务已提交，继续消费P7的消息
• 如果事务最终被回滚，消费者会跳过P7的事务消息，继续推进消费进度
• 另外，P0、P1这些已完成提交的分区的消费不受影响，消费者可以正常处理这些分区的消息。

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