從 Apache RocketMQ 和 Kafka 看 Topic 數量對單機性能的影響

02-02

摘要： 這次，我們來模擬一個真實的場景： * 消息的發送和訂閱一定是共存的 * 要支持多個訂閱端訂閱自己感興趣的消息我們將針對 RocketMQ 和 Kafka，對比在上述場景中，究竟誰更勝一籌。

阿里雲消息隊列測試小組出品

上一期我們對比了三類消息產品(Kafka、RabbitMQ、RocketMQ)單純發送小消息的性能，受到了程序猿們的廣泛關注，其中大家對這種單純的發送場景感到並不過癮，因為沒有任何一個網站的業務只有發送消息。本期，我們就來模擬一個真實的場景：

消息的發送和訂閱一定是共存的
要支持多個訂閱端訂閱自己感興趣的消息

本期我們將針對 RocketMQ 和 Kafka，對比在上述場景中，究竟誰更勝一籌。在正式開始測試之前，首先要向大家明確2個概念：

查看上一期文章

1. Topic為何物

Topic是消息中間件里一個重要的概念，每一個Topic代表了一類消息，有了多個Topic，就可以對消息進行歸類與隔離。

可以參照下圖的動物園餵食模型，每一種動物都只能消費相對應的食品。

2. 分區為何物

Kafka和RocketMQ都是磁碟消息隊列的模式，對於同一個消費組，一個分區只支持一個消費線程來消費消息。過少的分區，會導致消費速度大大落後於消息的生產速度。所以在實際生產環境中，一個Topic會設置成多分區的模式，來支持多個消費者，參照下圖：

在互聯網企業的實際生產環境中，Topic數量和分區都會比較多，這就要求消息中間件在多Topic共存的時候，依然能夠保證服務的穩定性。下面就進入測試環節，看看消息發送端，訂閱端共存時，Kafka和RocketMQ對多Topic的處理能力。

測試目的

對比發送端、接收端共存情況下，Topic數量對Kafka、RocketMQ的性能影響，分區數採用8個分區。這次壓測我們只關注服務端的性能指標，所以壓測的退出標準是:

不斷增加發送端的壓力,直到系統吞吐量不再上升,而響應時間拉長。此時服務端出現性能瓶頸，獲取相應的系統最佳吞吐量，整個過程中保證消息沒有累積。

測試場景

默認每個Topic的分區數為8，每個Topic對應一個訂閱者，逐步增加Topic數量。得到如下數據：

可以看到，不論Topic數量是多少，Kafka和RocketMQ均能保證發送端和消費端的TPS持平，就是說，保證了消息沒有累積。

根據Topic數量的變化，畫出二者的消息處理能力的對比曲線如下圖：

從圖上可以看出：

Kafka在Topic數量由64增長到256時，吞吐量下降了 98.37% 。
RocketMQ在Topic數量由64增長到256時，吞吐量只下降了 16% 。

為什麼兩個產品的表現如此懸殊呢？這是因為Kafka的每個Topic、每個分區都會對應一個物理文件。當Topic數量增加時，消息分散的落盤策略會導致磁碟IO競爭激烈成為瓶頸。而RocketMQ所有的消息是保存在同一個物理文件中的，Topic和分區數對RocketMQ也只是邏輯概念上的劃分，所以Topic數量的增加對RocketMQ的性能不會造成太大的影響。

測試結論

在消息發送端，消費端共存的場景下，隨著Topic數的增加Kafka吞吐量會急劇下降，而RocketMQ則表現穩定。因此Kafka適合Topic和消費端都比較少的業務場景，而RocketMQ更適合多Topic，多消費端的業務場景。

你知道阿里雲消息隊列（MQ）就是 Apache RocketMQ 的商業版嗎？

經過上面的測試，RocketMQ幾乎是完勝Kafka，其實這並不奇怪，因為RocketMQ就是針對互聯網的生產要求孕育而生的，讀者現在也應該明白為什麼 RocketMQ 可以支撐阿里集團的海量消息業務了吧。目前阿里雲上的消息隊列（MQ）就是RocketMQ的商業版，除了與RocketMQ一樣具備極佳的性能，還具備哪些差異和優勢呢？我們一起來看一看吧：

阿里雲消息隊列Kafka企業級消息服務（MQ-Kafka） VS Apache Kafka

為了擁抱開源生態，阿里雲消息隊列（MQ）MQ 推出 Kafka 企業級消息服務（MQ-Kafka），全面融合 Kafka 開源生態，兼容 Kafka API，做到無縫遷移，打造更安全、更可靠、更易運維的 Kafka 企業級消息服務。

Apache Kafka和消息隊列 Kafka 企業級消息服務（MQ-Kafka）在性能、可用性、可靠性等方面的對比如下：