事务性发件箱+Kafka实现Exactly-Once Delivery的分布式锁围栏疑问

需求背景 #

我计划在系统中实现事务性发件箱模式，以数据库表作为事务性发件箱，结合Kafka保证消息的Exactly-Once Delivery；同时配置开启Exactly-Once Processing的Kafka Streams，确保客户端消息的投递与处理全链路满足Exactly-Once要求。系统架构为：Client -> API -> DB -> Kafka

基础流程的困惑 #

我理解的基于轮询发布者的基础事务性发件箱流程如下：

• 在同一数据库事务中，将收到的消息写入message表与message_outbox表，通过messageId避免客户端重复消息在API层被重复处理；
• 由独立CDC服务或API内的发布者线程轮询新消息：先通过分布式锁（如ShedLock）获取锁，再批量更新message_outbox标记为locked状态，最后拉取该批次消息；
• 使用幂等、事务性生产者将批次消息发送至Kafka，生产者会话的围栏令牌可避免同会话内重试产生重复消息。

但我无法理解该流程如何在所有场景下保证Exactly-Once Delivery：例如生产者在收到Kafka ACK前彻底崩溃（如OOM），此时消息未从发件箱删除，新实例接管后会重试发送，仅能保证At-Least-Once。即使使用Debezium等CDC服务，仍存在类似问题。

优化流程的疑问 #

经解答后，我梳理了优化流程：API事务性存储消息至message_outbox，独立进程锁批次并标记为PENDING后发送至Kafka，使用read_committed隔离级的消费者读取消息后删除对应发件箱条目。但我困惑于崩溃后如何确定恢复时的起始偏移，目前想到两个方案：

1. 持续运行消费者组自动跟踪偏移，删除发件箱消息时提交偏移，但需处理分区重分配时的僵尸生产者围栏；
2. 处理Kafka内部的__transaction_state主题，但该方式依赖内部API，易受Kafka版本更新影响。

请问方案1是否存在问题？是否有其他可行方案？

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