微服務基準測試:Chronicle Queue比Kafka快750倍?

banq 發表於 2022-01-27
微服務 Kafka

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