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.复杂业务数据同步场景

复杂业务数据是指生成者须要必定的业务逻辑处理产生的数据。 关于复杂业务数据的同步，考虑到同步失败的场景，须要持久化这类数据。而后按单表数据同步场景进行数据的同步。