RocketMQ 怎麼處理消息丟失風險

先來一張最簡單的消費流程圖：



上圖中大致包含了這麼幾種場景：

1. 生產者產生消息發送給RocketMQ
2. RocketMQ接收到了消息之後，必然需要存到磁盤中，否則斷電或宕機之後會造成數據的丟失
3. 消費者從RocketMQ中獲取消息消費，消費成功之後，整個流程結束

這三種場景都可能會產生消息的丟失，如下圖所示：

1. 場景1中生產者將消息發送給Rocket MQ的時候，如果出現了網絡抖動或者通信異常等問題，消息就有可能會丟失
2. 場景2中消息需要持久化到磁盤中，這時會有兩種情況導致消息丟失
   ①RocketMQ爲了減少磁盤的IO，會先將消息寫入到os cache中，而不是直接寫入到磁盤中，消費者從os cache中獲取消息類似於直接從內存中獲取消息，速度更快，過一段時間會由os線程異步的將消息刷入磁盤中，此時纔算真正完成了消息的持久化。在這個過程中，如果消息還沒有完成異步刷盤，RocketMQ中的Broker宕機的話，就會導致消息丟失
   ②如果消息已經被刷入了磁盤中，但是數據沒有做任何備份，一旦磁盤損壞，那麼消息也會丟失
3. 消費者成功從RocketMQ中獲取到了消息，還沒有將消息完全消費完的時候，就通知RocketMQ我已經將消息消費了，然後消費者宕機，但是RocketMQ認爲消費者已經成功消費了數據，所以數據依舊丟失了

那麼如何保證消息的零丟失呢？

1. 場景1中保證消息不丟失的方案是使用RocketMQ自帶的事務機制來發送消息，大致流程爲
   ①首先生產者發送half消息到RocketMQ中，此時消費者是無法消費half消息的，若half消息就發送失敗了，則執行相應的回滾邏輯
   ②half消息發送成功之後，且RocketMQ返回成功響應，則執行生產者的核心鏈路
   ③如果生產者自己的核心鏈路執行失敗，則回滾，並通知RocketMQ刪除half消息
   ④如果生產者的核心鏈路執行成功，則通知RocketMQ commit half消息，讓消費者可以消費這條數據
   其中還有一些RocketMQ長時間沒有收到生產者是要commit/rollback操作的響應，回調生產者接口的細節，感興趣的可以參考我的這篇博文 RocketMQ分佈式事務原理
   在使用了RocketMQ事務將生產者的消息成功發送給RocketMQ，就可以保證在這個階段消息不會丟失
2. 在場景2中要保證消息不丟失，首先需要將os cache的異步刷盤策略改爲同步刷盤，這一步需要修改Broker的配置文件，將flushDiskType改爲SYNC_FLUSH同步刷盤策略，默認的是ASYNC_FLUSH異步刷盤。一旦同步刷盤返回成功，那麼就一定保證消息已經持久化到磁盤中了；爲了保證磁盤損壞不會丟失數據，我們需要對RocketMQ採用主從機構，集羣部署，Leader中的數據在多個Follower中都存有備份，防止單點故障。
3. 在場景3中，消息到達了消費者，RocketMQ在代碼中就能保證消息不會丟失

//註冊消息監聽器處理消息
consumer.registerMessageListener(new MessageListenerConcurrently() {
   @Override
    public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context){ 		 						                        
        //對消息進行處理
        return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
    }
});

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8

上面這段代碼中，RocketMQ在消費者中註冊了一個監聽器，當消費者獲取到了消息，就會去回調這個監聽器函數，去處理裏面的消息
當你的消息處理完畢之後，纔會返回ConsumeConcurrentlyStatus.CONSUME_SUCCESS
只有返回了CONSUME_SUCCESS，消費者纔會告訴RocketMQ我已經消費完了，此時如果消費者宕機，消息已經處理完了，也就不會丟失消息了
如果消費者還沒有返回CONSUME_SUCCESS時就宕機了，那麼RocketMQ就會認爲你這個消費者節點掛掉了，會自動故障轉移，將消息交給消費者組的其他消費者去消費這個消息，保證消息不會丟失

爲了保證消息不會丟失，在consumeMessage方法中就直接寫消息消費的業務邏輯就可以了，如果非要搞一些騷操作，比如下面的代碼

//註冊消息監聽器處理消息
consumer.registerMessageListener(new MessageListenerConcurrently() {
   @Override
    public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context){ 
    	//開啓子線程異步處理消息
    	new Thread() {
			public void run() {
				//對消息進行處理
			}
		}.start();		 						                        
        return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
    }
});

• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• 10
• 11
• 12
• 13

如果新開子線程異步處理消息的話，就有可能出現消息還沒有被消費完，消費者告訴RocketMQ消息已經被消費了，結果宕機丟失消息的情況。

使用上面一整套的方案就可以在使用RocketMQ時保證消息零丟失，但是性能和吞吐量也將大幅下降

1. 使用事務機制傳輸消息，會比普通的消息傳輸多出很多步驟，耗費性能
2. 同步刷盤相比異步刷盤，一個是存儲在磁盤中，一個存儲在內存中，速度完全不是一個數量級
3. 主從機構的話，需要Leader將數據同步給Follower
4. 消費時無法異步消費，只能等待消費完成再通知RocketMQ消費完成

消息零丟失是一把雙刃劍，要想用好，還是要視具體的業務場景而定，選擇合適的方案纔是最好的