【分布式系统】聊聊分布式事务中原子性

什么是分布式事务

在分布式系统中，一个是计算问题，也就是将多个任务，通过流控技术把不同的流量分发给不同的服务器进行处理。另一个就是存储，而只要设计的存储，就必然会引入从单体事务中衍生除的分布式事务问题。
事务的本质是什么，其实就是处理数据的复杂度 转移到数据库层面，业务开发人员无序关注具体的细节，简化开发。

分布式事务有两种方式，一种是数据需要复制到多个副本中，而这种一般都通过单主复制来解决。另一种就是在不同的节点操作不同的数据，比如订单系统N1节点，支付系统N2节点。如何在出现异常情况下进行事务的回滚解决。或者一起成功提交。

从ACID中看分布式事务

一致性与持久性

ACID这里就不说了，在分布式系统中，和单体的一致性和持久性没有太大区别。为了实现一致性，通过前后进行写入日志进行提交和回滚。而持久性，一般都是在返回响应到客户端的时候，进行将数据持久化到非易失性存储设备中，或者使用WAL 先写入日志，后刷新回磁盘的方式。而这种机制其实对于Redis、Kafka都具备。

原子性

二阶段提交

两阶段提交，其实就是为了防止，在一次提交后，有部分节点出现故障而导致数据不一致的问题。
二阶段提交中有两个角色 一个是协调者，另一个是参与者。协调者负责进行决策。而参与者是具体的节点。
第一个阶段：准备阶段，协调者发送请求参与者，参与者是否准备好所需的事务资源准备等。如果准备好，响应。 如果有一个参与者没有响应，那么事务中断。都响应之后，在继续进入下一个阶段。注意这个阶段会执行事务操作。
第二个阶段 提交阶段，因为在准备阶段协调者，接收到所有参与者的准备响应。所以进行提交。如果有一个参与者没有提交成功，则直接回滚整个事务。否则事务提交成功。

其实整个过程就是 一个准备 一个提交阶段。但是对于二阶段提交来说，还是存在很多问题。
比如在准备阶段，可能有一个参与者超时不能响应，这种就需要设置容错机制来解决。超时等待时间。协调者如果是单机可能出现单点故障。以及在提交阶段，如果只有部分完成， 出现网络分区，脑裂问题，会导致数据不一致问题。所以综上所诉，二阶段还是存在一定的问题。所以需要三阶段提交来解决。

三阶段提交

三阶段其实就是三个过程。准备 预提交 提交
为了防止二阶段协调者故障问题，增加一个预提交的过程。
第一阶段，协调者向所有参与者发送资源是否准备好的请求，如果都返回成功，继续
第二阶段，协调者向所有参与者预提交，参与者进行执行事务，并返回结果。
第三阶段，协调者向所有参与者提交，事务完成
如果在任意一个阶段，有参与者没有返回结果。那么就终止。
二阶段提交是阻塞协议，三阶段是非阻塞协议，增加了可用性。