如何基于Kafka事务构建实现Exactly-Once处理的单例有状态服务？

我了解如何基于Kafka的消费者-生产者事务API构建无状态微服务，但不清楚如何将其扩展到有状态服务。为简化问题，限定服务为单例类型（同一时间仅能运行一个服务进程），排除Kafka消费者组相关场景，聚焦核心问题。

示例问题 #

从input主题消费事件，处理后发送到output主题。输入主题包含A、B两类事件，每个事件带有时间戳和数值。示例A类型事件如下：

{
    "type": "A",
    "timestamp": "2024-02-09 21:00:00",
    "value": 1
}

目标是将同一时间戳的A、B事件配对，计算数值之和。A、B事件到达顺序随机，部分时间戳可能缺少事件，且时间戳存在少量乱序（最多几分钟）。这要求服务在内存中维护状态，为避免状态无限增长，设定超过5分钟的事件过期。

这带来了提交逻辑设计的复杂性，我提出两个初步方案：

方案1 #

• 将状态存储在磁盘或MongoDB等外部存储
• 跨系统交互时难以保证Exactly-Once处理，不确定是否具备普适性
• 更建议借助Kafka解决问题

方案2 #

• 新增state主题存储服务状态，典型消费-生产流程如下：
  • 启动事务
  • 从input主题消费事件
  • 更新内存中的内部状态
  • 向output主题生产事件
  • 向state主题生产当前内存中剩余状态的副本
  • 提交并结束事务

该方案的问题是可能向state主题发送大量数据，若传输大量重复数据会导致服务变慢。可通过批量处理优化（如一次处理100个事件），但会增加输入到输出的延迟；此时事务覆盖100个事件，state主题的数据量仅为单事件处理时的1%。

该架构仍存在问题：启动逻辑需读取state主题直至获取最新状态，本质是定位到主题末尾的seek操作，不确定能否稳定实现（可能需通过消息偏移量查询最大偏移量再读取），这种设计不佳且不符合Kafka的预期使用方式。

此外，加入state主题后，提交逻辑的实现方式尚不明确，或许可在向该主题生产新状态后立即提交；或者构建"跟随消费者"架构，为state主题配置生产者和消费者，仅用于读取已生产事件并执行提交操作，但这会使架构变得混乱复杂，易出问题。

总结 #

综上，我不确定是否能基于Kafka和事务API构建支持Exactly-Once处理的单例有状态服务。我认为方案2可行，但非常不符合Kafka的常规使用风格——典型的Kafka服务是读取一个或多个主题、生产数据然后提交事务。

加入state主题后会出现诸多问题：

• 持续发送使旧数据失效的新数据，我们仅关心主题中的最新数据，但Kafka主题本身是数据流形式，导致数据冗余
• 无法明确如何高效提交以避免因获取过时状态导致启动缓慢

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