关于数据库:ShardingSphere-4x-分布式事务

背景

数据库事务须要满足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 分布式事务模块的次要设计指标。