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