分布式事务的实现方案

 一，柔性事务

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

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

1、2PC两阶段提交

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

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

2、TCC补偿性提交

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

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

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

3、异步确保型

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

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

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

4、最大努力通知型

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

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

 二、最佳实践

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

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

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