图中那个红衣服的就是本人
分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
简单的说,就是一次大的操作由不同的小操作组成,这些小的操作分布在不同的服务器上,且属于不同的应用,分布式事务需要保证这些小操作要么全部成功,要么全部失败。
本质上来说,分布式事务就是为了保证不同数据库的数据一致性。
数据库的 ACID 满足了数据库本地事务的基础,但是它无法满足分布式事务,这个时候衍生了 CAP 和 BASE 两个经典理论。
BASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性) 三个短语的缩写。是对 CAP 中AP 的一个扩展
BASE 解决了 CAP 中理论没有网络延迟,在 BASE 中用软状态和最终一致,保证了延迟后的一致性。
BASE 和 ACID 是相反的,它完全不同于 ACID 的强一致性模型,而是通过牺牲强一致性来获得可用性,并允许数据在一段时间内是不一致的,但最终达到一致状态。
对于大部分的分布式应用而言,只要数据在规定的时间内达到最终一致性即可。 我们可以把符合传统的 ACID 叫做刚性事务,把满足 BASE 理论的最终一致性事务叫做柔性事务。
具体到分布式事务的实现上,业界主要采用了 XA 协议的强一致规范以及柔性事务的最终一致规范。
Seata 是一款开源的分布式事务解决方案,提供高性能和简单易用的分布式事务服务。
Github: https://github.com/seata/seata
XA 是 X/Open CAE Specification (Distributed Transaction Processing)模型,它定义的 TM(Transaction Manager)与 RM(Resource Manager)之间进行通信的接口。
Java中 的 javax.transaction.xa.XAResource
定义了 XA 接口,它依赖数据库厂商对 jdbc-driver 的具体实现。
mysql-connector-java-5.1.30
的实现可参 com.mysql.jdbc.jdbc2.optional.MysqlXAConnection
类。在 XA 规范中,数据库充当 RM 角色,应用需要充当 TM 的角色,即生成全局的 txId ,调用 XAResource 接口,把多个本地事务协调为全局统一的分布式事务。
目前 XA 有两种实现:
AT自动补偿模式就是基于一阶段提交的弱XA
业务无侵入 | 业务侵入 |
---|---|
AT | TCC |
XA | Saga |
TCC 模型是把锁的粒度完全交给业务处理,它需要每个子事务业务都实现Try-Confirm / Cancel 接口。
TCC 模式本质也是 2PC ,只是 TCC 在应用层控制。
这三个阶段,都会按本地事务的方式执行。不同于 XA的prepare ,TCC 无需将 XA 的投票期间的所有资源挂起,因此极大的提高了吞吐量。