微服务的搭建
微服务中我们把业务的能力进行了抽象，实际的业务中我们需要用到不同的服务的能力，并且我们处理的业务需要事务的一致性，避免出现数据的紊乱，那么我们就需要对分布式的微服务进行一致性事务的处理。下面是我自己总结的几种方案。
分布式事务解决的方案
一、（XA）两阶段方案
1、先提交每一个（这个是加锁）
2、确认资源，确认每一个RM是否都成功了，判断是否要提交还是要回滚
二、TCC（try-confirm-cancle）两阶段补偿性方案
1、先提交状态为中间状态（数据表更改为更新中，而不是加锁）
2、确认资源，确认每一个RM是否都成功了，都成功了，更新sql的状态，否则回滚
TCC相比于XA的优点
1、TCC是更新数据为中间状态，而两阶段方案是加锁
2、TCC能够对分布式事务中的各个资源进行分别锁定，分别提交与释放，例如，假设有AB 两个操作，假设A操作耗时短，那么A就能较快的完成自身的try-confirm-cancel流程，释 放资源，无需等待B操作。如果事后出现问题, 追加执行补偿性事务即可
3、TCC是绑定在各个子业务上的(除了cancle中的全局回滚操作)，也就是各服务之间可以 在一定程度上”异步并行”执行
适用的场景：
1、严格一致性
2、执行时间短
3、实时性要求高
三、异步确认性
通过将一系列同步的事务操作变为基于消息执行异步操作，避免了分布式事务中的同步阻塞 操作的影响。
需要额外说明的一点，就是事务消息投递到MQ定阅方后，并不一定能够成功执行。
需要 MQ订阅方主动给予消费反馈（ack）:
1、如果MQ订阅方执行远程事务成功，则给予消费成功的ACK,那么MQ server可以将事务 消息移除；
2、如果执行失败，MQ Server需要对消息重新投递，直至消费成功。
注意事项
1、消息中间件在系统中扮演一个重要的角色，所有的事务消息都需要通过它来传达，所以 消息中间件也需要支持 HAC 来确保事务消息不丢失。
2、根据业务逻辑的具体实现不同，还可能需要对消息中间件增加消息不重复，不乱序等其 它要求。
适用场景
1、执行周期较长
2、实时行要求不高
例如
1、跨行转账/汇款业务（两个服务分别在不同的银行中）
2、退货/退款业务
3、财务，账单统计业务（先发送到消息中间件，然后进行批量记账）
四、最大努力通知型
这是分布式事务中要求最低的一种，也可以通过消息中间件实现，与前面异步确保型操作不 同的一点是，在消息由MQ Server投递到消费者之后，允许在达到最大重试次数之后正常 结束事务。
适用场景
交易结果消息的通知等。