一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第18天，点击查看活动详情。
原文：How Does Kafka Perform When You Need Low Latency? - DZone Big Data
作者： Peter Lawrey
大部分 Kafka 的基准测试基本都是测试吞吐量，但不是时间延迟。Apache Kafka 一般用于用于高吞吐量，而不是对时延敏感的消息传递，但它确实有一个低时延的配置。(主要是设置linger.ms=0以及减少缓冲区的大小）。在这种配置下，对于适度的吞吐量，我们可以得到 < 1ms 的延迟，这在很大程度上是不错的表现。
基准测试往往用于高吞吐量配置的Kafka集群。虽然这（高吞吐量）可能是最常见的使用方法，但如果我们需要更低的时延，Kafka 的表现怎么样呢？
哪里有好用的实验测试呢？
这些是测试更高的吞吐量的例子，结果表明，对于不同的情况，时延在 2.5 到 30 毫秒之间。
-
Confluent benchmark 与Apache Pulsar和Rabbit MQ（pro Kafka）相比，99%的情况下："Kafka在更高的吞吐量下提供了最低的时延，同时还提供了强大的耐久性和高可用性"。
-
NativeStream benchmark 将Pulsar 和 Kafka（pro Pulsar）进行比较：" Pulsar的 百分之九十九的时延是在5到15毫秒之间"。
-
Instacluster performance, 比较不同生产者数量以及不同配置下的平均时延。
-
Datastax latency 使用 Confluent 一样的基准测试。但结论似乎是，当把每条消息都写入到磁盘时，Pulsar 表现更好。
-
Using Confluent Cloud from AWS： "在特定的测试参数下，Kafka 百分之九十九的时延是 100-200毫秒，比 Pub/Sub 的延迟低得多。"
我的看法是，这些基准测试并不是试图展示低时延，而是展示作者认为在高负载下的良好时延。
对Kafka的低延时进行基准测试
对于一个低延迟的系统来说，我们需要能够尽量支持我们的要求的硬件。这通常需要我们能有大量高性能CPU和足够大的 IO 带宽。
go fast（更快？）的最好方法往往是遵守 kiss 原则。我只从一台电脑开始实验，一台Ryzen 9 5950X，配备64GB内存和一个海盗船 MP600 PRO XT M.2 固态硬盘的电脑。
显然，集群的使用是 Kafka 的一个重要考量因素，但让我们从一个简单的情况开始：一台机器，消息有两跳，中间有一个简单的微服务。
一台机器，一个微不足道的微服务，传输的时延
Kafk a被配置成了低时延，并使用多个生产者来支持一个重要的，但较低的消息吞吐量。
在这种配置下，Kafka的延迟比上面基准测试更小。
一个生产者处理这种吞吐量表现并不是很好，但两个或者更多的生产者（我最多测试了10个）会有比较好的效果。增加分区的数量仅仅增加了开销（尽管是轻微的）。增加消费者的数量，则会在延迟方面出现微小的变化。
没有结论
我喜欢用结论来结束，但这给我留下的问题比答案多。文章开头的链接旨在讨论 Kafka 的低时延特性。然而，实际上，这些测试将 Kafka 配置成了提供较大的吞吐量，而不是低时延。当配置为提供较低时延时，Kafka 可以有更好的表现，而且即使在这种设置中，其他指标也可以表现得不错。
