类似TCC事务的落地的一些东西，技术选型，业务场景需要分布式事务，结合我个人亲身经历的一个创业公司APP的一个事故，给大家介绍了一下，对于系统核心链路，为什么必须要上分布式事务
seata，github上，都会提供sample，跟dubbo，官方的同学是定义为double，spring cloud，seata都提供了sample，知道如何把分布式事务框架整合到框架里去了
核心交易链路，分布式事务框架
有些服务之间的调用是走异步的，下成功了订单之后，你会通知一个wms服务去发货，这个过程可以是异步的，可以是走一个MQ的，发送一个消息到MQ里去，由wms服务去从MQ里消费消息
MQ，消息中间件，面试突击第一季，刚开头我就讲过消息中间件的面试连环炮
可靠消息最终一致性方案，参考面试突击第一季
落地，RocketMQ来实现可靠消息最终一致性事务方案
Producer向RocketMQ发送一个half message
RocketMQ返回一个half message success的响应给Producer，这个时候就形成了一个half message了，此时这个message是不能被消费的
注意，这个步骤可能会因为网络等原因失败，可能你没收到RocketMQ返回的响应，那么就需要重试发送half message，直到一个half message成功建立为止
接着Producer本地执行数据库操作
Producer根据本地数据库操作的结果发送commit/rollback给RocketMQ，如果本地数据库执行成功，那么就发送一个commit给RocketMQ，让他把消息变为可以被消费的；如果本地数据库执行失败，那么就发送一个rollback给RocketMQ，废弃之前的message
注意，这个步骤可能失败，就是Producer可能因为网络原因没成功发送commit/rollback给RocketMQ，此时RocketMQ自己过一段时间发现一直没收到message的commit/rollback，就回调你服务提供的一个接口
此时在这个接口里，你需要自己去检查之前执行的本地数据库操作是否成功了，然后返回commit/rollback给RocketMQ
只要message被commit了，此时下游的服务就可以消费到这个消息，此时还需要结合ack机制，下游消费必须是消费成功了返回ack给RocketMQ，才可以认为是成功了，否则一旦失败没有ack，则必须让RocketMQ重新投递message给其他consumer