Kafka Exactly-once语义与消费者去重方案对比：孰优孰劣？

没有绝对的“最优”方案，两者各有适用场景，下面分别拆解它们的优缺点，再给出选择建议：

方案一：启用Kafka Exactly-once语义 #

优点 #

• 原生端到端保障：Kafka的Exactly-once覆盖生产、传输、消费全链路，从生产者写入到消费者处理的整个流程都能确保仅一次执行，不需要自己开发复杂的跨环节去重逻辑，减少代码维护成本。
• 分布式场景可靠性高：面对多消费者实例、跨节点处理的复杂场景，原生语义的一致性逻辑经过官方验证，比自行开发的去重逻辑更不容易出现遗漏或误判。
• 减少业务侧负担：业务代码不需要关心重复消息的处理，只需要专注于核心业务逻辑，降低了业务开发的复杂度。

缺点 #

• 性能损耗明显：Exactly-once依赖生产者幂等性、事务机制，以及消费者的read_committed隔离级别，会增加消息处理的延迟，降低系统吞吐量，在高并发场景下影响尤为突出。
• 配置与兼容性门槛高：需要Kafka集群版本在0.11.0.0及以上，生产者要开启幂等性和事务，消费者要配置对应的隔离级别，同时上下游系统（比如消费者写入的数据库）也需要支持事务才能实现完整的端到端语义。
• 适用场景受限：如果消费者需要和不支持事务的外部系统（比如某些第三方API）交互，Kafka的Exactly-once无法覆盖外部系统的处理环节，仍可能出现重复执行的问题。

方案二：消费者端实现去重逻辑 #

优点 #

• 性能影响极小：不需要依赖Kafka的事务机制，生产者和消费者的吞吐量、延迟基本保持原有水平，适合对性能要求高的高吞吐低延迟场景。
• 配置灵活、兼容性强：不需要修改Kafka集群或生产者的任何配置，支持所有版本的Kafka集群，也能适配各种外部系统，只要消费者侧能实现去重判断即可。
• 成本低：不需要额外的集群资源开销，只需要在消费者侧维护一个去重存储（比如Redis、本地缓存、业务数据库）即可。

缺点 #

• 自行开发维护成本高：需要自己设计去重逻辑，包括选择合适的去重键（比如消息的唯一ID）、处理去重存储的一致性、设置过期策略（避免存储无限膨胀）、解决分布式场景下的并发去重问题（比如多个消费者实例同时处理同一条消息），代码复杂度高，容易出现漏洞。
• 仅覆盖消费环节：只能解决消费阶段的重复问题，无法避免生产者重试、Kafka集群异常导致的重复写入问题，属于被动处理重复。
• 去重存储可靠性依赖自身：如果去重存储（比如Redis）出现故障，可能导致重复消费或丢失去重记录，需要额外做高可用保障，增加了运维成本。

选择建议 #

• 若业务对一致性要求极高，能接受一定的性能损耗，且Kafka版本、上下游系统都支持事务，优先选Kafka Exactly-once语义。
• 若业务对性能要求高，Kafka版本较低，或需要对接不支持事务的外部系统，优先选消费者端去重，但务必做好去重逻辑的健壮性设计（比如确保去重键全局唯一、去重存储高可用、处理并发冲突）。

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