可靠消息最终一致性方案
对于常见的微服务系统，大部分接口调用是同步的，也就是一个服务直接调用另外一个服务的接口。这时候，用TCC分布式事务方案来保证各个接口的调用，要么一起成功，要么一起失败，是比较合适的。
但是在实际系统的开发过程中，可能服务间的调用是异步的，一个服务发送消息给MQ，另一个服务从MQ消费到消息后进行处理。如果希望基于MQ实现异步调用的多个服务的业务逻辑，要么一起成功，要么一起失败，这时候就需要用可靠消息最终一致性方案，来实现分布式事务。
1.上游服务投递消息
上游服务西药发送一条消息给可靠消息服务，可以认为是对下游服务一个接口的调用，里面包含了对应的一些请求参数。然后可靠消息服务就把这条消息存储到自己的数据库里，状态为“待确认”；
接着上游服务执行自己本地的数据库操作，根据自己的执行结果，再次调用可靠消息服务的接口。如果本地数据库操作执行成功了，那么就找可靠消息服务确认那条消息；如果失败，则删除那条消息；
此时如果是确认消息，那么可靠消息服务就把数据库里的消息状态更新为“已发送”，同事将消息发送给MQ。
注意：更新数据库里的消息状态和投递消息到MQ，这两步操作必须放在一个方法里，而且开启本地事务。这两操作必须同时成功，或同时失败。
2.下游服务接收消息
下游服务消费到了消息，那么就操作自己本地数据库。如果操作成功了，就反过来通知可靠消息服务，可靠消息服务就会把消息的状态设置为“已完成”。
3.如何保证上游服务对消息的100%可靠投递
如果上游服务给可靠消息服务发送待确认消息的过程出错，上游服务会感知到调用异常，就不用执行下面的流程了，这种没有问题；
如果上游服务操作完本地数据库之后，通知可靠消息服务确认消息或删除消息的时候出现问题，比如没通知成功，或者没执行成功，或者可靠消息服务没成功的投递消息到MQ，这种情况下，可以在可靠消息服务中开发一个后台定时运行的线程，不停的检查各个消息的状态。
定时任务检测到消息一直是“待确认”状态的话，就会取检查上游服务是否执行成功，如果执行成功了，就修改消息状态为“已发送”，否则删除消息即可。
通过这套机制，就可以保证，可靠消息服务一定会尝试完成消息到MQ的投递。
4.如何保证下游服务对消息的100%可靠接收
如果下游服务消费消息出现问题，没消费到，或者是对消息的处理失败，也可以在可靠消息服务中开发一个后台定时运行的线程，不断的检查消息状态。
如果消息状态一直是“已发送”，始终没变成“已完成”，就说明下游服务始终没有处理成功，此时可靠消息服务就可以再次尝试重新投递消息到MQ，让下游服务来再次处理。
只要下游服务的接口逻辑实现幂等性 ，保证多次处理一个消息，不会插入重复数据即可。
5.如何基于MQ来实现可靠消息最终一致性方案
在上面的通用方案设计里，完全依赖可靠消息服务的各种自检机制来确保：
如果上游服务的数据库操作没成功，下游服务就不会收到任何通知；
如果上游服务的数据库操作成功了，可靠消息服务一定会确保将一个调用消息投递给下游服务，而且一定会确保下游服务成功处理这条消息。
通过这套机制，保证了基于MQ的异步调用/通知的服务间的分布式事务保障。
MQ都实现了可靠消息服务的功能！！！