大多数Kafka基准测试似乎都是测试高吞吐量而不是低延迟。Apache Kafka传统上用于高吞吐量，而不是对延迟敏感的消息传递，但它确实有一个低延迟的配置。(主要是设置linger.ms=0和减少缓冲区大小）。在这种配置下，对于适度的吞吐量，你可以得到低于1毫秒的延迟，这在很大程度上是一个很好的例子。
基准测试倾向于关注高吞吐量配置中的Kafka集群。虽然这可能是最常见的使用情况，但如果你需要更低的延迟，它的表现如何？
哪里有一些延迟的基准测试？
这些是测试较高吞吐量的各种基准，从200kmsg/s到800kmsg/s，端到端延迟在2.5到30毫秒之间。
-
Confluent的基准，与Apache Pulsar和Rabbit MQ（pro Kafka）相比，看了99%的延迟。"Kafka在更高的吞吐量下提供最低的延迟，同时还提供强大的耐久性和高可用性。"
-
NativeStream基准比较了Pulsar和Kafka（亲Pulsar）。"Pulsar的第99个百分点的延迟在5到15毫秒的范围内。"
-
Instacluster的性能，看的是不同生产者数量下的平均延迟，不同的配置。
-
Datastax的延迟基准使用与Confluent相同的基准。他们的结论似乎是，当把每个消息都冲到磁盘时，Pulsar更好。
-
使用AWS的Confluent Cloud。"在我的特定测试参数下，Kafka p99的延迟是100-200毫秒，比Pub/Sub的延迟低得多。"
我的印象是，这些基准测试并不是试图显示低延迟，而是显示作者认为在高负载下的良好延迟。
基准测试Kafka的低延迟性
对于一个低延迟的系统来说，你需要的是能够最好地支持你的要求的硬件。这通常是你能负担得起的大量最快的CPU和足够多的IO带宽。
快速的最好方法往往是尽可能少做，并保持解决方案的简单。在我的案例中，我只从一台电脑开始，一台Ryzen 9 5950X，配备64GB内存和一个海盗船MP600 PRO XT M.2驱动器。
显然，集群支持是Kafka的一个重要用例，但让我们从一个真正简单的端到端用例开始：一台机器，两个消息跳转和一个琐碎的微服务。
一台机器，一个微不足道的微服务，端到端的延时
这个基准与之前 在这里发现的一个基准相似。然而，Kafka被配置为更低的延迟，并使用多个生产者来支持一个重要的，但较低的消息吞吐量。
在这种配置下，Kafka的延迟只有上面的基准报告中的一小部分。
一个生产者不能很好地处理这种吞吐量，但两个及以上的生产者（我最多测试了10个）会产生良好的效果。增加分区的数量只增加了开销（尽管是轻微的）。增加消费者的数量，在延迟方面出现了小的变化。
为了正确看待这个问题，我增加了使用Chronicle Queue Enterprise的单个生产者的结果，你可能期望它的抖动要少得多。(请看上图底部几乎看不见的蓝线。这条线正好在X轴上方；看不到这条线的原因是Chronicle Queue的性能明显比Kafka好）。这表明同一台机器上的进程之间的性能。
没有结论
我喜欢用结论来结束，但这给我留下的问题比答案多。帖子开头链接的基准测试旨在讨论Kafka的低延时特性。然而，实际上，这些测试似乎反而将Kafka配置成了最大的吞吐量，而不是低延迟。当适当地配置为低延迟时，Kafka可以产生更好的基准数字，但即使在这种设置中，其他选项也可以表现得更好两个或多个数量级。
