为什么存在重复消费？
生产者
- 消息重复发送：
- 如果生产者在发送消息后未能收到确认（例如，在网络不稳定的情况下），生产者可能会重发消息。这种情况虽然不会直接导致消费者的重复消费，但如果消费者未能正确处理这种情况，就可能造成重复消费。
- 消息重复提交：
- 如果生产者使用事务性发送（transactional send），但在提交事务时出现问题，可能会导致消息重复提交。这种情况同样需要消费者能够处理重复消息。
- 解决办法：确保生产者正确地使用事务性发送，并在事务提交失败时进行适当的回滚操作。
消费者
- 自动提交偏移量：
- 如果启用了自动提交偏移量 (
enable.auto.commit=true)，消费者在处理消息的过程中如果突然断开连接（例如，网络中断或消费者崩溃），那么在消息尚未完全处理完的情况下，偏移量可能已被提交。当消费者重新连接后，这些消息可能被认为已经消费过，从而导致重复消费。
- 解决办法：关闭自动提交偏移量 (
enable.auto.commit=false)，并手动控制偏移量的提交，确保消息被正确处理后再提交偏移量。
- 手动提交偏移量时机不当：
- 如果手动提交偏移量的时机不当（例如，在消息处理之前或消息处理过程中提交偏移量），可能会导致消息被重复消费。
- 解决办法：确保在消息被完全处理并且确认无误之后再提交偏移量。
- 消费者组再平衡：
- 当消费者组发生再平衡（例如，新的消费者加入或现有消费者退出）时，分区会被重新分配。如果消息在再平衡过程中未能被确认，可能会导致重复消费。
- 解决办法：在再平衡过程中，确保消费者能够正确处理分区重新分配的情况，并且在消息被处理完毕后再提交偏移量。
- 消费者异常退出：
- 如果消费者在处理消息过程中因某种原因（如网络问题、硬件故障等）突然退出，而消息尚未提交偏移量，那么这条消息可能会被重新分配给其他消费者。
- 解决办法：确保消费者在退出前能够妥善处理消息，并提交偏移量。
- 幂等性问题：
- 如果消息处理逻辑不具备幂等性，即多次处理同一消息会产生不同的结果，那么重复消费可能会导致数据不一致。
- 解决办法：确保消息处理逻辑具备幂等性，即多次处理同一消息应产生相同的结果。可以通过在处理消息前检查状态来实现幂等性，例如查询数据库中的状态或使用唯一标识符来避免重复处理。
解决办法
增加幂等性检查（消费端）
- 使用唯一键（Unique Key）：对于某些业务场景，可以为每条消息添加一个唯一的键，这个键可以是一个全局唯一的 ID 或者是基于业务逻辑生成的唯一标识符。在处理消息之前，先检查该唯一键是否已经处理过。
消息去重队列（消费端）
- 使用外部系统去重：在消费者处理消息之前，可以先将消息发送到一个专门的去重队列中。去重队列会检查该消息是否已经处理过，并且只将未处理过的消息传递给实际的业务逻辑处理。
消息版本控制（消费端）
- 版本化消息：为消息添加版本号，当消费者重启或升级时，可以忽略旧版本的消息，仅处理新版本的消息。
数据一致性检查（业务端）
- 定期检查数据一致性：在业务逻辑中加入定期的数据一致性检查，确保数据状态与预期相符。
事务性处理（业务端）
- 使用事务性消息：对于需要强一致性的业务场景，可以使用 Kafka 的事务性消息功能，确保消息要么全部被处理，要么全部不被处理。