目前比较流行的分布式事务解决方案可分为两类： XA协议
1、两阶段提交（2PC Two Phase Commit）
* 两阶段提交，是实现分布式事务的成熟方案。
第一阶段表决阶段(prepare)：是所有参与者都将本事务能否成功的反馈发送给协调者；
第二阶段执行阶段(commit)：协同者根据所有参与者的反馈，通知所有参与者，一致地在所有分支上提交或者回滚；
* 缺点：
1、数据库需要频繁地对资源上锁；
2、资源被锁住的时间相对比较长些；
（第一阶段上锁，第二阶段才能解锁）
* 一个完整的事务生命周期是：begin -> 业务逻辑 -> prepare -> commit。
2、TCC
* Try、Confirm、Cancel）是两阶段提交的一种变种。
* TCC提供了一个框架，需要应用程序按照该框架编程，将业务逻辑的每个分支都分别为Try、Confirm、Cancel三个操作集。
* TCC让应用程序自己定义数据库操作的粒度，使得降低锁冲突、提高吞吐量成为可能。
例子：按照TCC框架，应用需要在Try阶段将商品的库存减去，将买家支付宝账户中的相应金额扣掉，在临时表中记录下商品的数量，订单的金额等信息；
另外再编写Confirm的逻辑，即在临时表中删除相关记录，生成订单，告知CRM、物流等系统，等等；以及Cancel逻辑，
即恢复库存和买家账户金额，删除临时表相关记录。
* 使用TCC机制时————以提交为例————一个完整的事务生命周期是：begin -> 业务逻辑(try业务) -> commit(comfirm业务)。
高性能的分布式事务框架(txlcn)
介绍
- LCN Lock 锁定事务单元 Confirm 确认事务模块状态 Notify 通知事务
- LCN并不生产事务，LCN只是本地事务的协调工
- TX-LCN定位于一款事务协调性框架，框架其本身并不操作事务，而是基于对事务的协调从而达到事务一致性的效果。
总体框架
解决方案
在一个分布式系统下存在多个模块协调来完成一次业务。那么就存在一次业务事务下可能横跨多种数据源节点的可能。TX-LCN将可以解决这样的问题。
例如存在服务模块A 、B、 C。A模块是mysql作为数据源的服务，B模块是基于redis作为数据源的服务，C模块是基于mongo作为数据源的服务。
若需要解决他们的事务一致性就需要针对不同的节点采用不同的方案，并且统一协调完成分布式事务的处理。
方案：
若采用TX-LCN分布式事务框架，则可以将A模块采用LCN模式、B/C采用TCC模式就能完美解决。
