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的队列数比较少,那么就容易易出现消息堆积的情况。可以通过增加队列数来提高消息的处理并发度,从而减少消息堆积。
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值