分布式事务简介
理论不多说,谈起事务,必然就绕不过ACID。然而传统的分布式事务在当下的分布式、微服务结构中中并不太合适,数据在传统的分布式事务中会被锁住,而且还要应对XA协议带来的开销(建立和关闭与资源管理器的连接、预提交、提交和回滚一个本地事务等等)。
与之相对的,是更符合当下业务需求的基于BASE理论的柔性事务。
看看ACID和BASE的区别
Soft State:柔性状态
【ACID(A,I)::原子性,隔离性】与【BASE(S)::柔性状态】:比如说在支付系统中,有一个支付业务系统和积分系统,如果要满足原子性与隔离性,那么逻辑肯定是这样的:
- 要么是支付成功,加积分,在这期间,积分数据与支付数据是不可访问的。
- 要么是支付失败,积分不变,在这期间,积分数据与支付数据是不可访问的。
但是在BASE的柔性状态中,允许出现
- 支付成功,积分不变,并且在支付成功后,其他服务查询我的支付状态时,也会是成功的。在这期间,积分数据与支付数据是可访问的。
- 加积分,支付失败,在这期间,积分数据与支付数据是可访问的。
这样的情况,柔性事务中,允许数据短暂的不一致,以及非隔离性的操作。
Eventual Consistency:最终一致性
【ACID(A,D)::原子性,持久性】与【BASE(E)最终一致性】:最终一致性指的是系统中的所有数据副本经过一定时间后,最终能够达到一致的状态。
- 事务中的原子性:要么全部成功,要么全部失败(这与上面提到的不同,上面说的是允许中间状态出现,这里说的是最后的状态要是一致的);
- 事务中的持久性:数据必须持久化(其实有些业务不持久化也是没问题的….);
Basically Available:基本可用。
基本可用有两个层面,即,
- 服务可用,但服务降级了;
- 分区出现故障,我的业务依旧不受影响;
比如说我有一个秒杀商品的业务,有些用户会获取到一个假的秒杀页,并且秒杀必定失败…之类的。