Apache Pulsar 與 Kafka 延遲性比較的測試過程是怎么樣的

本篇文章為大家展示了Apache Pulsar 與 Kafka 延遲性比較的測試過程是怎么樣的，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

下面將介紹測試細節。

測試細節介紹：

>>> 設定基準

To set up the benchmark tests, we followed the steps documented on the OpenMessaging site. After applying the Terraform configuration, you get the following set of EC2 instances: 我們根據 OpenMessaging 網站上提供的步驟進行了基準測試。應用 Terraform 配置可以得到以下 EC2 實例集：

用于 Pulsar/BookKeeper 和 Kafka broker 的 i3.4xlarge 實例包含兩個 NVMe SSD，以提高性能。這兩個功能強大的虛擬機都有 16 個 vCPU、122 GiB 內存和高性能磁盤。

兩個 SSD 對 Pulsar 而言是理想設定，因為不僅可以寫入兩個數據流，數據流還能在磁盤上并行。Kafka 還可以通過分配兩個驅動器的分區來使用這兩個 SDD。

用于 Pulsar 和 Kafka 的 Ansible playbook 使用 `tuned-adm` 命令（延遲性能配置文件）調優低延遲性能。

tuned-adm 命令詳情參考 https://linux.die.net/man/1/tuned-adm

>>> 工作負載

雖然基準測試中附帶了一些可以立即運行的工作負載，但是為了更接近 LinkedIn Engineering 博客中 Kafka 的測試結果，我們仍進行了一些修改。定義新工作負載并不難，只需創建帶有測試更新參數的 YAML 文件即可。

閱讀 LinkedIn 博客你便會發現，他們運行的消息大小都是 100 字節的，因為通常而言，如果消息太小（遠小于100字節），測試對比結果并不明顯；而所有的消息隊列都不擅長處理“大消息”（遠大于 100 字節），所以這里選擇了一個折中的大小，即 100 字節，這也是所有消息系統測試中選擇使用的單條消息的大小。

這個大小更有利于測試消息系統本身的性能。無論每條消息大小如何，用于測試的消息總量是固定的，消息系統處理消息的效率越高，性能越好；同時，網絡或磁盤吞吐量限制對測試結果產生影響的可能性越低。消息系統在處理“大消息”時的性能表現也是一個值得探討的話題，但我們目前只測試“小消息”。

另外，在測試中，我們還添加了 partition 數目為 6（簡稱：6 分區）的一項基準測試。因為在 LinkedIn 測試中使用了很多 6 分區，所以我們也把它添加進來。

LinkedIn 博客中包含 producer-only 和 consumer-only 工作負載，而我們在測試中使用的工作負載都同時包括 producer 和 consumer。原因有以下兩點。

首先，就目前的情況來看，基準測試不支持 producer-only 或 consumer-only 工作負載；其次，在實際情況中，消息系統同時為 producer 和 consumer 服務。我們決定采用生產消息和消費消息的實際場景來測試。

綜上所述，我們用于測試的負載集如下：

Kafka consumer group 和 Pulsar 訂閱很相似，都允許一個或多個 consumer 接收一個 topic 上的所有消息。當一個 topic 與多個 consumer group/subscription 有關聯時，消息系統向 topic 提供每條消息的多個副本，或“扇出“消息。

發布在 topic 上的每條消息都被發送到所有 consumer group/subscription。如果所有消息都被發送到同一 topic，且這一 topic 上只有一個 consumer group/subscription，則 producer 速率與 consumer 速率相等。

如果單個 topic 上有兩個 consumer group/subscription，則 consumer 速率是 producer 速率的兩倍。我們盡量簡化測試，所以采用了前者，即多個 consumer 接收一個 topic 上的所有消息。

上述內容就是Apache Pulsar 與 Kafka 延遲性比較的測試過程是怎么樣的，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。