如何證明 rocketmq 集群本身沒有問題呢？其實也很簡單，我們通常乙個常用的技巧是檢視 rocketmq 訊息寫入的效能，執行如下命令：
cd ~/logs/rocketmqlogs/
grep 'pagecachert' store.log | more
在 rocketmq broker 中會每隔 1 分鐘列印出上一分鐘訊息寫入的耗時分布，例如 [<=0ms] 表示在這一秒鐘寫入訊息在 broker 端的延時小於 0ms 的訊息條數，其他的依次類推，通常在 100~200ms 在上萬次訊息傳送中也不會出現 1 次。從這裡基本能看出 broker 端寫入的壓力。
RocketMQ Broker的最佳實踐
翻譯自rocket官方文件 broker的方式有非同步主，同步主，或者從。如果不能容忍訊息丟失，建議以同步主從方式部署。如果對丟失沒那麼嚴格，但是希望高可用，可以部署為非同步主從，如果你想更簡單，可以使用非同步主而不需要從機。非同步刷盤是推薦的方式,因為同步刷盤太多的消耗而且造成大量的效能丟失，如果...
rocketmq broker 訊息分發流程分析
文章基於rocket mq4.0 分析 server接收到訊息後，會將訊息分發到對應的consumequeue中，等待client端拉取消費。核心類 org.apache.rocketmq.store.defaultmessagestore.reputmessageservice類圖 該類繼承 se...
RocketMQ Broker 快速失敗機制
版本 4.2.0，原始碼 class檔案 broker的快速失敗機制是為了防止請求過載，導致broker處理請求效率變低，從而影響訊息的消費 broker啟動的時候會初始化broke stfailure this.broke stfailure new broke stfailure this th...