Kafka--08---Kafka中的优化问题

Kafka--08---Kafka中的优化问题,第1张

Kafka--08---Kafka中的优化问题

提示:文章写完后,目录可以自动生成,如何生成可参考右边的帮助文档

文章目录
  • Kafka中的优化问题
    • 1.如何防⽌消息丢失
    • 2.如何防⽌重复消费
      • 怎么解决:
        • ==所谓的幂等性:多次访问的结果是⼀样的==。
      • 解决⽅案:
      • 1. 在数据库中==创建联合主键==
      • 2. **使⽤redis或zk的分布式锁(主流的⽅案)**
        • 以==业务id为锁==。保证只有⼀条记录能够创建成功
        • 支付业务系统---幂等性
    • 3.如何做到消息的顺序消费
    • 4.如何解决消息积压问题
      • 1)消息积压问题的出现
      • 2)消息积压的解决⽅案
    • 5.实现延时队列的效果
      • 1)应⽤场景
      • 2)具体⽅案


Kafka中的优化问题 1.如何防⽌消息丢失
  • ⽣产者:1)使⽤同步发送 2)把ack设成1或者all,并且设置同步的分区数>=2
  • 消费者:把⾃动提交改成⼿动提交
2.如何防⽌重复消费

在防⽌消息丢失的⽅案中,如果⽣产者发送完消息后,因为⽹络抖动,没有收到ack,但实际上broker已经收到了。

此时⽣产者会进⾏重试,于是broker就会收到多条相同的消息,⽽造成消费者的重复消费。

怎么解决:
  • ⽣产者关闭重试:会造成丢消息(不建议)
  • 消费者解决⾮幂等性消费问题:
所谓的幂等性:多次访问的结果是⼀样的

对于rest的请求(get(幂等)、post(⾮幂等)、put(幂等)、delete(幂等))

解决⽅案: 1. 在数据库中创建联合主键
  • 防止相同的主键 创建出多条记录

2. 使⽤redis或zk的分布式锁(主流的⽅案)
业务id为锁。保证只有⼀条记录能够创建成功 支付业务系统—幂等性
  1. 先查询一下redis订单是否已经插入过,用业务id为key
  2. 如果已经插入过,则不重复 *** 作;
  3. 如果没有插入,进行支插入流程,修改订单状态为‘已插入’。
3.如何做到消息的顺序消费
  • ⽣产者:保证消息按顺序消费,且消息不丢失——使⽤同步的发送,ack设置成⾮0的值。
  • 消费者:主题只能设置⼀个分区,消费组中只能有⼀个消费者


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

4.如何解决消息积压问题 1)消息积压问题的出现
  • 消息的消费者的消费速度远赶不上⽣产者的⽣产消息的速度,导致kafka中有⼤量的数据没有 被消费。
  • 随着没有被消费的数据堆积越多,消费者寻址的性能会越来越差,最后导致整个 kafka对外提供的服务的性能很差
  • 从⽽造成其他服务也访问速度变慢,造成服务雪崩。
2)消息积压的解决⽅案
  • 在这个消费者中,使⽤多线程,充分利⽤机器的性能进⾏消费消息。
  • 通过业务的架构设计,提升业务层⾯消费的性能。
  • 创建多个消费组,多个消费者,部署到其他机器上,⼀起消费,提⾼消费者的消费速度
  • 创建⼀个消费者,该消费者在kafka另建⼀个主题,配上多个分区,多个分区再配上多个
    消费者。该消费者将poll下来的消息,不进⾏消费,直接转发到新建的主题上。此时,新
    的主题的多个分区的多个消费者就开始⼀起消费了。——不常⽤
5.实现延时队列的效果 1)应⽤场景
  • 订单创建后,超过30分钟没有⽀付,则需要取消订单,这种场景可以通过延时队列来实现
  • rabbitMQ 有专门的实现,Kafka实现起来相对复杂一点
2)具体⽅案


1.kafka中创建创建相应的主题
2.消费者消费该主题的消息(轮询)
3.消费者消费消息时判断消息的创建时间和当前时间是否超过30分钟(前提是订单没⽀付)

  • 如果是:去数据库中修改订单状态为已取消
  • 如果否:记录当前消息的offset,并不再继续消费之后的消息。等待1分钟后,再次
    向kafka拉取该offset及之后的消息,继续进⾏判断,以此反复。

欢迎分享,转载请注明来源:内存溢出

原文地址: https://outofmemory.cn/zaji/5688255.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-12-17
下一篇 2022-12-17

发表评论

登录后才能评论

评论列表(0条)

保存