如何调优Kafka

调优目标

在做调优之前,我们必须明确优化 Kafka 的目标是什么。通常来说,调优是为了满足系统 常见的非功能性需求。在众多的非功能性需求中,性能绝对是我们最关心的那一个。不同的 系统对性能有不同的诉求,比如对于数据库用户而言,性能意味着请求的响应时间,用户总 是希望查询或更新请求能够被更快地处理完并返回。

对 Kafka 而言,性能一般是指吞吐量和延时。

吞吐量,也就是 TPS,是指 Broker 端进程或 Client 端应用程序每秒能处理的字节数或消
息数,这个值自然是越大越好。
延时和我们刚才说的响应时间类似,它表示从 Producer 端发送消息到 Broker 端持久化完
成之间的时间间隔。这个指标也可以代表端到端的延时(End-to-End,E2E),也就是从
Producer 发送消息到 Consumer 成功消费该消息的总时长。和 TPS 相反,我们通常希望
延时越短越好。
总之,高吞吐量、低延时是我们调优 Kafka 集群的主要目标,一会儿我们会详细讨论如何
达成这些目标。在此之前,我想先谈一谈优化漏斗的问题

调优吞吐量

首先是调优吞吐量。很多人对吞吐量和延时之间的关系似乎有些误解。比如有这样一种提法
还挺流行的:假设 Kafka 每发送一条消息需要花费 2ms,那么延时就是 2ms。显然,吞吐
量就应该是 500 条 / 秒,因为 1 秒可以发送 1 / 0.002 = 500 条消息。因此,吞吐量和延
时的关系可以用公式来表示:TPS = 1000 / Latency(ms)。但实际上,吞吐量和延时的关
系远不是这么简单。
我们以 Kafka Producer 为例。假设它以 2ms 的延时来发送消息,如果每次只是发送一条
消息,那么 TPS 自然就是 500 条 / 秒。但如果 Producer 不是每次发送一条消息,而是在
发送前等待一段时间,然后统一发送 一批 消息,比如 Producer 每次发送前先等待 8ms,
8ms 之后,Producer 共缓存了 1000 条消息,此时总延时就累加到 10ms(即 2ms +
8ms)了,而 TPS 等于 1000 / 0.01 = 100,000 条 / 秒。由此可见,虽然延时增加了 4
倍,但 TPS 却增加了将近 200 倍。这其实也是批次化(batching)或微批次化(micro
batching)目前会很流行的原因。
在实际环境中,用户似乎总是愿意用较小的延时增加的代价,去换取 TPS 的显著提升。毕
竟,从 2ms 到 10ms 的延时增加通常是可以忍受的。事实上,Kafka Producer 就是采取
了这样的设计思想。
当然,你可能会问:发送一条消息需要 2ms,那么等待 8ms 就能累积 1000 条消息吗?答
案是可以的!Producer 累积消息时,一般仅仅是将消息发送到内存中的缓冲区,而发送消
息却需要涉及网络 I/O 传输。内存操作和 I/O 操作的时间量级是不同的,前者通常是几百 纳秒级别,而后者则是从毫秒到秒级别不等,因此,Producer 等待 8ms 积攒出的消息
数,可能远远多于同等时间内 Producer 能够发送的消息数。


推荐阅读

Spring中观察者模式的应用-CSDN博客

180Wtps超高并发、大流量生产案例 字节钱包 架构与落地方案

相关推荐
东窗西篱梦33 分钟前
Redis集群部署指南:高可用与分布式实践
数据库·redis·分布式
Acrel_Fanny34 分钟前
Acrel-1000系列分布式光伏监控系统在湖北荆门一马光彩大市场屋顶光伏发电项目中应用
分布式
xufwind40 分钟前
spark standlone 集群离线安装
大数据·分布式·spark
半新半旧2 小时前
Redis集群和 zookeeper 实现分布式锁的优势和劣势
redis·分布式·zookeeper
亲爱的非洲野猪2 小时前
Kafka “假死“现象深度解析与解决方案
分布式·kafka
CodeWithMe2 小时前
【Note】《Kafka: The Definitive Guide》第三章: Kafka 生产者深入解析:如何高效写入 Kafka 消息队列
分布式·kafka
虾条_花吹雪2 小时前
2、Connecting to Kafka
分布式·ai·kafka
Edingbrugh.南空4 小时前
Hadoop高可用集群搭建
大数据·hadoop·分布式
Bug退退退1234 小时前
RabbitMQ 高级特性之重试机制
java·分布式·spring·rabbitmq
在肯德基吃麻辣烫6 小时前
《Redis》缓存与分布式锁
redis·分布式·缓存