1.概述

我們知道在使用RabbitMQ時，生產者將訊息釋出出去之後，訊息是否順利到達broker代理伺服器呢？預設情況下發布操作沒有任何資訊返回給生產者，也就是生產者是不知道訊息有沒有順利到達broker。如果在訊息到達broker之前已經丟失了，那釋出的訊息就更不會到達佇列並被消費者消費。如果出現上述情況，就會造成生產者釋出的訊息與消費者消費的訊息不一致的問題。

2.RabbitMQ自帶的解決方案

RabbitMQ提供以下兩種方式解決上述問題。

2.1事務機制

事務機制能夠解決生產者與broker之間訊息確認的問題，只有訊息成功被broker接受，事務才能提交成功，否則就進行事務回滾操作並進行訊息重發。但是使用事務機制會降低RabbitMQ的訊息吞吐量，不適用於需要釋出大量訊息的業務場景。

2.2訊息確認機制

生產者將通道設定成confirm模式，一旦通道進入confirm模式，所有在該通道上面釋出的訊息都會被指派一個唯一的ID(從1開始)，一旦訊息被投遞到所有匹配的佇列之後，broker就會發送一個確認給生產者（包含訊息的唯一ID），這就使得生產者知道訊息已經正確到達目的隊列了。
與事務機制相比較，確認機制採用非同步回撥方式來處理確認訊息，效能得到了較大的提升，可以確保資料同步的一致性。

3.新的解決方案

為了最大限度的提升MQ資料同步的效能，自己制定了一個更好的解決方案，現分享如下。
解決方案：MQ+Redis+介面。
MQ：作為訊息佇列中介軟體負責同步資料；
Redis：負責儲存每天（或每批次等）生產者已傳送資料的唯一標識，即全量儲存已傳送資料唯一標識，方便消費者檢查並同步失敗資料；
介面：作為補償措施，用於消費者獲取同步失敗的資料。

下面分兩個使用場景說明。

4.單表資料同步場景

(1)生產者傳送資料至MQ Server，同時記錄已傳送資料的唯一標識（如id），每同步一批次（比如N條）後，再把該批次的唯一標識存入Redis。
(2)儲存唯一標識的key及過期時間，需要根據資料的同步策略具體制定。比如：若每天同步一次資料，就可以以“佇列名稱+日期”為key，把這一天所有生產者已傳送資料的唯一標識存入同一個list中。
(3)消費者消費資料後，負責檢查已消費資料唯一標識與Redis中唯一標識是否有差異，若存在差異，則說明有資料同步失敗。
(4)對於同步失敗資料，消費者呼叫生產者提供的介面實時獲取。介面以唯一標識為入參，並控制每次請求的資料量，比如每次最多同步200條等。

5.複雜業務資料同步場景

複雜業務資料是指生成者需要一定的業務邏輯處理產生的資料。
關於複雜業務資料的同步，考慮到同步失敗的場景，需要持久化這類資料。然後按單表資料同步場景進行資料的同步。