因为最近项目正在做重构，而这次重构实质上比原来更接近于SOA化和微服务的思想。对于我们金融交易来说，数据结果的准确性是重中之重。所以今天总结一下分布式事务的实现方法，下次组内周会给大家统一一下概念。
刚性事务和柔性事务
刚性事务：严格遵循ACID原则（原子性、一致性、隔离性、持久性）的事务。基本上指的是本地数据库事务。根据CAP原则，分布式下的事务都不是刚性事务。
柔性事务：遵循CAP理论或者其变种BASE理论的事务。分布式事务基本上都是柔性事务。
因为刚性事务基本上等价于本地数据库事务，而柔性事务基本上等价于分布式事务。只是一个是按照事务严格性来区分，一个是按使用场景来区分。所以平时除了用来做对比，很少直接提刚性事务和柔性事务的概念。
分布式事务理论
分布式事务：在分布式环境下，各个操作步骤并不在同一台机器上，需要保证所有动作都有一个统一的结果的一组操作。
CAP原则（记得在之前的博客中多次写过）：分布式环境下，数据一致性、服务可用性、分区容错性三者最多只能满足其中二者。
数据一致性（consistency）:这里的一致性是强一致性，又叫线性一致性。即一个写操作成功，而读出的必须是写操作后的新数据。而写操作失败读出的必须是写操作前的旧数据。
服务可用性（availability）:所有的操作在一定时间内都能得到响应。
分区容错性（partition-tolerance）:在网络分区环境下，被分割的节点仍然能对外提供服务。
| 选 择 | 说 明 |
| AP | 分隔的节点同时对外服务但不能相互通信，将导致状态不一致，即不能满足C |
| CP | 网络分区的情况下为达成C，请求只能一直等待，即不满足A |
| CA | 在一定时间内要达到节点状态一致，要求不能出现网络分区，则不能满足P |
BASE理论：这是基于CAP理论权衡之后的结果。核心思想是即使无法做到强一致性，但可以使用一些技术手段达到最终一致。BASE是Basically Available(基本可用)、Soft state(软状态)、Eventually consistent(最终一致性)的缩写。
分布式事务一致性实现方案
为了解决分布式一致性问题，前人在性能和数据一致性的权衡过程中总结了许多经典的协议和算法。比较著名的有：2PC、3PC、TCC、Paxos、Raft、Zab、ISR。除了这些之外，业界用的最多的其实是基于MQ实现的。
2PC（Two Phase Commit）两阶段提交:一般说的两阶段提交是基于XA协议的。另外JTA协议的也比较常见。
XA是一个分布式事务协议。它大致分为两部分：事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现，比如Oracle、DB2都实现了XA接口。MySQL对XA的支持不是很好。而事务管理器作为全局的调度者，负责各个本地资源的提交和回滚。
两阶段提交的优点是：原理简单、实现方便。缺点是同步阻塞、单点问题、数据不一致。
3PC(Three Phrase Commit)三阶段提交：分为CanCommit、PreCommit、Do Commit 三个阶段。就是把两阶段提交的Phase 1分成两个，预提交的时候如果有参与者返回No或者超时则中断事务。
三阶段提交的优点是降低参与者阻塞范围，并能够在出现单点故障后继续达成一致。缺点是因为preCommit阶段，在这个阶段如果出现网络分区，协调者无法与参与者正常通信，参与者仍然会进行实物提交，造成数据不一致。
TCC(Try-Confirm-Cancel)
Try:完成所有的检查，预留必须资源
Confirm:使用Try阶段预留的资源执行业务，如果执行出现异常，要重试
Cancel:释放Try阶段预留资源
TCC能够对分布式事务中的各个资源进行分别锁定，分别提交与释放。适用于严格一致、执行时间短、实时性要求高的场景。
Paxos算法：之前看过《从Paxos到Zookeeper》那本书，没怎么看明白。实现比较复杂，Zookeeper就是用这个来实现的分布式一致性。Paxos算法、Raft协议和Zab（Zookeeper Atomic Broadcast）协议都是一种通过多数投票来保证主备数据一致性的。
ISR（In-Sync Replicas）机制：Kafka使用了这个机制来保证数据一致性。ISR认为对于2f+1个副本来说，多数投票机制要求最多只能允许f个副本发生故障，如果要支持2个副本的容错，则需要至少维持5个副本。
基本MQ实现是一种异步确保型的实现方案。将同步阻塞的事务变成异步的，避免了对数据库事务的争用。
