分布式事务的实现方案

 一，柔性事务

互联网分布式高并发场景，传统单机事务在数据库性能和处理能力上都出现瓶颈，因而有人就基于分布式CAP （一致性、可用性、分区容忍性）和BASE （基本可用（Basically Available）、柔性状态（Soft State）、最终一致性（Eventual Consistency），BASE理论是大型分布式系统场景下的设计思想，经过强一致性保证最终一致性来得到高可用性）理论提出了“柔性事务”的概念。

 与传统单机事务严格遵照ACID原则不一样，柔性事务遵照BASE理论，一般用在分布式环境下，常见的实现方式有：两阶段提交（2PC）、TCC补偿性提交，基于消息的异步确保型，最大努力通知型。

一、2PC两阶段提交

 2PC两阶段提交，有强一致性，是CP的典型实现。常见的标准有XA、JTA等。

缺点：协调者要等待全部参与者发出yes或至少一个发出no请后才能执行提交或中断操做，可能会形成长时间锁住多个只有，形成性能瓶颈，致使系统可用性很低。实现复杂，不利于扩展， 通常不多使用。

二、TCC补偿性提交

TCC（Try-Confirm-Cancle）是基于补偿型事务的一种实现，具备最终一致性，是AP的实现。

 特色：TCC能对分布式事务中各个资源进行分别锁定，分别提交与释放，若是过后出现问题，追加执行补偿性事务便可。要注意事务管理器节点要以带同步复制语义的高可用集群（HAC）方式部署，并使用多数派算法避免集群发生脑裂问题。

 使用场景：实时性、一致性要求高，须要获取远程执行结果决定逻辑业务走向，如红包业务等。

三、异步确保型

异步确保型是将同步事务操做变为基于消息执行的异步操做，经过异步信息和补偿性事务实现了服务的解耦，避免了分布式事务中的同步阻塞操做的影响。

特色：本地发送事务消息到MQ并收到MQ确认后就执行commit操做，事务执行失败，则MQ丢弃该消息，事务执行成功则MQ容许并保证消息订阅方消费本条事务消息（订阅方消费成功MQ将事务消息删除，不然尝试直到消费成功）。 此方案要求MQ支持HAC来确保事务消息不丢失。实际实现时可根据具体业务场景，先将事务消息在本地落地执行事务操做后再将消息发送到MQ，并保证本地休息到MQ，再从MQ到订阅方过程消息不丢失（要有确认操做，失败重试）。

使用场景： 实时性要求不高，主业务逻辑无需外部数据变动协助来完成的最终一致性事务，如跨行转帐汇款，退货、退款业务等。

四、最大努力通知型

最大努力通知型和前面异步确保型相似，也是基于异步消息执行，只是在消息从MQ到订阅者时，容许在达到最大重试次数以后正常结束事务。

使用场景：对一致性要求不高，如交易结果消息通知等。 

 2、最佳实践

• 若是业务场景须要强一致性, 那么尽可能避免将它们放在不一样服务中, 也就是尽可能使用本地事务, 避免使用强一致性的分布式事务.
• 若是业务场景可以接受最终一致性, 那么最好是使用基于消息的最终一致性的方案(异步确保型)来解决.
• 若是业务场景须要强一致性, 而且只可以进行分布式服务部署, 那么最好是使用TCC方案而不是2PC方案来解决.

https://github.com/QNJR-GROUP/EasyTransaction 

http://blog.csdn.net/congyihao/article/details/70195154