引言

上期我們對比了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響應時間的劇烈波動，造成部分客戶端的響應時間過長，影響客戶端投遞的實時性以及客戶端的業務吞吐量。

附錄

測試環境

服務端為單機部署，機器配置如下：

應用版本：

測試指令碼:

未完待續

經過本期的測試，RocketMQ在穩定性上也是完勝Kafka，如果只是小規模的業務，Kafka可以滿足需求，但要是對業務的複雜度和穩定性有更高的要求，RocketMQ則是更好的選擇。

本期測試暫時告一段落了，但Kafka和RocketMQ的對戰並沒有停止，更多的場景對比還在後面，敬請期待後續的比拼！