引言
上一期我們對比了三類消息產品(Kafka、RabbitMQ、RocketMQ)單純發送小消息的性能，受到了程序猿們的廣泛關注，其中大家對這種單純的發送場景感到並不過癮，因為沒有任何一個網站的業務只有發送消息。本期，我們就來模擬一個真實的場景：
- 消息的發送和訂閱一定是共存的
- 要支持多個訂閱端訂閱自己感興趣的消息
鑒於上一期Kafka和RocketMQ的指標和關注度很高，本期我們將只針對這兩個產品，對比在上述場景中，究竟誰更勝一籌。在正式開始測試之前，首先要向大家明確2個概念：
Topic為何物
Topic是消息中間件里一個重要的概念，每一個Topic代表了一類消息，有了多個Topic，就可以對消息進行歸類與隔離。
可以參照下圖的動物園喂食模型，每一種動物都只能消費相對應的食品。
分區為何物
Kafka和RocketMQ都是磁盤消息隊列的模式，對於同一個消費組，一個分區只支持一個消費線程來消費消息。過少的分區，會導致消費速度大大落后於消息的生產速度。所以在實際生產環境中，一個Topic會設置成多分區的模式，來支持多個消費者，參照下圖：
在互聯網企業的實際生產環境中，Topic數量和分區都會比較多，這就要求消息中間件在多Topic共存的時候，依然能夠保證服務的穩定性。下面就進入測試環節，看看消息發送端，訂閱端共存時，Kafka和RocketMQ對多Topic的處理能力。
測試目的
對比發送端、接收端共存情況下，Topic數量對Kafka、RocketMQ的性能影響，分區數采用8個分區。這次壓測我們只關注服務端的性能指標，所以壓測的退出標准是:
不斷增加發送端的壓力,直到系統吞吐量不再上升,而響應時間拉長。此時服務端出現性能瓶頸，獲取相應的系統最佳吞吐量，整個過程中保證消息沒有累積。
測試場景
默認每個Topic的分區數為8，每個Topic對應一個訂閱者，逐步增加Topic數量。得到如下數據：
產品 |
Topic數量 |
發送端並發數 |
發送端RT（ms） |
發送端TPS |
消費端TPS |
RocketMQ |
64 | 800 | 8 | 9w | 8.6w |
| 128 | 800 | 9 | 7.8w | 7.7w | |
| 256 | 800 | 10 | 7.5w | 7.5w | |
Kafka |
64 | 800 | 5 | 13.6w | 13.6w |
| 128 | 256 | 23 | 8500 | 8500 | |
| 256 | 256 | 133 | 2215 | 2352 |
可以看到，不論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，多消費端的業務場景。
附錄：
測試環境
服務端為單機部署，機器配置如下：
| CPU | 24核 |
| 內存 | 94G |
| 硬盤 | Seagate Constellation ES (SATA 6Gb/s) 2,000,398,934,016 bytes [2.00 TB] 7202 rpm |
| 網卡 | 1000Mb/s |
應用版本：
| 消息中間件 | 版本 |
| Kafka | 0.8.2 |
| RocketMQ | 3.4.6 |
測試腳本
| 壓力端 | Jmeter的java客戶端 |
| 消息大小 | 128字節 |
| 並發數 | 能達到服務端最大TPS的最優並發 |
| Topic分區數量 | 8 |
| 刷盤策略 | 異步落盤 |
未完待續
經過上面的測試，RocketMQ幾乎是完勝Kafka，其實這並不奇怪，因為RocketMQ就是針對互聯網的生產要求孕育而生的，讀者現在也應該明白為什么RocketMQ可以支撐阿里集團的海量消息業務了吧。
本期測試暫時告一段落了，測試中涉及到的多Topic場景，其實壓測時間均只有20分鍾，對於一個消息中間件產品來說，過短的執行時間是無法判斷它們的穩定性的。下一期我們會繼續探索多分區場景下，Kafka和RocketMQ對外服務的穩定性。敬請期待后續的比拼！