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

重复消费问题

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

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

解决方案：

1. 消费消息服务做幂等校验，比如 Redis 的 set、MySQL 的主键等天然的幂等功能。这种方法最有效。
2. 将 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）。然而，可以通过一些方式来模拟实现类似死信队列的功能。可以通过自定义实现来达到类似的效果。一种常见的做法是创建一个或多个特定的主题来作为“死信主题”。当消息处理出现错误时，将这些消息发送到对应的“死信主题”中进行存储。

实现的方式大致如下：

• 在消息处理的代码中，添加 try-catch 块来捕获预期或意外的异常。如果没有发生错误，则正常处理消息。如果发生异常，可以将消息发送到专用的“死信主题”。同时，为了便于后续的分析和故障排查，最好在发送到“死信主题”的消息中添加一些额外的信息，例如错误原因等。

另外，一些与 Kafka 相关的框架或组件可能提供了对死信队列的开箱即用支持。例如，Kafka Connect 中可以通过配置来实现一定程度上的死信队列功能。

虽然 Kafka 没有内置的死信队列概念，但通过上述自定义或借助相关框架的方式，仍然可以满足对死信队列的需求，实现对无法正常处理消息的特殊处理和管理。

需注意，具体的实现方式可能会因项目的具体需求和技术架构而有所不同。在实际应用中，需要根据情况选择最适合的方法来模拟死信队列的功能。同时，要确保对“死信主题”中的消息进行适当的监控和处理，以避免这些消息被无限期地忽略或积累。

消息积压问题

消息堆积，一般都是因为消费者在消费过程中，由于消费耗时过长或消费并发度较小等原因，导致消费能力不足，出现消息堆积的问题。当线上出现消息堆积的问题时,一般有以下几种方式来解决:

1. 增加消费者数量：消息堆积了，消费不过来了，那就把消费者的数量增加一下，让更多的实例来消费这些消息。
2. 提升消费者消费速度：消费者消费的慢可能是消息堆积的主要原因，想办法提升消费速度，比如引入线程池、本地消息存储后即返回成功后续再慢慢消费等。
3. 降低生产者的生产速度：如果生产者可控的话，可以让生产者生成我消息的速度慢一点。
4. 清理过期消息：有一些过期消息、或者一直无法成功的消息，在业务做评估之后，如果无影响或者影响不大,其实是可以清理的。
5. 增加Topic队列数：如果一个Topic的队列数比较少，那么就容易易出现消息堆积的情况。可以通过增加队列数来提高消息的处理并发度，从而减少消息堆积。