数据一致性解决方案

Consistency，Availability和Partition Tolerance（ CAP定理）：分区、一致性、可用性，三者不能同时满足。所以退而求其次，达到最终一致性，而不是实时一致性。

1、定时同步。可以是增量的，按照时间来。

2、用消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列，再通过业务规则自动或人工发起重试。消息日志方案的核心是保证服务接口的幂等性。

3、如何保证幂等：

查询：天然的幂等

insert：唯一索引

update：带上条件，比如乐观锁：读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

delete：第一次delete成功，后来的请求直接返回成功

4、消息通知往往不能保证 100% 成功；且消息通知后，接收方业务是否能执行成功还是未知数。前者问题可以通过重试解决；后者可以选用事务消息来保证。

5、RocketMQ 采用了事物消息。

具体来说，就是把消息的发送分成了2个阶段：Prepare阶段和确认阶段。

具体来说，上面的2个步骤，被分解成3个步骤： 
(1) 发送Prepared消息 
(2) update DB 
(3) 根据update DB结果成功或失败，Confirm或者取消Prepared消息。

可能有人会问了，前2步执行成功了，最后1步失败了怎么办？这里就涉及到了RocketMQ的关键点：RocketMQ会定期（默认是1分钟）扫描所有的Prepared消息，询问发送方，到底是要确认这条消息发出去？还是取消此条消息？

6、那么消费端执行失败怎么办？人工服务。