调优目标
在做调优之前，我们必须明确优化 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 能够发送的消息数。
