今儿是越写越快乐的第二篇文章，我来为大家说说工作上的那些事儿，主要是基于Spring Cloud构建的下的分布式事务的技术选型。
分布式事务介绍
分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。分布式是相对于集中式而言的，现在非常流畅的区块链技术则是建立在去中心化(分布式)网络、P2P和密码学的技术集合，回到我们分布式事务的话题而言，对于一个业务系统而言，有多个子模块需要进行数据一致性的需求，那么保证多个操作的最终一致性才是实现分布式事务的核心目标之一。
分布式事务相关概念
刚性事务
刚性事务是指严格遵循ACID原则的事务, 例如单机环境下的数据库事务。
柔性事务
柔性事务是指遵循BASE理论的事务，通常用在分布式环境中, 常见的实现方式有: 两阶段提交(2PC)、 TCC补偿型提交、基于消息的异步确保型和最大努力通知型。
事务补偿机制
在事务链中的任何一个正向事务操作, 都必须存在一个完全符合回滚规则的可逆事务。
CAP理论
BASE理论
BASE(Basically Avaliable, Soft State, Eventually Consistent)是分布式事务实现的一种理论标准。
常见分布式事务实现方式
两阶段提交(2PC)事务
两阶段提交(Two Phase Commit - 2PC), 具有强一致性, 是CP系统的一种典型实现。该事务分为准备阶段和执行阶段，通过事务协调器和资源管理器来保证事务在执行的过程中的最终数据的一致性。
它有以下缺点：
- 在事务的第二阶段，协调者需要等待所有参与者发出YES请求, 或者一个参与者发出NO请求后, 才能执行提交或者中断操作. 这会造成长时间同时锁住多个资源, 造成性能瓶颈, 如果参与者有一个耗时长的操作, 性能损耗会更明显。
- 实现复杂, 不利于系统的扩展。
TCC补偿事务
TCC是基于补偿型事务的AP系统的一种实现, 具有最终一致性。它分为Try 、 Confirm和Cancel三个阶段。在不同的阶段执行如下操作：
- Try 阶段主要是对业务系统做检测及资源预留。
- Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行Confirm阶段时，默认 Confirm阶段是不会出错的。
- Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。
最大努力通知型事务
这是分布式事务中要求最低的一种, 也可以通过消息中间件实现, 与前面异步确保型操作不同的一点是, 在消息由MQ Server投递到消费者之后, 允许在达到最大重试次数之后正常结束事务。
可用的开源实现
ByteTCC
ByteTCC是一个兼容JTA规范的基于TCC机制的分布式事务管理器。
Hmily
Hmily是一个支持Dubbo和Spring Cloud的分布式事务框架。它基于Java语言构建，并有以下特点：
- 采用disruptor框架进行事务日志的异步读写，与RPC框架的性能毫无差别；
- 支持springboot-starter项目启动，使用简单；
- 采用Aspect AOP 切面思想与Spring无缝集成，天然支持集群；
- 支持本地事务存储；
结论
基于以上有关分布式事务的梳理和分析，我们知道要实现一个系统的分布式事务是一项复杂的工程。只有通过不断实践和业务迭代才会找出适合自己的业务架构和服务于业务的技术选型。目前采取的方面是TCC事务模式来构建我们的业务系统。当然接下来还需要继续验证开源实现的可行性以及将开源实现整合到现有的项目中，通过Spring Cloud的微服务架构来升级和优化业务系统，服务于更多的用户，带给用户更大的价值。若是我的文章对你有所启发，那将是我莫大的荣幸。
