kafka在高并发场景下的解决方案

案例描述

在我们现在开发的项目中,经常会用到kafka消息中间件。一般情况下,单线程(单分区)的配置已经可以满足需求,但是在某些大数据和数据并发量要求较高的应用场景下经常会遇到消息来不及处理,出现消息积压的情况。因此,该文章主要针对这种应用场景提供了一个多线程消费的解决方案

案例分析

自己在平时使用kafka消息中间件的时候开始也并没有分区的概念,都是像传统的MQ消息中间件一样,直接从TOPIC里消费消息就行了。但是在有次项目现场发现有时候TOPIC里的消息往往会积压一部分无法消费。后来经过网上查阅资料和阅读kafka官方文档,了解到可以使用kafka提供的多分区能力来解决这个问题。
官网上关于kafka的分区概念介绍很多,我这里总结一下就是:

kafka的分区,相当于把一个TOPIC再细分成了多个通道,一个消费者应用可以从一个通道或者多个通道中获取数据。例如:

  • 有4个分区,1个消费者:这一个消费者需要负责消费四个分区的数据
  • 有4个分区,2个消费者:每个消费者负责两个分区
  • 有4个分区,3个消费者:消费者1负责1个分区,消费者2负责1个分区,消费者3负责2个分区
  • 有4个分区,4个消费者:一人一个
  • 有4个分区,5个及以上消费者:4个消费者一人一个,剩下的消费者空闲不工作
    所以,建议部署的时候尽量做到一个消费者对应一个分区。
    具体的实现方案如下:
  1. 生产者随机分区提交数据
    这也是一个比较关键步骤,只有随机提交到不同的分区,才能实现多分区消费;可以自定义自己的分区策略,如下:
   public int partition(String topic, Object key, byte[] keyBytes, Object var, byte[] valueBytes
  • 0
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值