1 背景

在金融系統中MQ消息的消息丟失是不允許的，消息的丟失會導致支付狀態訂單狀態出現混亂。接下來聊一下如何保證MQ消息不丟失,以筆者公司使用的RocketMQ為例。

2 RokectMQ消息什么情況下會丟失？

MQ的消息生成到消費主要經歷三個階段：MQ消息生產、RocketMQ Broker存儲消息、消費者消息對應的消息。如下圖：

從上圖可以知道消息丟失主要會發生在下面幾個地方：

消息生產者將消息發送到RocketMQ Broker的這個過程可能出現消息丟失。
RocketMQ Broker接收到生產者發送的消息存儲的過程消息可能丟失。
消費者處理失敗，但是將錯誤進行捕捉，導致消息出現虛假的消費成功。實際上沒有消費，但是在MQ看來消費完成了消費。

3 如何解決RokectMQ消息丟失

解決消息丟失從消息丟失的地方入手。

3.1 消息生產防止消息丟失

RocketMQ消息生產方式有三種：同步發送消息、異步發送消息、One-Way發送消息。不同的發送方式使用不同的場景：

同步發送消息： 重要的通知(訂單狀態的更新)、短信系統。

異步發送消息： 通常用于響應時間敏感的業務場景。

One-way： 主要用于對可靠性要求不高的場景，在金融的場景下不適用。一般是用于日志收集。

根據上面三種發送方式的特點， one-way 消息發送模式本身就是對消息的丟失無法保證。所以如果你的系統對消息丟失零容忍不能使用 one-way 的方式發送。同步發送消息和異步發送消息 都可以判斷消息的發送狀態判斷消息是否已經發送到Broker。這里是選擇同步發送還是異步發送消息看業務的需要，同步發送比較關心發送后返回的結果對時間的要求不是那么敏感。異步發送對消息返回時間敏感。

SendResult定義說明(來自RocketMQ官方)

SEND_OK
消息發送成功。要注意的是消息發送成功也不意味著它是可靠的。要確保不會丟失任何消息，還應啟用同步Master服務器或同步刷盤，即SYNC_MASTER或SYNC_FLUSH。
FLUSH_DISK_TIMEOUT
消息發送成功但是服務器刷盤超時。此時消息已經進入服務器隊列（內存），只有服務器宕機，消息才會丟失。消息存儲配置參數中可以設置刷盤方式和同步刷盤時間長度，如果Broker服務器設置了刷盤方式為同步刷盤，即FlushDiskType=SYNC_FLUSH（默認為異步刷盤方式），當Broker服務器未在同步刷盤時間內（默認為5s）完成刷盤，則將返回該狀態——刷盤超時。
FLUSH_SLAVE_TIMEOUT
消息發送成功，但是服務器同步到Slave時超時。此時消息已經進入服務器隊列，只有服務器宕機，消息才會丟失。如果Broker服務器的角色是同步Master，即SYNC_MASTER（默認是異步Master即ASYNC_MASTER），并且從Broker服務器未在同步刷盤時間（默認為5秒）內完成與主服務器的同步，則將返回該狀態——數據同步到Slave服務器超時。
SLAVE_NOT_AVAILABLE
消息發送成功，但是此時Slave不可用。如果Broker服務器的角色是同步Master，即SYNC_MASTER（默認是異步Master服務器即ASYNC_MASTER），但沒有配置slave Broker服務器，則將返回該狀態——無Slave服務器可用。

3.2 RocketMQ Broker防丟失消息

首先了解一下Broker集群部署模式(官方方案)。

單Master模式

這種方式風險較大，一旦Broker重啟或者宕機時，會導致整個服務不可用。不建議線上環境使用,可以用于本地測試。

多Master模式

一個集群無Slave，全是Master，例如2個Master或者3個Master，這種模式的優缺點如下

優點：配置簡單，單個Master宕機或重啟維護對應用無影響，在磁盤配置為RAID10時，即使機器宕機不可恢復情況下，由于RAID10磁盤非常可靠，消息也不會丟（異步刷盤丟失少量消息，同步刷盤一條不丟），性能最高；
缺點：單臺機器宕機期間，這臺機器尚未被消費的消息在機器恢復之前不可訂閱，消息實時性會受到影響。

多Master多Slave模式-異步復制

每個Master配置一個Slave，有多對Master-Slave，HA采用異步復制方式，主備有短暫消息延遲（毫秒級），這種模式的優缺點如下

優點：即使磁盤損壞，消息丟失的非常少，且消息實時性不會受影響，同時Master宕機后，消費者仍然可以從Slave消費，而且此過程對應用透明，不需要人工干預，性能同多Master模式幾乎一樣；
缺點：Master宕機，磁盤損壞情況下會丟失少量消息(非同步刷盤的情況下)

多Master多Slave模式-同步雙寫

每個Master配置一個Slave，有多對Master-Slave，HA采用同步雙寫方式，即只有主備都寫成功，才向應用返回成功，這種模式的優缺點如下：

優點：數據與服務都無單點故障，Master宕機情況下，消息無延遲，服務可用性與數據可用性都非常高；
缺點：性能比異步復制模式略低（大約低10%左右），發送單個消息的RT會略高，且目前版本在主節點宕機后，備機不能自動切換為主機

如果是想不存在消息丟失的情況，那么在多Master的情況下要配置消息同步刷盤，而在 多Master多Slave模式-同步雙寫 的情況下配置同步刷盤。

3.3 消費端處理消息

消息消費示例代碼如下：

public class Consumer {

    public static void main(String[] args) throws InterruptedException, MQClientException {

        // Instantiate with specified consumer group name.
        DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("please_rename_unique_group_name");
         
        // Specify name server addresses.
        consumer.setNamesrvAddr("localhost:9876");
        
        // Subscribe one more more topics to consume.
        consumer.subscribe("TopicTest", "*");
        // Register callback to execute on arrival of messages fetched from brokers.
        consumer.registerMessageListener(new MessageListenerConcurrently() {

            @Override
            public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs,
                ConsumeConcurrentlyContext context) {
                //處理消息
                System.out.printf("%s Receive New Messages: %s %n", Thread.currentThread().getName(), msgs);
                return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
            }
        });

        //Launch the consumer instance.
        consumer.start();

        System.out.printf("Consumer Started.%n");
    }
}

在處理消息的時候，如果消息處理失敗返回的狀態不應該是
ConsumeConcurrentlyStatus.CONSUME_SUCCESS 。如果消息處理失敗返回的是
ConsumeConcurrentlyStatus.CONSUME_SUCCESS 消息就不能再次被消息。在Broker看來就是已經消費完成。