運維管理
1 集羣搭建
1.1 單Master模式
這種方式風險較大,一旦Broker重啓或者宕機時,會導致整個服務不可用。不建議線上環境使用,可以用於本地測試。
- 啓動 NameServer
### 首先啓動Name Server
$ nohup sh mqnamesrv &
驗證Name Server 是否啓動成功
$ tail -f ~/logs/rocketmqlogs/namesrv.log
The Name Server boot success...
- 啓動 Broker
### 啓動Broker
$ nohup sh bin/mqbroker -n localhost:9876 &
### 驗證Name Server 是否啓動成功,例如Broker的IP爲:192.168.1.2,且名稱爲
### broker-a
$ tail -f ~/logs/rocketmqlogs/Broker.log
The broker[broker-a, 192.169.1.2:10911] boot success...
1.2 多Master模式
一個集羣無Slave,全是Master,例如2個Master或者3個Master,這種模式的優缺點如下:
- 優點:配置簡單,單個Master宕機或重啓維護對應用無影響,在磁盤配置爲RAID10時,即使機器宕機不可恢復情況下,由於RAID10磁盤非常可靠,消息也不會丟(異步刷盤丟失少量消息,同步刷盤一條不丟),性能最高;
- 缺點:單臺機器宕機期間,這臺機器上未被消費的消息在機器恢復之前不可訂閱,消息實時性會受到影響。
- 啓動NameServer
NameServer需要先於Broker啓動,且如果在生產環境使用,爲了保證高可用,建議一般規模的集羣啓動3個NameServer,各節點的啓動命令相同,如下:
### 首先啓動Name Server
$ nohup sh mqnamesrv &
### 驗證Name Server 是否啓動成功
$ tail -f ~/logs/rocketmqlogs/namesrv.log
The Name Server boot success...
- 啓動Broker集羣
### 在機器A,啓動第一個Master,例如NameServer的IP爲:192.168.1.1
$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-noslave/broker-a.properties &
### 在機器B,啓動第二個Master,例如NameServer的IP爲:192.168.1.1
$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-noslave/broker-b.properties &
...
如上啓動命令是在單個NameServer情況下使用的。對於多個NameServer的集羣,Broker啓動命令中-n後面的地址列表用分號隔開即可,例如 192.168.1.1:9876;192.161.2:9876。
1.3 多Master多Slave模式-異步複製
每個Master配置一個Slave,有多對Master-Slave,HA採用異步複製方式,主備有短暫消息延遲(毫秒級),這種模式的優缺點如下:
- 優點:即使磁盤損壞,消息丟失的非常少,且消息實時性不會受影響,同時Master宕機後,消費者仍然可以從Slave消費,而且此過程對應用透明,不需要人工干預,性能同多Master模式幾乎一樣;
- 缺點:Master宕機,磁盤損壞情況下會丟失少量消息。
- 啓動NameServer
### 首先啓動Name Server
$ nohup sh mqnamesrv &
### 驗證Name Server 是否啓動成功
$ tail -f ~/logs/rocketmqlogs/namesrv.log
The Name Server boot success...
- 啓動Broker集羣
### 在機器A,啓動第一個Master,例如NameServer的IP爲:192.168.1.1
$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-a.properties &
### 在機器B,啓動第二個Master,例如NameServer的IP爲:192.168.1.1
$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-b.properties &
### 在機器C,啓動第一個Slave,例如NameServer的IP爲:192.168.1.1
$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-a-s.properties &
### 在機器D,啓動第二個Slave,例如NameServer的IP爲:192.168.1.1
$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-b-s.properties &
1.4 多Master多Slave模式-同步雙寫
每個Master配置一個Slave,有多對Master-Slave,HA採用同步雙寫方式,即只有主備都寫成功,才嚮應用返回成功,這種模式的優缺點如下:
- 優點:數據與服務都無單點故障,Master宕機情況下,消息無延遲,服務可用性與數據可用性都非常高;
- 缺點:性能比異步複製模式略低(大約低10%左右),發送單個消息的RT會略高,且目前版本在主節點宕機後,備機不能自動切換爲主機。
- 啓動NameServer
### 首先啓動Name Server
$ nohup sh mqnamesrv &
### 驗證Name Server 是否啓動成功
$ tail -f ~/logs/rocketmqlogs/namesrv.log
The Name Server boot success...
- 啓動Broker集羣
### 在機器A,啓動第一個Master,例如NameServer的IP爲:192.168.1.1
$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-a.properties &
### 在機器B,啓動第二個Master,例如NameServer的IP爲:192.168.1.1
$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-b.properties &
### 在機器C,啓動第一個Slave,例如NameServer的IP爲:192.168.1.1
$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-a-s.properties &
### 在機器D,啓動第二個Slave,例如NameServer的IP爲:192.168.1.1
$ nohup sh mqbroker -n 192.168.1.1:9876 -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-b-s.properties &
以上Broker與Slave配對是通過指定相同的BrokerName參數來配對,Master的BrokerId必須是0,Slave的BrokerId必須是大於0的數。另外一個Master下面可以掛載多個Slave,同一Master下的多個Slave通過指定不同的BrokerId來區分。$ROCKETMQ_HOME指的RocketMQ安裝目錄,需要用戶自己設置此環境變量
2 mqadmin管理工具
注意:
執行命令方法:sh mqadmin {command} {args}
- 幾乎所有命令都需要配置-n表示NameServer地址,格式爲ip:port多個用分號隔開
- 幾乎所有命令都可以通過-h獲取幫助
- 如果既有Broker地址(-b)配置項又有clusterName(-c)配置項,則優先以Broker地址執行命令,如果不配置Broker地址,則對集羣中所有主機執行命令,只支持一個Broker地址。-b格式爲ip:port,port默認是10911
- 在tools下可以看到很多命令,但並不是所有命令都能使用,只有在MQAdminStartup中初始化的命令才能使用,你也可以修改這個類,增加或自定義命令
由於版本更新問題,少部分命令可能未及時更新,遇到錯誤請直接閱讀相關命令源碼
-t: topic
-c;cluster即集羣名
-b:broker
-n:namesrv
1. 例如,查看 updateTopic 的使用sh mqadmin help updateTopic
2. 關閉nameserver和所有的broker:
sh mqshutdown namesrv
sh mqshutdown broker
3. 查看所有消費組group:
sh mqadmin consumerProgress -n 192.168.1.23:9876
4. 查看指定消費組下的所有topic數據堆積情況:
sh mqadmin consumerProgress -n 192.168.1.23:9876 -g warning-group
5. 查看所有topic :
sh mqadmin topicList -n 192.168.1.23:9876
6. 查看topic信息列表詳情統計
sh mqadmin topicstatus -n 192.168.1.23:9876 -t topicWarning
7. 新增topic
sh mqadmin updateTopic –n 192.168.1.23:9876 –c DefaultCluster –t topicWarning
8. 刪除topic
sh mqadmin deleteTopic –n 192.168.1.23:9876 –c DefaultCluster –t topicWarning
9. 查詢集羣消息
sh mqadmin clusterList -n 192.168.1.23:9876
2.1 Topic相關
sh mqadmin {command} {args}
- 以下“名稱”就是command
- args 就是命令選型 + 參數值
2.2 集羣相關
2.3 Broker相關
2.4 消息相關
2.5 消費者、消費組相關
2.6 連接相關
2.7 NameServer相關
2.8 其他
3 運維常見問題
3.1 RocketMQ的mqadmin命令報錯問題
- 問題描述:有時候在部署完RocketMQ集羣后,嘗試執行“mqadmin”一些運維命令,會出現下面的異常信息:
org.apache.rocketmq.remoting.exception.RemotingConnectException: connect to <null> failed
- 解決方法:可以在部署RocketMQ集羣的虛擬機上執行export NAMESRV_ADDR=ip:9876(ip指的是集羣中部署NameServer組件的機器ip地址)命令之後再使用“mqadmin”的相關命令進行查詢,即可得到結果。
3.2 RocketMQ生產端和消費端版本不一致導致不能正常消費的問題
- 問題描述:同一個生產端發出消息,A消費端可消費,B消費端卻無法消費,rocketMQ Console中出現:
Not found the consumer group consume stats, because return offset table is empty, maybe the consumer not consume any message的異常消息。
- 解決方案:RocketMQ 的jar包:rocketmq-client等包應該保持生產端,消費端使用相同的version。
3.3 新增一個topic的消費組時,無法消費歷史消息的問題
- 問題描述:當同一個topic的新增消費組啓動時,消費的消息是當前的offset的消息,並未獲取歷史消息。
- 解決方案:rocketmq默認策略是從消息隊列尾部,即跳過歷史消息。如果想消費歷史消息,則需要設置:
org.apache.rocketmq.client.consumer.DefaultMQPushConsumer#setConsumeFromWhere。常用的有以下三種配置:
- 默認配置,一個新的訂閱組第一次啓動從隊列的最後位置開始消費,後續再啓動接着上次消費的進度開始消費,即跳過歷史消息;
consumer.setConsumeFromWhere(ConsumeFromWhere.CONSUME_FROM_LAST_OFFSET);
- 一個新的訂閱組第一次啓動從隊列的最前位置開始消費,後續再啓動接着上次消費的進度開始消費,即消費Broker未過期的歷史消息;
consumer.setConsumeFromWhere(ConsumeFromWhere.CONSUME_FROM_FIRST_OFFSET);
- 一個新的訂閱組第一次啓動從指定時間點開始消費,後續再啓動接着上次消費的進度開始消費,和consumer.setConsumeTimestamp()配合使用,默認是半個小時以前;
consumer.setConsumeFromWhere(ConsumeFromWhere.CONSUME_FROM_TIMESTAMP);
3.4 如何開啓從Slave讀數據功能
在某些情況下,Consumer需要將消費位點重置到1-2天前,這時在內存有限的Master Broker上,CommitLog會承載比較重的IO壓力,影響到該Broker的其它消息的讀與寫。可以開啓slaveReadEnable=true,當Master Broker發現Consumer的消費位點與CommitLog的最新值的差值的容量超過該機器內存的百分比(accessMessageInMemoryMaxRatio=40%),會推薦Consumer從Slave Broker中去讀取數據,降低Master Broker的IO。
3.5 性能調優問題
異步刷盤建議使用自旋鎖,同步刷盤建議使用重入鎖,調整Broker配置項useReentrantLockWhenPutMessage,默認爲false;異步刷盤建議開啓TransientStorePoolEnable;建議關閉transferMsgByHeap,提高拉消息效率;同步刷盤建議適當增大sendMessageThreadPoolNums,具體配置需要經過壓測。
3.6 在RocketMQ中msgId和offsetMsgId的含義與區別
使用RocketMQ完成生產者客戶端消息發送後,通常會看到如下日誌打印信息:
SendResult [sendStatus=SEND_OK, msgId=0A42333A0DC818B4AAC246C290FD0000, offsetMsgId=0A42333A00002A9F000000000134F1F5, messageQueue=MessageQueue [topic=topicTest1, BrokerName=mac.local, queueId=3], queueOffset=4]
- msgId,對於客戶端來說msgId是由客戶端producer實例端生成的,具體來說,調用方法MessageClientIDSetter.createUniqIDBuffer()生成唯一的Id;
- offsetMsgId,offsetMsgId是由Broker服務端在寫入消息時生成的(採用”IP地址+Port端口”與“CommitLog的物理偏移量地址”做了一個字符串拼接),其中offsetMsgId就是在RocketMQ控制檯直接輸入查詢的那個messageId。
3.7 RocketMQ 錯誤:The broker does not support consumer to filter message by SQL92
解決方法在broker-a.properties這裏類配置文件中,添加enablePropertyFilter=true配置項
4. 常用命令
4.1 啓動namesrv
nohup mqnamesrv start &
4.2 啓動broker
nohup sh mqbroker -c ../conf/2m-2s-sync/broker-a.properties &
4.3 關閉namesrv
sh mqshutdown namesrv
4.4 關閉broker
sh mqshutdown broker
4.5 查看集羣狀態
sh mqadmin clusterlist -n 152.168.1.88:9876
5. 日誌
5.1 namesrv日誌
/logs/rocketmqlogs/namesrv.log
5.2 broker
/logs/rocketmqlogs/broker.log