可靠消息最终一致性方案

4、发送mq成功，修改本地数据状态“已送达”

注意: 1 发送失败，直接失败

消息表

等待消息的再次消费

3.2、发送消息

方案2：上游服务发送mq消息的同时，创建zk监听

是

（针对半状态half 的数据，mq会有一个定时任务去上游服务拿confim还是cancle的状态）重试15次，如果上游服务一直没告知，则默认设置为rollback

Order 下游服务已保存、进行中、成功、失败

RocketMQ

针对  消息发送失败消息发送失败，这里需要有一个定时job，去扫描已确认得消息，进行再次发送mq

失败 rollback

重发

user服务如果是先发消息，再进行本地数据事务处理，那消息服务的状态就是“待确认”，然后等user处理完本地事务之后，再进行第二轮得消息发送，确认消息，修改消息服务的状态，\"已确认\"如果是先处理本地事务，然后再发送消息到消息服务，那消息服务的状态就是 “已确认”

感觉这里还可以进行一个数据的发送，供上游服务订阅，这样上游就能知道你这个数据是成功还是失败，然后更新自己的中间状态、也可以使用zk等

3.1、执行本地的数据存储，这时候可以是待确认或者已确认

执行

本地业务操作

降级方案

通过第二步的成功失败进行mq消息的确认、取消

消息发送失败

可靠消息服务待确认、已确认、已送达、已完成、作废

注意点：1-2，步应该是在同一个方法中的，只有第二步得发送消息成功，user服务的数据库中才会有数据信息。

5、订阅消息

发送mq是否成功

4、消息表保存 、执行下游业务逻辑

本地数据库

job1 ：进行中的数据，可以十分钟后进行再次发送mq数据

业务表

0- 扫描 “ 待确认”的消息，回调上游服务，此消息是作废还是已执行完成1、后台线程扫描“已确认”的数据重新发送：防止mq消息发送失败2、后台线程扫描“已发送”的数据重新发送：防止未收到下游服务的确认

job3 ：根据创建时间扫描一分钟得\"待确认\"得消息，向上游服务确定是作废还是已确认

成功确认消息

User上游服务已保存、进行中、成功、失败

否

RabbitMQ

不同的系统应该设置不同的消费组，如果不同的消费组订阅了同一个Topic，对Topic里的一条消息，每个消费组都会获取到这条消息，但是正常情况下 只会有一个客户端消费

MQ

幂等

9、通知user服务，成功还是失败，下游服务会包装一个json发给消息服务，由消息服务转发{\"id\"\"1\":state:\"成功\"}

方案1：上游服务提供接口，推送成功失败

1、发送half事务消息

2、发送消息到消息服务

8、通知消息服务，下游执行完成

1、消息队列收到 “half”的消息状态，半状态（针对半状态的数据，mq会有一个定时任务去上游服务拿confim还是cancle的状态）重试15次，如果上游服务一直没告知，则默认设置位rollback2、拿到确认消息后、推送数据到下游服务3、下游服务拿到数据后，进行数据的消费，3.1 如果失败，则可以加入到重试队列中，默认重试16 还是 18，如果都失败，这时候进行到死信队列，可以对这个队列进行订阅后处理3.3 如果成功，则发送ack的确认消息，mq中的数据消费掉4、如果下游好几个服务，因为某一个服务发生了异常，解决方案：a、你的模块接收到数据出现的问题，那就需要你自行处理b、进行全流程的数据消息回滚

1、执行本地事务

job2 ：扫描\"已送达\"消息超时十分钟，重发MQ

3、发送MQ的消息 确认3、发送MQ的消息 取消

推荐

1、先执行业务逻辑（如果是这样，需要一个消息确认的接口）

2、执行数据库操作

失败 rollback等待消息的再次消费

job1 ：扫描\"已确认\"消息超时十分钟，重发MQ

6、消息保存消息表，数据入库保证幂等7、进行业务操作，成功：则ACK确认MQ消息失败：回滚消息表和业务表得事务