Kafka Streams Exactly once功能失效相关配置问题咨询

服务端Broker必填配置 #

• 事务状态主题配置：transaction.state.log.replication.factor必须≥3，transaction.state.log.min.isr必须≥2，保证broker重启后事务元数据不丢失，避免事务状态错乱导致重复提交
• 全局/主题级ISR配置：所有业务主题（含outbound topic）、Kafka Streams自动生成的changelog、repartition内部主题的min.insync.replicas必须≥2，配合已配置的acks=all保证写入数据的持久性，避免broker重启后数据回滚触发重放
• 必须允许幂等生产者：enable.idempotence = true（Kafka高版本默认开启，低版本需手动配置），这是事务和Exactly Once的基础依赖

Kafka Streams 客户端必填补充配置 #

• 事务超时匹配：transaction.timeout.ms必须≤Broker端的transaction.max.timeout.ms（默认15分钟），若拓扑处理耗时较长导致事务超时被Broker主动终止，Streams重试时就会重复生成消息
• 消费隔离级别：必须配置consumer.isolation.level = read_committed，否则会读取到未提交的临时事务消息，误判为重复生成，同时Streams内部消费中间主题也依赖该配置保证事务可见性
• 加工保证级别配置：Confluent 6.1.0对应Kafka 2.7版本，Exactly Once V2已正式转正，建议直接配置processing.guarantee = exactly_once_v2而非beta版本，beta版本存在已知的事务边界处理缺陷，重启时极易触发重复生产
• 内部主题副本配置：显式配置replication.factor = 3，保证Streams自动创建的内部主题有足够多的副本，避免Broker重启时内部主题数据丢失触发状态重放

测试场景校验规则 #

• 关闭多个Broker时，必须保证所有主题（含__transaction_state事务系统主题、业务主题、Streams内部主题）的ISR数量始终满足min.insync.replicas要求，否则事务提交会失败，任务恢复后会重新处理之前的批次导致重复输出
• Broker重启后需等待所有分区Leader选举完成、ISR同步完毕后再验证outbound topic的消息，否则可能看到未提交的临时事务消息，这类消息后续会被标记为废弃，不属于实际重复生产

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