Kafka vs RocketMQ——多Topic對性能穩定性的影響-轉自阿里中間件

引言

上期咱們對比了RocketMQ和Kafka在多Topic場景下，收發消息的對比測試，RocketMQ表現穩定，而Kafka的TPS在64個Topic時能夠保持13萬，到了128個Topic就跌至0.85萬，致使沒法完成測試。咱們不由要問：

爲何看不到Kafka性能暴跌的趨勢呢？

今天的測試，就來排查一下這個問題，而後驗證一下兩個系統對外服務的穩定性。本次測試，要引入「穩定性測試」這個概念，那什麼是穩定性測試呢？咱們先來看一下定義：

穩定性測試：測試系統的長期穩定運行能力。在系統運行過程當中，對系統施壓，觀察系統的各類性能指標以及服務器的負載指標。

好像有點抽象，咱們仍是看一個例子吧。

下面的測試對比圖，是用來評測汗血寶馬和蒸汽機車誰快的一組競速曲線：

圖1 汗血寶馬和蒸汽火車的速度穩定性對比

上圖的橫軸表示測試時間，縱軸表示火車和馬的速度，能夠看到，馬的加速和最高速度均好於火車。可是因爲體力緣由，15分鐘後，馬就很難維持最高速度，只能稍做休息再加速，直至體力耗盡；而火車全程達到最高速度就基本不會變了。因此結論很明顯，火車的速度穩定性優於汗血寶馬。

假想一下：若是測試時間只取15分鐘會獲得什麼結論呢？汗血寶馬不管是加速，仍是最高速度，乃至單位時間內經過的路程均完勝火車。因此若是是要對長途運輸作一個評測的話，那麼正確的測試方式是——拉長測試時間，以觀察被測對象的穩定性。

OK，再次回到咱們上次測試留下的疑問——暴跌無趨勢。其緣由極可能是，在早期的32Topic，64Topic時，Kafka就已經出現了下跌的趨勢，只是咱們壓測的時間不夠，算做測試經過了。

本期測試，咱們沿用上一期的測試方式，惟一不一樣的就是把壓測時間從15分鐘拉長到1小時，看看在較長的壓力時間內，Kafka和RocketMQ哪個產品對外服務更穩定。

測試目的

消息收發端共存的狀況下，RocketMQ和Kafka各運行約1個小時，觀察不一樣Topic數量時，Kafka、RocketMQ性能指標（TPS&響應時間）的波動性。

測試場景

默認每一個Topic的分區數爲8，每一個Topic對應一個訂閱者，逐步增長Topic的數量，這裏性能是否抖動根據趨勢圖作直觀的判斷，數據以下：

作徹底部的測試場景後會發現，正如以前的猜想，Kafka在32和64個Topic時，就已經出現了不穩定的狀況。下面看一下32和64個Topic的詳細數據，以下圖所示：

圖2. 32個Topic性能曲線對比

藍色Kafka的TPS曲線在18分鐘之後，就開始上下波動，毫無規律，而RocketMQ則表現穩定。下面再看64個Topic的狀況，以下圖所示：

圖3. 64個Topic性能曲線對比

圖4. 64個Topic客戶端發送響應時間對比

Kafka的TPS在前20分鐘保持穩定，並大幅度領先RocketMQ。20分鐘後又開始出現不規則波動，這些波動直接致使響應時間的變化（圖4），某個時刻Kafka的客戶端響應時間會達到25毫秒，而RocketMQ全程都是5毫秒。
此次的對比3個場景中， Kafka勝出一個，就是8個Topic的場景，如圖5所示，因爲Topic個數和分區數的限制，致使Kafka只適合小規模的業務系統。

圖5. 8個Topic性能曲線對比

測試結論

1. Topic數的增長對RocketMQ無影響，長時間運行服務很是穩定。
2. Kafka 的Topic數量建議不要超過8個。8個以上的Topic會致使Kafka響應時間的劇烈波動，形成部分客戶端的響應時間過長，影響客戶端投遞的實時性以及客戶端的業務吞吐量。

附錄

測試環境

服務端爲單機部署，機器配置以下：

CPU	24核
內存	94G
硬盤	Seagate Constellation ES (SATA 6Gb/s) 2.00 TB 7202 rpm
網卡	1000Mb/s

應用版本：

消息中間件	版本
Kafka	0.8.2
RocketMQ	3.4.8

測試腳本:

壓力端	Jmeter的java客戶端
消息大小	128 字節
併發數	能達到服務端最大TPS的最優併發
Topic分區數量	8
刷盤策略	異步落盤

未完待續

通過本期的測試，RocketMQ在穩定性上也是完勝Kafka，若是隻是小規模的業務，Kafka能夠知足需求，但要是對業務的複雜度和穩定性有更高的要求，RocketMQ則是更好的選擇。