配置exactly_once的ksqlDB宕机后出现重复数据如何排查？

你当前仅配置了处理语义参数，还有多端的事务、副本相关配置遗漏，会导致事务提交失败、offset未持久化，最终出现数据重复：

• Kafka Broker 端必配
  • transaction.state.log.replication.factor：事务状态topic的副本数，测试环境单broker可设为1，生产环境至少3，必须大于等于transaction.state.log.min.isr的值
  • transaction.state.log.min.isr：事务状态topic的最小ISR数，测试环境单broker可设为1，生产环境至少2
  • transaction.max.timeout.ms：broker允许的最大事务超时时间，必须大于ksqlDB端配置的事务超时时间，默认900000（15分钟）
• ksqlDB 端必配
  • KSQL_KSQL_STREAMS_REPLICATION_FACTOR：ksql自动创建的内部topic（changelog、repartition）的副本数，测试环境可设为1，生产环境至少2
  • KSQL_KSQL_STREAMS_TRANSACTION_TIMEOUT_MS：ksql producer的事务超时时间，必须小于broker的transaction.max.timeout.ms，默认600000（10分钟）
  • 建议显式配置KSQL_KSQL_STREAMS_CONSUMER_ISOLATION_LEVEL=read_committed，避免版本兼容问题导致自动配置未生效
  • 若使用内存状态存储，建议切换为RocksDB持久化状态存储，降低OOM时状态丢失导致的重复处理风险

• 先验证重复数据的真实性：使用kafka官方控制台消费者加读已提交参数消费输出topic，确认不是消费工具默认读未提交导致的误判，命令参考：kafka-console-consumer.sh --bootstrap-server <broker地址> --topic TEST_FINAL --isolation-level read_committed --from-beginning
• 排查broker日志：搜索关键词abort transaction、transaction timeout，确认是否存在事务被broker主动中止的情况
• 排查ksqlDB运行日志：搜索ProducerFencedException、InvalidProducerEpochException、TransactionTimeoutException等事务相关异常，确认故障发生前是否有事务提交失败的报错
• 验证运行时配置是否生效：调用ksqlDB的GET /config接口，确认processing.guarantee、isolation.level、enable.idempotence等参数的实际值和预期一致，未被其他配置覆盖
• 核对offset提交情况：用kafka-consumer-groups.sh工具查询ksql对应查询的消费者组（组ID格式为_confluent-ksql-<ksql.service.id>query_<查询ID>），确认故障发生时offset是否确实未提交
• 确认故障模拟时机：EOS语义保证的是已提交事务的处理结果不重复，如果在事务提交完成前终止进程，事务会整体回滚，重启后重新处理属于正常逻辑，需在事务提交完成后再模拟故障验证语义

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