Kafka延时分析

1、背景

针对Kafka进行测试的结果中出现的ack为0消费时延比ack为1、-1情况下反而要长，异步生产消费时延较大等疑点，都非常有必要一番配置和代码的梳理。

2、核心配置

以下所有默认参数是针对kafka 0.9，且主要针对时延这块涉及的核心参数做分析：

producer端：

buffer.memory：默认32m，每个producer实例可用来存储消息的最大内存空间（在实例中作为一个内存池存在）。
retries：kafka默认0次，mafka默认3次，异步发送失败重试次数。
batch.size: 默认16k，可以把一个batch.size大小的空间认为是一个槽。
linger.ms：默认0ms，在异步IO线程被触发后（任何一个topic，partition满都可以触发），如果其他的

broker端：

replica.fetch.max.bytes：默认1m，follower每次拉消息过程中，针对每个

consumer端：

fetch.message.max.bytes：默认1m，consumer每次拉消息过程中，针对每个

3、术语说明

ISR：同步副本列表
kafka0.8 通过2个因素来控制ISR：1、最近追上的时间和当前时间的差和配置的阈值的比较。 2、replica partition和leader partition的消息条数的差和配置的阈值的比较。
kafka0.9 抛弃了0.8中消息条数的控制，只通过最近追上的时间和当前时间的差和配置的阈值的比较来控制ISR的变化。
LEO：每个replica partition存储的最后一条消息的offset。
HW：partition的高水位，取这个partition对应的ISR中最小的LEO作为HW，消费者最多只能消费到HW所在的位置。

4、延时分析

这里不针对每种情况进行逐一分析，仅以一个非常具有代表性的case（异步发送，replica为3，ack为-1）来进行分析。

4.1 producer

针对每个producer实例：
创建一个大小为buffer.memory的内存池，所有存放发送消息的缓存都是从这个内存池捞出来的空间。
创建一个batches的Map，key为

4.2 broker

ack设置为0的情况下，类似于客户端进行了一次one way的rpc操作，不需要等待broker端的response。

针对ack为1和-1的情况，下面做些分析：
broker端接收到producer端发送过来的消息，先往leader partition上顺序写入这条消息，更新LEO和HW。
针对ack为1的情况，直接response给Producer端。
针对ack为-1的情况，创建一个延迟操作（DelayedProduce），延迟操作有个超时时间timeout.ms。

参考和引用自涂扬wiki