分布式事务柔性事务的解决方法，可靠消息最终一致性

分布式事务简介

理论不多说，谈起事务，必然就绕不过ACID。然而传统的分布式事务在当下的分布式、微服务结构中中并不太合适，数据在传统的分布式事务中会被锁住，而且还要应对XA协议带来的开销（建立和关闭与资源管理器的连接、预提交、提交和回滚一个本地事务等等）。

与之相对的，是更符合当下业务需求的基于BASE理论的柔性事务。

看看ACIＤ和BASE的区别

Soft State：柔性状态

【ACIＤ(A,I)::原子性，隔离性】与【BASE(S)::柔性状态】：比如说在支付系统中，有一个支付业务系统和积分系统，如果要满足原子性与隔离性，那么逻辑肯定是这样的：

要么是支付成功，加积分，在这期间，积分数据与支付数据是不可访问的。 要么是支付失败，积分不变，在这期间，积分数据与支付数据是不可访问的。

但是在BASE的柔性状态中，允许出现

支付成功，积分不变，并且在支付成功后，其他服务查询我的支付状态时，也会是成功的。在这期间，积分数据与支付数据是可访问的。 加积分，支付失败，在这期间，积分数据与支付数据是可访问的。

这样的情况，柔性事务中，允许数据短暂的不一致，以及非隔离性的操作。

Eventual Consistency：最终一致性

【ACIＤ(A,D)::原子性，持久性】与【BASE(E)最终一致性】：最终一致性指的是系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。

事务中的原子性：要么全部成功，要么全部失败（这与上面提到的不同，上面说的是允许中间状态出现，这里说的是最后的状态要是一致的）； 事务中的持久性：数据必须持久化（其实有些业务不持久化也是没问题的….）；

Basically Available：基本可用。

基本可用有两个层面，即，

服务可用，但服务降级了； 分区出现故障，我的业务依旧不受影响；

比如说我有一个秒杀商品的业务，有些用户会获取到一个假的秒杀页，并且秒杀必定失败…之类的。