发布日期: 2018年11月16日
作者: 伊藤雅博，日立制造公司

首先

在此帖中，我们将介绍我们在2017年企业级开源会议上发表的“追寻！成为Kafka大师～如何发挥Apache Kafka的最佳性能～”中所进行的验证调查的内容（共计8次）。本帖内容基于Kafka 0.11.0于2017年6月发布的版本。

本次是最终一集，将介绍系统整体的延迟。之前我们一直关注数据处理的吞吐量并进行优化调整。一般来说，吞吐量的增加会导致延迟的增加，但在之前的调优中并未考虑延迟。因此，本次将介绍延迟的测量结果。

1. Apache Kafka的概述和架构
2. Apache Kafka的生产者/代理/消费者的工作原理和设置列表
3. Apache Kafka推荐的系统配置和性能估计方法
4. Apache Kafka性能验证（1）：验证内容和验证环境
5. Apache Kafka性能验证（2）：生产者调优
6. Apache Kafka性能验证（3）：代理调优结果
7. Apache Kafka性能验证（4）：生产者重新调优和消费者的调优结果

整个系统的延迟

系统整体延迟是指从生产者的发送API添加记录的时刻到消费者的轮询API获取记录的时间。该延迟是以下5个处理时间的总和。

在进行上述各个处理的延迟测量时，我们展示了在进行前一次调优的情况下得出的结果。这些延迟数据与我们之前测量的吞吐量一样，都是通过收集Kafka在JMX中公开的指标得出的。

① API发送的阻塞时间

若用户线程通过Send API添加记录的吞吐量高于生产者的请求发送吞吐量，则生产者的缓冲区将会在某个时刻被填满。当生产者的缓冲区被填满时，用户线程会在Send API中被阻塞，直到缓冲区有空闲位置。

以下是本次檢測使用的40個Producer的每個Producer的空閒緩衝區大小變化情況。從測量開始後，空閒緩衝區大小不斷減少，大約經過2分鐘時，緩衝區的可用容量幾乎為0。因此，可以推斷從經過約2分鐘後，Send API已經發生了阻塞。

以下是Producer每秒请求发送数量的变化情况。在开始进行测量后的大约10秒后，可以发现一个Producer每秒发送请求的数量大约为3。

在本次验证中，我们没有测量Send API的阻塞时间，但是当请求被发送后，由于缓冲区会被清空，因此可以推测阻塞时间约为1秒÷3个请求≒333毫秒左右。

② 制片人的缓冲时间

通过Send API添加到Record Batch中的Record，在网络线程发送请求之前，会持续留在Producer的缓冲区中。以下展示了Record缓冲时间的变化。从测量开始后，缓冲时间逐渐增加，并且在经过2-3分钟后，可以看出缓冲时间大约为50秒。

在本次测试中，由40个生产者发送的总吞吐量为803MB/s，因此每个生产者的发送吞吐量约为20MB/s。在本次测试中，由于将生产者的buffer.memory设置为1GB，当缓冲区装满时，记录将在发送之前累积到1GB÷20MB/s≒50秒。

③ 请求产生的延迟

由于将Produce请求的acks设置为all，Topic的min.insync.replicas设置为2，因此在将Record复制到两个以上的Replica时即返回响应。复制完成的Record可以从Consumer获取。以下是Produce请求的延迟变化情况。在高峰期，延迟可能超过10秒，但平均情况下大约为2.5秒。

④ 检索请求的延迟

在本次验证中，我们使用了6个消费者组成消费者组，并继续获取主题数据。以下是每个消费者发送的获取请求的延迟变化情况。尽管延迟在100毫秒到300毫秒之间有一些波动，但平均延迟大约是150毫秒左右。

请提供关于API轮询的延迟信息。

使用 Consumer 的用户应用程序会调用 Poll API 来获取记录。如果 Consumer 持有记录，则记录将立即返回，否则将阻塞直到获取到新的记录为止。

在本次验证中，我们没有测量Poll API的延迟，但Consume吞吐量大约为803MB/s。因此，可以推断Record会被立即返回，并且延迟可能在几毫秒左右。

关于延迟的思考

从第①至⑤时的延迟总计约为53秒。为了验证并最大化吞吐量，这次我们以超过Producer的发送能力的速度添加Record，导致Producer的缓冲区堵塞，发送时间长达50秒。增加Producer的buffer.memory后，可以更容易地应对用户应用程序传入的Record流量的暂时增加。然而，如果不监视缓冲时间，也存在无法察觉Record发送延迟的风险。

如果Record的流量不超过Kafka的最大吞吐量（803MB/s），那么Producer就不会堵塞（几乎没有等待时间），因此估计延迟会在3秒左右。但是由于Record批量的积累会变慢，可能需要增加linger.ms。

总结

到目前为止，我们已经分为8个部分介绍了有关Kafka的调查内容和性能验证结果。Kafka是一个具有出色的可扩展性的分布式消息队列。然而，为了在保护数据的同时提取性能，需要在理解内部结构的基础上进行适当的调优。