微服务基准测试:Chronicle Queue比Kafka快750倍?

22-01-27 banq

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

 

1
猜你喜欢