Kafka~消息系列问题解决：重复消费问题、消费重试机制、消息积压问题

重复消费问题

kafka 出现消息重复消费的原因：

服务端侧已经消费的数据没有成功提交 offset（根本原因）。
Kafka 侧由于服务端处理业务时间长或者网络链接等等原因让 Kafka 认为服务假死，触发了分区 rebalance。

解决方案：

消费消息服务做幂等校验，比如 Redis 的 set、MySQL 的主键等天然的幂等功能。这种方法最有效。
将 enable.auto.commit 参数设置为 false，关闭自动提交，开发者在代码中手动提交 offset。

那么这里会有个问题：什么时候提交 offset 合适？

处理完消息再提交：依旧有消息重复消费的风险，和自动提交一样。
拉取到消息即提交：会有消息丢失的风险。允许消息延时的场景，一般会采用这种方式。然后，通过定时任务扫离线数据检查。

在Kafka中，有三种常见的消息传递语义:At-least-once、At-most-once、Exactly-once。

其中At-least-once和Exactly-once是最常用的。

At-least-once消费语义

At-least-once消费语义意味着消费者至少消费一次消息，但可能会重复消费同一消息。在At-least-once语义中，当消费者从Kafka服务器读取消息时，消息的偏移量会被认己录下来。一旦消息被成功处理，消费者会将位移提交回Kafka服务器。如果消息处理失败，消费者不会提交立移。这意味着该消息将在下一次重试时再次被消费。

At-least-once语义通常用于实时数据处理或消费者不能容忍数据丢失的场景。

At-most-once消费语义

如果你可以容忍消息丢失，那这个就可以保证消息只消费一次，他的实现就是只要这个消费组消费了该条消息，就直接提交offset。

Exactly-once消费语义

Exactly-once消费语义意味着每个消息仅被消费一次，且不会被重复消费。在Exactly-once语义中，Kafka保证消息只被处理一次，同时保持消息的顺序性。为了实现Exactly-once语义，Kafka引入了一个新的概念：事务。

事务是一系列的读写操作，这些操作要么全部成功，要么全部失败。在Kafka中,，产者和消费者都可以使用事务，以保证消息的Exactly-once语义。具体来说，消费者可以使用事务来保证消息的消费和位移提交是原子的，而生产者可以使用事务来保证消息的生产和位移提交是原子的。

在Kafka0.11版本之前，实现Exactly-once语义需要一些特殊的配置和设置。但是，在Kafka0.11版本之后，Kafka提供了原生的Exactly-once支持，使得实现Exactly-ondce变得更加简单和可靠。

总之，At-least-once消费语义保证了数据的可靠性，但可能会导致数据重复。而Exactly-once消费语义则解决了重复问题，但需要更复杂的设置和配置。选择哪种消费语义取决于业务需求和数据可靠性要求。

重试机制

在 Kafka 如何保证消息不丢失这里，我们提到了 Kafka 的重试机制。由于这部分内容对于消息可靠性的优化较为重要。

消费过程在默认配置下，当消费异常会进行重试，重试多次后会跳过当前消息，继续进行后续消息的消费，不会一直卡在当前消息。因此，即使某个消息消费异常，Kafka 消费者仍然能够继续消费后续的消息，不会一直卡在当前消息，保证了业务的正常进行。

默认配置下，Kafka 消费者在默认配置下会进行最多 10 次的重试，每次重试的时间间隔为 0，即立即进行重试。如果在 10 次重试后仍然无法成功消费消息，则不再进行重试，消息将被视为消费失败。

当达到最大重试次数后，数据会直接被跳过，继续向后进行。当代码修复后，如何重新消费这些重试失败的数据呢？

死信队列（Dead Letter Queue，简称 DLQ）是消息中间件中的一种特殊队列。它主要用于处理无法被消费者正确处理的消息，通常是因为消息格式错误、处理失败、消费超时等情况导致的消息被"丢弃"或"死亡"的情况。当消息进入队列后，消费者会尝试处理它。如果处理失败，或者超过一定的重试次数仍无法被成功处理，消息可以发送到死信队列中，而不是被永久性地丢弃。在死信队列中，可以进一步分析、处理这些无法正常消费的消息，以便定位问题、修复错误，并采取适当的措施。

Kafka 本身并不直接支持死信队列（Dead Letter Queue，DLQ）。然而，可以通过一些方式来模拟实现类似死信队列的功能。可以通过自定义实现来达到类似的效果。一种常见的做法是创建一个或多个特定的主题来作为“死信主题”。当消息处理出现错误时，将这些消息发送到对应的“死信主题”中进行存储。

实现的方式大致如下：