分布式事务

分布式事务概念

业务的本质是对数据进行的操作，最终沉淀下来的就是数据，当然这些数据沉淀都是在某个确定的上下文条件下进行沉淀的。事务就是业务操作数据时的性质（一致性和原子性是基本，隔离性和持久性是方法）。分布式事务指的就是事务是在分布式场景下的特殊情况而已。

原子性

为了保证操作数据的安全，必须将操作数据控制在同一个上下文，也就是说从看到数据到操作数据这整个过程都是同一个上下文。也就是说这些操作要么都执行，要么都不执行。

实现原子性的方法

锁

为了保障数据处在同一个上下文，提出了锁的概念，锁就是将数据控制在同一个上下文的手段，这种手段是独占和强制的。一旦锁被占用，就不能再占用，锁是资源的入口。这就是所谓的悲观锁方案。先控制住上下文，然后在进行修改。

CAS

CAS是另一种将数据控制在同一个上下文的手段，只不过它不是强制性地把资源的入口给独占，而是在更新资源的时候把自己的上下文给写进去，告诉其他使用资源的“这个资源已经被我给更新了”。这就是所谓的乐观锁方案。先获取上下文，修改的同时比较写入的上下文和获取的上下文，相同表明处于同一个上下文里。

一致性

业务操作的本质就是对数据的状态进行改变，这就说明了数据库在整个状态的变化过程中是有序的。从另一个角度来说，每个业务操作其实就对应了数据库的某个具体的状态，也就是数据快照。反向理解，如果某个业务操作失败了，那么整个数据库应该可以回滚到上一个状态。这就是一致性，用来表示业务操作和沉淀数据之间一一对应的关系。

原子性和一致性其实本质上都是对同一个东西的不同描述吧。有了原子性，一致性肯定是有保障的；需要一致性，那么必须有原子性给他提供保驾护航。

当处于分布式场景下，事务所操作数据是分布在不同网络节点下的。换个角度看问题，其实就是对同一份数据的描述需要有多个网络节点的参与。

一致性在分布式场景下，按照使用的强度，可以分为最终一致性和强一致性。

最终一致性实现方案

最终一致性实现方案业界都比较成熟了，基本都是通过MQ异步进行数据同步。也就是说先只以网络中的某个节点上的数据作为整个操作成功与否的判断条件，如果成功了就以后就把这个成功操作的行为同步到其他节点，注意是行为，也就是对操作的描述。

强一致性实现方案

分布式锁

两段提交协议

CAS本质就是两段提交协议。在操作资源的时候，先获取资源的上下文（commit阶段），然后在更新（accept阶段），只有最先更新的才成功。

paxos协议

paxos协议就是两段提交协议在分布式系统中的运用，原来更新数据都只有唯一的一份，现在是有多份相同的数据。

raft协议

raft协议是一种简化过的paxos协议。