RocketMQ實戰疑問和原理解答(實時更新)

Q1：怎麼解決remote toomuch exception的問題呢？

A：主要是的客戶端傳送的TPS太高，達到了broker的瓶頸。

Q2: broker無法寫入store.log的日誌報錯，報異常如下：

2018-12-17 14:09:37 WARN StoreScheduledThread1 - disk space will be full soon, but delete file failed.
2018-12-17 14:09:42 WARN SendMessageThread_1 - message store is not writeable, so putMessage is forbidden 16
2018-12-17 14:09:47 INFO StoreScheduledThread1 - physic disk maybe full soon, so reclaim space, 0.9246850495308918

R：物理檔案不能無限制的寫入磁碟，當磁碟空間達到閾值時，不再接受訊息，broker列印出日誌，訊息傳送失敗。

A：擴容 或者根據業務縮短commitlog在磁碟的儲存時間。或者調大diskMaxUsedSpaceRatio = 75的預設值到90。

Q3:如果在多topic下，併發對多個partition檔案寫入，相當於隨機io，所以效能不好，那rocketmq也會對多個consumerqueue寫入，為什麼就不會出現效能問題?

A：kafka與rocketmq的儲存區別在於：kafka是每個topic下會對應好幾個.log檔案；而rocketmq則是將所有的topic訊息都寫在了一個commitlog裡。當topic很多時，kafka下的.log檔案就會很多，而commitlog數量則不會受到影響（受影響的是consumequeue，但是consumequeue檔案大小很小，基本上都是在記憶體裡，不需要訪問磁碟）。

在topic很少時，kafka是順序讀，rocketmq是隨機讀，但是rocketmq基於os的pagecache，所以效能不會慢於順序讀。
在topic很多時，kafka檔案很多，就變成了隨機讀，效能會下降。rocketmq依然不受影響。

kafka記憶體不足時會將已經快取的資料swap到磁碟，同時再從磁碟讀取新資料。增加了磁碟IO，效能就降低了。
但是rocketmq 會盡可能利用OS的磁碟IO排程演算法（NOOP）以及PageCache，儘可能的減少磁碟IO。