Chronicle Queue比Kafka比快750倍？

比较 Chronicle Queue 和 Apache Kafka 的一个有趣的基准测试，请注意：对于极其重视低延迟应用程序，kafka 可能不是最佳适合工具，Kafka适合高吞吐量和大数据可扩展的应用。

Apache Kafka 是服务间通信的常见选择。Kafka便于消息的并行处理，是日志聚合的不错选择。Kafka号称是低延迟、高吞吐量。但是，对于云中的许多微服务应用程序，Kafka 是否足够快？

当我编写Chronicle Queue Open Source时，我的目标是开发一个具有微秒延迟的消息传递框架，世界各地的银行都将其用于延迟敏感的交易系统。

在本文中，我将描述 Kafka 如何在吞吐量方面不像微服务应用程序的 Chronicle Queue 那样容易扩展。即使在吞吐量较低的情况下，Chronicle Queue 的速度也提高了大约750 倍。

使用 Chronicle 的微服务延迟**：**在 500 kmsg/s 时，Chronicle Queue Enterprise 的 99%ile 单个微服务端到端延迟为 3.69 微秒

使用 Kafka 的微服务延迟：使用 Kafka 进行相同的测试，但在 100 kmsg/s 的较低吞吐量下，99%ile 单阶段微服务端到端延迟约为 2633 微秒（从 150kmsg/s 开始，延迟急剧增加）。

Kafka 最初是为日志聚合而设计的。它有许多连接器，对于这个用例，它做得很好。我测量了良好的结果，表明使用 Kafka 代替典型系统中的日志文件写入可以提高性能并显着提高可管理性。

测试场景

在每种情况下，使用相同的测试硬度。一切都部署在运行 Ubuntu 21.04 的 Ryzen 9 5950X 上。所有测试均使用相同的 MP600 PRO XT 2TB M.2 NVMe 驱动器。基准测试的来源可在此处获得。https://github.com/OpenHFT/Microservice-Benchmark

对于微服务基准测试：

• 添加高分辨率时间戳 (System.nanoTime())
• 序列化第一条消息
• 发布第一条消息
• 消费第一条消息
• 反序列化第一条消息
• 调用微服务
• 添加第二个高分辨率时间戳
• 序列化另一个主题/队列上的第二条消息
• 发布第二条消息
• 消费者第二条消息
• 反序列化第二条消息。
• 记录端到端延迟

注意：生成的每条消息都会创建第二条消息作为响应，因此与单跳消息传递基准相比，实际消息数量翻了一番。

…

更多点击标题见原文图表

结论：

虽然 Kafka 是日志聚合的不错选择，但由于其相对较高的端到端延迟，对于许多涉及微服务的用例而言，它的延迟可能不够低。

Chronicle Queue 开源在超过 99.99% 的时间内实现了低于 100 微秒的一致延迟，而 Kafka 即使在吞吐量的 1/5 时也有 7 毫秒的异常值。

Chronicle Queue Enterprise 具有其他功能，可在超过 99.99% 的情况下将延迟与低于 10 微秒的延迟保持一致。