kafka调优参考建议 —— 筑梦之路

这里主要是从不同使用场景来调优,仅供参考。

吞吐量优先

吞吐量优先使用场景如采集日志。

1. broker配置调优

**num.partitions:**分区个数,设置为与消费者的线程数基本相等

2. producer配置调优

  • batch.size

    批量提交消息的字节数,发送消息累计大小达到该值时才会发送(或者达到linger.ms),默认16k,如果 batch 设置太小,会导致频繁网络请求,吞吐量下降;如果 batch 太大,会导致一条消息需要等待很久才能被发送出去,增加网络延时;建议设置为1M。

  • linger.ms

    发送间隔时间,默认是 0,意思就是消息必须立即被发送。如果 linger.ms 设置的太小,会导致频繁网络请求,吞吐量下降;如果 linger.ms 太长,会导致一条消息需要等待很久才能被发送出去,增加网络延时;建议设置为100ms以上。

  • compression.type

    压缩类型,默认是 none,不压缩,但是也可以使用 lz4 压缩,效率还是不错的,压缩之后可以减小数据量,提升吞吐量,但是会加大 producer 端的 CPU 开销。

  • acks

    应答机制,默认是all(0.8.x之前,默认为1),即等待所有的副本收到消息后再返回成功,可以设置成1,即leader副本确认接收到消息后,生产者会收到返回成功的信息。但如果恰好此时leader失效,该条消息就会丢失。

  • buffer.memory

    内存缓冲区大小,默认32M,当消息写入过快或者写入量过大时,Sender 线程来不及处理,造成缓存区堆积,此时会阻塞用户线程,禁止往 kafka 写入消息,一般需要根据业务场景估算一个 buffer_memory 的合理值,建议64M以上。

3. consumer配置调优

  • fetch.min.bytes

    从broker获取消息的最小字节数,只有大于这个值时,consumer才会拉取消息,默认是1,建议设置为1048576(1M)。

  • fetch.max.wait.ms

    当fetch.min.bytes不满足时,从broker获取消息的最大等待时间,默认是500,建议设置为1000

低延时优先

使用场景有实时数据传输,比如弹幕

1. broker配置调优

  • num.partitions

    分区个数,设置为与消费者的线程数基本相等。

  • num.io.threads

    默认是8。负责写磁盘的线程数。整个参数值要占总核数的50%。

  • num.replica.fetchers

    默认是1。副本拉取线程数,这个参数占总核数的50%的1/3。

  • num.network.threads

    默认是3。数据传输线程数,这个参数占总核数的50%的2/3

2. producer配置调优​​​​​

  • linger.ms

    设置为0,即有消息就发送。

  • compression.type

    设置为nonenone。

  • acks

    设置为0,异步发送,无需等待任何broker确认

3. consumer配置调优

  • fetch.min.bytes

    设置为1,一有消息就消费。

  • 线程数

    消费者的并发线程数能满足实时消费的要求,避免积压

可靠性优先

将kafka作为核心数据源,不允许kafka出现数据丢失情况的业务架构。

1. broker配置调优

  • default.replication.factor

    至少设置为3,2/3机器挂掉够,依然不影响数据的可靠性。

  • min.insync.replicas

    当生产者的ack设置为all时,必须满足该数量的副本同步成功后才能继续写入。当default.replication.factor设置为3时,该值建议设置为2。

  • unclean.leader.election.enable

    不洁leader选举,默认true,建议设置为false,即不允许不在ISR列表中的broker参加leader的选举,否则会导致已经提交但是还未复制的消息的丢失

2. producer配置调优

  • acks

    设置为all,等待ISR中的所有副本收到数据后再返回成功。

  • retries

    重试次数,建议>=3

3. consumer配置调优

enable.auto.commit: 是否开启自动提交,默认true,在设置为true时与auto.commit.interval.ms(自动提交时间间隔)配合使用,有点是简单,省去了偏移量提交逻辑,缺点是会存在重复消费和消息丢失的情况,在数据可靠性优先的场景下需要设置为false,当事务提交后再提交位移。

可用性优先

将kafka作为核心依赖,不允许kafka出现长时间不可用情况的业务架构(对数据可靠性要求不高,不阻塞读写就行)

1. broker配置调优

  • unclean.leader.election.enable

    设置为true,允许不洁的副本当选leader。

  • min.insync.replicas

    设置为1。

  • num.recovery.threads.per.data.dir

    启动时用于日志恢复和关闭时用于刷新的每个数据目录的线程数,默认为1,建议设置为1,减少重启时加载日志的时间。

2. producer配置调优

**acks :**设置为0,不等待任何确认,直接返回成功。

相关推荐
jstart千语18 小时前
【Redisson】锁可重入原理
redis·分布式·redisson
暗离子跃迁20 小时前
达梦数据库单机部署dmhs同步复制(dm8->kafka)
linux·运维·数据库·分布式·学习·kafka·达梦数据库
代码的知行者1 天前
分布式数据库中间件-Sharding-JDBC
数据库·分布式·中间件
啾啾Fun1 天前
Java面试题:分布式ID时钟回拨怎么处理?序列号耗尽了怎么办?
java·分布式·分布式id·八股
计算机毕设定制辅导-无忧学长1 天前
Kafka 可靠性保障:消息确认与事务机制(一)
分布式·kafka·linq
掘金-我是哪吒1 天前
分布式微服务系统架构第145集:Jeskson文档-微服务分布式系统架构
分布式·微服务·云原生·架构·系统架构
G探险者1 天前
为什么 Zookeeper 越扩越慢,而 Nacos 却越扩越快?
分布式·后端
Pitayafruit1 天前
跟着大厂学架构01:如何利用开源方案,复刻B站那套“永不崩溃”的评论系统?
spring boot·分布式·后端
bxlj_jcj2 天前
Kafka环境搭建全攻略:从Docker到Java实战
java·docker·kafka
苏格拉没有底_coder2 天前
引入 Kafka 消息队列解耦热点操作
分布式·kafka