ShardingSphere 4.x 分布式事务

背景

数据库事务须要知足ACID（原子性、一致性、隔离性、持久性）四个特性。

• 原子性（Atomicity）指事务做为总体来执行，要么所有执行，要么全不执行。
• 一致性（Consistency）指事务应确保数据从一个一致的状态转变为另外一个一致的状态。
• 隔离性（Isolation）指多个事务并发执行时，一个事务的执行不该影响其余事务的执行。
• 持久性（Durability）指已提交的事务修改数据会被持久保存。

在单一数据节点中，事务仅限于对单一数据库资源的访问控制，称之为本地事务。几乎全部的成熟的关系型数据库都提供了对本地事务的原生支持。
可是在基于微服务的分布式应用环境下，愈来愈多的应用场景要求对多个服务的访问及其相对应的多个数据库资源能归入到同一个事务当中，分布式事务应运而生。

关系型数据库虽然对本地事务提供了完美的ACID原生支持。
但在分布式的场景下，它却成为系统性能的桎梏。如何让数据库在分布式场景下知足ACID的特性或找寻相应的替代方案，是分布式事务的重点工做。

本地事务

在不开启任何分布式事务管理器的前提下，让每一个数据节点各自管理本身的事务。
它们之间没有协调以及通讯的能力，也并不互相知晓其余数据节点事务的成功与否。
本地事务在性能方面无任何损耗，但在强一致性以及最终一致性方面则力不从心。

两阶段提交

XA协议最先的分布式事务模型是由X/Open国际联盟提出的X/Open Distributed Transaction Processing（DTP）模型，简称XA协议。

基于XA协议实现的分布式事务对业务侵入很小。
它最大的优点就是对使用方透明，用户能够像使用本地事务同样使用基于XA协议的分布式事务。
XA协议可以严格保障事务ACID特性。

严格保障事务ACID特性是一把双刃剑。
事务执行在过程当中须要将所需资源所有锁定，它更加适用于执行时间肯定的短事务。
对于长事务来讲，整个事务进行期间对数据的独占，将致使对热点数据依赖的业务系统并发性能衰退明显。
所以，在高并发的性能至上场景中，基于XA协议的分布式事务并非最佳选择。

柔性事务

若是将实现了ACID的事务要素的事务称为刚性事务的话，那么基于BASE事务要素的事务则称为柔性事务。
BASE是基本可用、柔性状态和最终一致性这三个要素的缩写。

• 基本可用（Basically Available）保证分布式事务参与方不必定同时在线。
• 柔性状态（Soft state）则容许系统状态更新有必定的延时，这个延时对客户来讲不必定可以察觉。
• 而最终一致性（Eventually consistent）一般是经过消息传递的方式保证系统的最终一致性。

在ACID事务中对隔离性的要求很高，在事务执行过程当中，必须将全部的资源锁定。
柔性事务的理念则是经过业务逻辑将互斥锁操做从资源层面上移至业务层面。经过放宽对强一致性要求，来换取系统吞吐量的提高。

基于ACID的强一致性事务和基于BASE的最终一致性事务都不是银弹，只有在最适合的场景中才能发挥它们的最大长处。
可经过下表详细对比它们之间的区别，以帮助开发者进行技术选型。

	本地事务	两（三）阶段事务	柔性事务
业务改造	无	无	实现相关接口
一致性	不支持	支持	最终一致
隔离性	不支持	支持	业务方保证
并发性能	无影响	严重衰退	略微衰退
适合场景	业务方处理不一致	短事务 & 低并发	长事务 & 高并发

挑战

因为应用的场景不一样，须要开发者可以合理的在性能与功能之间权衡各类分布式事务。

强一致的事务与柔性事务的API和功能并不彻底相同，在它们之间并不能作到自由的透明切换。在开发决策阶段，就不得不在强一致的事务和柔性事务之间抉择，使得设计和开发成本被大幅增长。

基于XA的强一致事务使用相对简单，可是没法很好的应对互联网的高并发或复杂系统的长事务场景；柔性事务则须要开发者对应用进行改造，接入成本很是高，而且须要开发者自行实现资源锁定和反向补偿。

目标

整合现有的成熟事务方案，为本地事务、两阶段事务和柔性事务提供统一的分布式事务接口，并弥补当前方案的不足，提供一站式的分布式事务解决方案是ShardingSphere分布式事务模块的主要设计目标。