禁用Exactly-once时，Kafka Streams状态处理器是否保证至少一次处理？

由于基础设施限制，我们运行的Kafka Streams应用未启用Exactly-once语义（EOS）。在使用带变更日志状态存储的transformer/processor API实现自定义去重逻辑时，对故障场景下的行为存在疑问。

我们采用的拓扑如下：

[topic] -> [flatTransformValues + state store] -> [...(downstream)]

该转换器的逻辑是：将传入记录与状态存储中的值对比，仅当值发生变化时才转发记录并更新状态存储。例如输入消息序列[A:1], [A:1], [A:2]，预期下游仅收到[A:1], [A:2]。

疑问点：故障发生时，是否会出现[A:2]已存入状态存储的变更日志，但下游未收到该消息的情况？如果出现这种情况，重试读取[A:2]时会被转换器丢弃，导致该记录永久丢失。如果不会出现这种情况，请说明阻止该情况的机制——我推测可能是Kafka Streams在下游生产成功后，才向变更日志主题生产并提交偏移量？

你担心的**[A:2]写入变更日志但下游未收到的情况，在未启用EOS的Kafka Streams中是可能发生**的，但Kafka Streams的默认机制会降低风险，却无法完全避免。

核心逻辑说明 #

Kafka Streams的处理与提交流程是这样的：

• 转换器处理[A:2]时，会先更新内存中的状态存储，再调用forward()向下游发送消息。
• 之后Kafka Streams会异步将内存中的状态更新同步到变更日志主题，同时在处理完一批记录后，异步提交源主题的偏移量。
• 关键在于：状态更新写入、下游消息发送、偏移量提交这三个操作并非原子性的（未启用EOS的前提下）。

可能触发丢失的场景 #

比如：
状态更新已经同步到变更日志，但下游消息发送失败（例如下游主题不可用），此时应用崩溃重启后，重新读取[A:2]时，会因为状态存储里已有该值而被转换器丢弃，最终导致下游永远收不到这条记录——这就是你担心的永久丢失场景。

关于你的推测 #

Kafka Streams不会等待下游生产成功后才写入变更日志或提交偏移量。默认情况下，它是基于时间或记录数的批量提交逻辑，操作之间没有强依赖的顺序保证。

缓解方案（无法启用EOS时） #

• 调小commit.interval.ms参数，缩小批量提交的间隔，降低故障时的重复处理范围。
• 在transformer中手动控制逻辑：确保下游发送成功后再更新状态存储（但会同步处理降低吞吐量，需自行实现重试逻辑）。
• 给下游消息添加唯一标识，让下游系统自己做幂等处理，即使重复接收也不会影响业务逻辑。

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