RabbitMQ數據同步一致性解決方案

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.複雜業務數據同步場景

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