文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

Kafka如何选择合适的分区数,你选对了吗

2024-12-11 17:40

关注

本文转载自微信公众号「搬运工来架构」,作者cocodroid 。转载本文请联系搬运工来架构公众号。

我们经常会面临这样的问题,在确定某个topic下应该设置多少分区数,有时并不知道应该如何设置,如何评估等。或者别人问你当前kafka集群中,具体的业务topic中分区数是多少,是如何知道需要多少分区或怎么选择比较适合的分区数。

1.结合业务场景和非业务条件

那么我们应该如何选择合适的分区数呢?

具体的业务具体分析。

但是前期我们可以根据这些条件:实际业务场景(消息总量,消息生产或消费频率,要求的吞吐量等)、软件条件、硬件条件、负载情况等,进行大致的评估我们可以设置topic多少分区数。

2.使用压测工具,得出最佳分区数

kafka官方也提供了脚本方便我们针对我们的kafka集群做测试,我们可以测试当前提供的硬件条件进行压测,得出当前机器环境到底能支持多少分区数,从而达到尽量最优的方案。

生产者性能测试脚本:kafka-producer-perf-test.sh

消费者性能测试脚本:kafka-consumer-perf-test.sh

设置好topic的某个分区数,之后我们可以选择不同的参数:比如消息发送总量、单条消息大小、吞吐量、acks、消费线程数等等,这样压测之后就能得出一份测试报告,报告包含的数据有:50%/90%/95%/99%的消息处理耗时、平均处理耗时、每秒消息发送吞吐量、每秒拉取的消息的字节大小/消息数量、消费总数、再平衡时间、按消息计数/消息大小计算的吞吐量等等。

合适的增加分区数是可以提高吞吐量,但超过一定的阈值之后,吞吐量也会随之下降。如果生产上对吞吐量有一定的要求,可以在生产机器硬件条件下进行压测,得出适合你的最优分区数。

3.吞吐量越高并不会一直与分区数有关

对kafka生产者而言,数据写入每个分区是可以并行进行的。对kafka消费者而言,每个分区只能给一个消费者线程消费,所以消费组的消费并行度依赖于分区数。这样看来好像分区数越多,理论上吞吐量应该越高。

但是,事实真的是这样吗?

消息中间件kafka的吞吐量并不只是跟分区有关。

消息写入(生产)的吞吐量与这些有关:消息大小、消息压缩方式、消息发送方式(同步或异步)、消息确认类型acks、副本因子等。

同样,消息消费的吞吐量与业务逻辑消费速度等有关。

4.分区数与操作系统有关

分区数也不能无限制的增加,因为其占用了文件描述符,进程可支配的文件描述符是有限的。

一般如果要设置比较大的分区数,要特别留意是否超过系统的最的大描述符文件。虽然可以通过改系统配置,但是应尽量避免这种,毕竟文件句柄也是有开销的。

5.注意消息写入分区策略

我们知道消费写入哪个分区,默认或者有些会根据Key计算其应写入哪个分区,这个时候就要考虑与Key较强关联的应用是否会影响你的使用场景。

比如有些应用场景可能只是要求某个分区内消息有序,如果一旦调整分区数,就有可能影响这种使用场景。

所以我们一般会尽量配置较好的分区数,尽量满足未来2年内目标的吞吐量。

如果与Key关联较弱的应用,我们可以在未来根据实际情况进行增加分区数。

6.分区数会影响系统可用性

Kafka通过多副本机制实现集群高可用和高可靠,每个分区至少会有一个或多个副本,每个副本会存在于不同的Broker节点,并且只有leader副本对外提供服务。

kafka集群内部所有副本都采用了自动化的方式进行管理,所有副本的数据都能保持一定程度上的同步。当Broker发生故障,leader副本所在的Broker节点上的所有分区将处于暂不可用状态。

此时集群内follower副本就会重新进行选举出leader副本,整个过程由kafka控制器负责,并且集群上的分区会存在暂时不可用,并且如果分区数过多,这个不可用的时间窗口就会更大。

7.分区数越多也会增加耗时

分区数越多,kafka在正常启动和关闭的耗时也会变得越长。

与此同时,主题分区数也会在日志清理时增加耗时,也会在删除时耗费更多的时间。在旧版本上是比较明显,在新版本已经得到了改善。

8.分区数理论参考设置值

一般情况下,分区数可以配置为Broker节点数的整数倍,比如:Broker节点是3,那么可以设置分区数为3、6、9。

但是在broker节点数庞大的情况下,比如大几十、上百、上千则不合适,一般这种也是比较极少的吧,除非有BAT的量级。如果需要可以在选定分区数时可以进一步考虑引入机架等参考因素。

9.实际情况具体分析,切勿盲目

最后,当你后期增加分区数时,要注意是否有必要或合理。笔者曾见过这种场景:将日志消费后写入es,但是存在消息堆积严重,于是将分区数从6个增加到12个,此时对堆积情况并没有很好得到改善,甚至出现更差(比如同一日志文件日志数据出现不连续,即有序),最后只能删掉主题,重新设置原来的分区数。

因为系统的主要瓶颈在于es的写入能力,造成消费速度慢,从而引起海量日志消息的堆积。

所以分析出当前的主要问题(瓶颈等)很重要,切记不能随意或盲目设置分区数。

参考书籍:《深入理解kafka》

 

来源:搬运工来架构内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯