引言
上期我們對比了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性能曲線對比
測試結論
- Topic數的增加對RocketMQ無影響，長時間運行服務非常穩定。
- 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則是更好的選擇。