分布式事务—MQ最终一致性模型（无独立消息系统）

参考：https://blog.csdn.net/shanchahua123456/article/details/84781638

幂等性，有序性，补偿性，可查性，消息持久化

保证同种服务集群读写同一个数据库/数据库中间件，这样即使是集群服务，也可以正常确认，因为同种服务集群共用相同的数据。

最终一致性：一旦发起，要求100%投递，保证最终各个库一定一致。可以没有回滚措施。

发送方：本地事务提交成功(本地业务表+本地消息表)。投递MQ（下游多个业务可以用广播）、提供状态查询API。

              本地消息表：消息ID，状态，消费方路由(可能多个)，消息体等信息，消息完成持久化。

消费方：幂等消费信息，回写发送方消息状态，提供查询API。

补偿方：提取发送方本地消息表中超时消息，根据表中消费方路由并重发MQ。

回滚(可选)：回滚推荐用MQ广播机制，将回滚的消息ID广播到所有分布式服务中，各个服务通过消息ID找到原请求数据，各自实现业务回滚。通过补偿机制保证最终一致性。这里推荐使用广播，是因为可能有多个服务需要回滚，广播模式回滚发起方只需要发送一条消息，保证发送消息的原子性。

 

流程：

1 上游程序/数据库（生产者）：

1.1 本地事务  【生成唯一ID——》执行业务流程  ——》  本地保存消息数据（db_queue 表） ——》发送到MQ】 

本地db_queue 表：消息ID，相关单据编号，路由键(目标MQ-QUEUE,可能有多个)，内容Json，时间，状态。

MQ采用confirm方式发送，会有异步的返回结果。根据返回结果，然后更新db_queue表里的消息状态"已发"。

本地事务中任意异常都会回滚，但小概率出现 MQ发送成功，但是本地事务未提交。所以下游消费时，要确认上游业务已完成。若是简单的数据传输/同步则不需要确认，因为上游无数据，下游也不会拉取到数据。

1.2 确认接口（幂等）：回写业务表状态，删除db_queue 表。 （成功/失败）   

      下游服务消费出现逻辑失败。比如库存不足，金额不足等。此时生产者要视情况手动实现业务回滚逻辑 。若调用了多个下游服务，则可能还要通过MQ通知其他下游服务执行回滚逻辑。        

1.3 查询接口：状态业务表、db_queue 表查询等。满足恢复功能和下游服务的查询功能。

2 消息恢复功能（定时任务）：(注意幂等性设计)  

本服务主要做的是定时补偿工作。

2.1查询db_queue 表，上游程序超时未发送，通过表中路由键重发；

2.2查询db_queue 表，上游程序超时未确认数据，调用下游消费者查询接口，若下游已消费则调用上游确认接口，若下游未消费则重发。

3 下游程序/数据库（消费者）：(注意幂等性设计)  

监听MQ队列：调用对应消费服务

3.1 根据业务判断是否需要查询上游业务已完成，避免无效重试。（数据传输不需要）

3.2 本地事务  【 幂等执行业务流程  ——》 用上游接口，确认上游业务数据 】 

           3.3 注意MQ的可靠消费，手动ACK，限制收取量

           3.4 数据库幂等设计可以依靠：主键/唯一索引/update+条件/先查再写(高并发一定概率有问题)

           3.5 查询接口：查询消费状态。

推荐参考文章：RabbitMQ消息可靠性投递解决方案 

https://blog.csdn.net/shanchahua123456/article/details/86188705