kafka常见问题处理

1. 如何防⽌消息丢失

在生产者层面,我们有个ack参数确认机制

设置成-1,也就是副本全部同步了leader才发送ack,这样确保leader和副本挂掉只剩一个还能

保证消息不丢失

消费者:

把⾃动提交改成⼿动提交

2. 如何防⽌重复消费

在防⽌消息丢失的⽅案中,如果⽣产者发送完消息后,因为⽹络抖动,没有收到ack,但实际上broker已经收到了。此时⽣产者会进⾏重试,于是broker就会收到多条相同的消息,⽽造成消费者的重复消费。

怎么解决:

⽣产者关闭重试:会造成丢消息(不建议)
消费者解决⾮幂等性消费问题:
所谓的幂等性:多次访问的结果是⼀样的。对于rest的请求(get(幂等)、post(⾮幂
等)、put(幂等)、delete(幂等))
解决⽅案:
1.在数据库中创建联合主键,防⽌相同的主键 创建出多条记录

假设我们有一个电商平台,其中有一个订单系统,需要处理用户的订单。在这个业务场景下,我们可以使用联合主键来避免重复消费。

假设订单系统中的订单数据存储在数据库表中,表结构包含以下字段:订单ID、用户ID、商品ID、订单状态等。

订单系统通过消息队列将订单数据发送给其他系统进行处理,比如库存系统和物流系统。当订单系统发送一个订单消息给库存系统时,可能由于网络抖动或其他原因导致消息发送失败,此时订单系统会进行重试。

然而,由于某些原因(如网络延迟、重试机制设计等),重试过程中可能会导致重复发送相同的订单消息到库存系统。如果没有相应的方式来防止重复消费,库存系统可能会处理同一订单多次,导致库存错误或其他问题。

为了解决这个问题,我们可以在订单数据表中创建一个联合主键,由订单ID、用户ID和商品ID组成。这样,当订单系统接收到一个新订单时,首先检查数据库中是否已存在具有相同联合主键的记录。

如果存在重复记录,订单系统可以判断该订单消息已经被处理过,并选择跳过重复消息的处理。如果不存在重复记录,则将该订单数据插入数据库,并发送消息给库存系统进行处理。

通过使用联合主键,我们可以确保在订单系统中防止重复消费的问题。即使在订单系统进行重试时,库存系统只会处理首次收到的订单消息,避免了重复消费产生的问题

2.使⽤分布式锁,以业务id为锁。保证只有⼀条记录能够创建成功

假设我们有一个在线活动报名系统,用户可以通过该系统报名参加各种活动。在这个业务场景中,我们可以使用分布式锁来保证同一个用户只能成功报名一次活动。

假设活动报名系统中的报名记录存储在数据库表中,表结构包含以下字段:报名ID、用户ID、活动ID、报名状态等。

当用户尝试报名一个活动时,系统需要进行以下操作:

  1. 检查该用户是否已经报名了该活动。
  2. 如果用户已经报名了该活动,则返回相应的提示,阻止用户重复报名。
  3. 如果用户未报名该活动,则将报名信息插入数据库,并完成报名流程。

在这个场景下,我们可以使用分布式锁来保证同一个用户只能成功报名一次活动。以用户ID作为锁的key,当用户尝试报名活动时,先尝试获取该用户的锁。

如果获取到了锁,表示该用户尚未报名该活动,可以继续执行报名操作,并将用户ID作为锁的值存储在分布式锁中。

如果未能获取到锁,表示该用户已经报名了该活动,可以给用户返回相应的提示,阻止用户重复报名。

3. 如何做到消息的顺序消费

  • ⽣产者:保证消息按顺序消费,且消息不丢失——使⽤同步的发送,ack设置成⾮0的值。
  • 消费者:主题只能设置⼀个分区,消费组中只能有⼀个消费者

kafka的顺序消费使⽤场景不多,因为牺牲掉了性能,但是⽐如rocketmq在这⼀块有专⻔的功能已设计好。

 

4. 如何解决消息积压问题


4.1 消息积压问题的出现


消息的消费者的消费速度远赶不上⽣产者的⽣产消息的速度,导致kafka中有⼤量的数据没有被消费。随着没有被消费的数据堆积越多,消费者寻址的性能会越来越差,最后导致整个kafka对外提供的服务的性能很差,从⽽造成其他服务也访问速度变慢,造成服务雪崩。

4.2 消息积压的解决⽅案


在这个消费者中,使⽤多线程,充分利⽤机器的性能进⾏消费消息。
通过业务的架构设计,提升业务层⾯消费的性能。
创建多个消费组,多个消费者,部署到其他机器上,⼀起消费,提⾼消费者的消费速度
创建⼀个消费者,该消费者在kafka另建⼀个主题,配上多个分区,多个分区再配上多个
消费者。该消费者将poll下来的消息,不进⾏消费,直接转发到新建的主题上。此时,新
的主题的多个分区的多个消费者就开始⼀起消费了。——不常⽤

5. 实现延时队列的效果

5.1 应用场景

订单创建后,超过30分钟没有⽀付,则需要取消订单,这种场景可以通过延时队列来实现

5.2 具体方案

 kafka中创建创建相应的主题
消费者消费该主题的消息(轮询)
消费者消费消息时判断消息的创建时间和当前时间是否超过30分钟(前提是订单没⽀付)
如果是:去数据库中修改订单状态为已取消。
如果否:记录当前消息的offset,并不再继续消费之后的消息。等待1分钟后,再次向kafka拉取该offset及之后的消息,继续进⾏判断,以此反复。
 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

乖的小肥羊

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值