1、背景

一個(gè) RocketMQ 集群由4主4從組成，突然其中3臺(tái)服務(wù)器“竟然”在同一時(shí)間下線，其監(jiān)控顯示如下：

 

2、故障分析

出現(xiàn)問(wèn)題，先二話不說(shuō)，馬上重啟各服務(wù)器，盡快恢復(fù)集群，降低對(duì)業(yè)務(wù)的影響，接下來(lái)開(kāi)始對(duì)日志進(jìn)行分析。

Java 進(jìn)程自動(dòng)退出(rocketmq 本身就是一個(gè)java進(jìn)程)，一種最常見(jiàn)的問(wèn)題是由于內(nèi)存溢出或由于內(nèi)存泄漏導(dǎo)致進(jìn)程發(fā)送Crash等。由于我們的啟動(dòng)參數(shù)中未配置

• -XX:+HeapDumpOnOutOfMemoryError

• -XX:HeapDumpPath=/opt/jvmdump

這兩個(gè)參數(shù)，不能直接根據(jù) 是否生成 dump 文件，那退而求其次去查看其GC日志，將GC日志下載到本地，然后可以使用一個(gè)在線gc日志分析工具：https://gceasy.io/ ，將 gc 日志上傳后會(huì)給出圖形化的展示，其圖如下：

 

 

既然 Java 進(jìn)程不是由于內(nèi)存溢出等問(wèn)題導(dǎo)致的退出，那又會(huì)是什么原因呢？那我們來(lái)看一下那個(gè)點(diǎn)的broker的日志，其關(guān)鍵日志截圖如下：

 

但我始終相信，肯定是執(zhí)行了手動(dòng)執(zhí)行了 kill 命令導(dǎo)致進(jìn)程退出的，經(jīng)過(guò)網(wǎng)上查找查，得知可以通過(guò)查閱系統(tǒng)日志/var/log/messages 來(lái)查看系統(tǒng)命令的調(diào)用，于是乎把日志文件下載到本地，開(kāi)始搜索 kill 關(guān)鍵字，發(fā)現(xiàn)如下日志：

 

這個(gè)命令是有問(wèn)題的，沒(méi)有使用 nohup ，如果會(huì)話失效，該進(jìn)程就會(huì)被退出，為了驗(yàn)證，我們?cè)俨橐幌逻M(jìn)程退出時(shí)的日志：

 

故障原因基本分析到位了，運(yùn)維在啟動(dòng)的時(shí)候沒(méi)有使用 nohup 來(lái)啟動(dòng)，故馬上排查剛啟動(dòng)的集群的方式，重新重啟剛啟動(dòng)的 Broker。

RocketMQ優(yōu)雅重啟小建議：

1. 首先將 broker 的寫權(quán)限關(guān)閉，命令如下：

   bin/mqadmin updateBrokerConfig -b 192.168.x.x:10911 -n 192.168.x.x:9876 -k brokerPermission -v 4
   

2. 通過(guò) rocketmq-console 查看該broker的寫入TPS，當(dāng)寫入TPS降為0后，再使用 kill pid 關(guān)閉 rocketmq 進(jìn)程。溫馨提示：將broker的寫權(quán)限關(guān)閉后，非順序消息不會(huì)立馬拒絕，而是需要等客戶端路由信息更新后，不會(huì)在往該broker上發(fā)送消息，故這個(gè)過(guò)程需要等待。

3. 啟動(dòng) rocketmq

   nohup bin/mqbroker -c conf/broker-a.conf  /dev/null  2>&1 &
   

4. 恢復(fù)該節(jié)點(diǎn)的寫權(quán)限

   bin/mqadmin updateBrokerConfig -b 192.168.x.x:10911 -n 192.168.x.x:9876 -k brokerPermission -v 6