比较 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 微秒的延迟保持一致。