微服務基準測試：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 微秒的延遲保持一致。