单机事务向分布式事务的演变
单机事务 ACID
ACID
Transaction事务，单机事务也叫本地事务，将一组数据库操作组成一个逻辑单元。当程序运行事务时，这一组操作执行完毕才会提交，出错可以整体回滚，保证了数据一致性。
原子性（Automicity）
原子性指事务是一个操作单元，在执行后只有两种状态：
全部成功，提交事务
有失败操作，则回滚事务
例如：蛋糕店卖东西，付款后进行 1.收取优惠券 2.收钱 3.增加会员积分，都完成了客人拿蛋糕走人；如果增加会员积分失败，就把付款和优惠券退回给客人，如果收取的优惠券失败（比如优惠券过期了），后面两步也不走了，直接退优惠券，跟客人说你不能走优惠购买流程。
一致性（Consistency）
一致性指事务的执行不能破坏数据库数据的完整性和一致性，在事务执行前后，数据库都处于一致性状态。
例如：蛋糕店10个蛋糕（200一个），收银台有500块钱，卖完1个蛋糕，状态就变为店里9个蛋糕，收银台有700块钱，这就是一致性，我总价值不变。
隔离性（Isolation）
隔离性指在多个事务并发执行时，事务之间是相互隔离的。
隔离级别
1.读未提交（Read Uncommitted）
最低级别，事务可以看到其他事务未提交的执行结果
可能引发脏读、不可重复读、幻读
2.读已提交（Read Committed）
事务可以看到其他事务提交后的执行结果
可能引发不可重复读、幻读
3.可重复读（Repeatable Read）
同一事务中，多次读取同一数据结果一致
可能引发幻读
4.串行化（Serializable）
强制事务排序串行执行，加行锁，效率低
并发事务异常
脏读：并发环境下一个事务读到其他事物尚未提交的数据。
不可重复读：并发环境下一个事务中使用相同条件的两次读取得到的数据不一致。
幻读：并发环境下一个事务中使用相同条件的两次读取得到的数据量不一致
持久性（Durability）
持久性指事务提交后，数据库中的数据变更应该是永久性的
分布式事务 CAP/BASE
当使用单机数据库时，ACID解决了事务处理，但是分布式环境中，数据库散落在不同机器上，可能出现网络问题、部分服务挂掉的问题，所以就需要分布式事务保证分布式环境的可靠性。
CAP
CAP是分布式出现后的理论，三个特性不能共存，现在一般是倾向CP（如Zookeeper），或倾向AP（如Eureka）。
CAP概念
一致性（Consistency）
一致性指数据在多台数据副本保证整体一致。1、2、3三套服务，更新1的话，2 、3也一起更新，这样的系统就具有强一致性
可用性（Available）
可用性指系统一直处于可用，每次发送请求，都保证在“有限的时间内”能“返回结果”。
如果超过“有限的时间内”或不能“返回结果”，系统就是不可用的。
分区容错性（Partition tolerance）
分区容错性指分布式系统中一部分服务挂了，但是还能够正常向外提供服务。
CP
Zookeeper在选举leader时，会停止服务，选举期间不对外提供服务，就违背了可用性，但保证了一致性
AP
Eureka各节点平等，挂了一部分，客户端会去找其他节点，只要有一台还在，就保证了可用性，但是不保证强一致性，但是保证最终一致性。
RocketMQ中的NameServer也有内味儿，NameServer是一个几乎无状态节点，可集群部署，节点之间无任何信息同步，每个broker都和所有NameServer建立长连接，Producer和Consumer和某一台NameServer建立长连接，当一个NameServer挂了，就换一台建立连接。
BASE
BASE是对CAP的权衡，进行了演进，核心思想是虽然无法做到强一致性，但采用适当的方式达到最终一致性。
BASE概念
基本可用（Basic Available）
基本可用指分布式系统出现故障时，允许损失一部分可用性，例如响应时间延长、返回结果变为降级页面。
软状态（Soft state）
软状态指允许数据存在中间状态，各节点数据同步存在延迟。
最终一致性（Eventually consistency）
最终一致性指系统中所以数据副本，经过同步后，最终达到一致的状态。
一致性协议
分布式系统中的每个服务可以知道自己事务操作的结果，但是分布式事务整体结果无法保证，所以要引入协调者，决定参与者是否提交事务。
2PC 二阶段提交
2PC 二阶段提交（Two-Phase Commit），用来保证分布式系统数据的一致性，完成对分布式事务参与者的协调，统一决定事务的提交或回滚，保证分布式数据一致性。
阶段一 提交事务请求（投票阶段）
1.事务询问：协调者向所有参与者发送事务内容， 询问是否可以执行事务提交，等待响应。
2.执行事务：各参与者执行事务操作，将Undo和Redo记入事务日志。
3.响应：各参与者向协调者反馈事务询问的响应，Yes or No。
阶段二 执行事务提交（执行阶段）
执行事务提交
当所有参与者反馈Yes，执行事务提交。
1.发送提交请求：协调者向所有参与者发送Commit请求。
2.事务提交：各参与者提交事务。
3.反馈事务提交结果：参与者向协调者发送Ack。
4.完成事务：协调者接收到所有参与者Ack，完成事务。
中断事务
当出现有参与者反馈No或等待超时后，中断事务。
1.发送回滚请求：协调者向所有参与者节点发Rollback请求。
2.事务回滚：参与者根据阶段一记录的Undo信息执行事务回滚。
3.反馈事务回滚结果：参与者回滚后，发送Ack。
4.中断事务：协调者接收到所有参与者Ack后，中断事务。
2PC 问题
同步阻塞。
协调者单点，不高可用。
数据不一致。
协调者和所有参与者容错率低，一台故障就无法完成。
3PC 三阶段提交
3PC 三阶段提交（Three-Phase Commit），将2PC提交协议的发送提交请求过程拆分，形成CanCommit、PreCommit和DoCommit三个阶段。
阶段一 CanCommit
1.事务询问：协调者向参与者发送包含事务内容的CanCommit请求。
2.响应：各参与者反馈事务询问的响应。
阶段二 PreCommit
执行预提交
1.发送预提交请求：协调者发送preCommit请求，进入Prepared阶段。
2.事务预提交：参与者接收到preCommit后，执行事务操作，并记录Undo和Redo到事务日志。
3.响应：参与者反馈Ack。
中断事务
1.发送中断请求：协调者发送abort。
2.中断事务：参与者中断事务。
阶段三 DoCommit
执行提交
1.发送提交请求：接收所有Ack后，从预提交切换到提交，向参与者发送doCommit。
2.事务提交：参与者接收到doCommit后，提交事务。
3.反馈事务提交结果：参与者发送Ack。
4.完成事务：协调者接收到所有Ack，完成事务。
中断事务
1.发送中断请求：协调者发送abort。
2.事务回滚：参与者利用Undo回滚
3.反馈事务回滚结果：参与者发送Ack
4.中断事务：协调者接收到所有Ack，中断事务。
3PC 问题
比2PC降低参与者阻塞范围。
参与者在PreCommit后，如果网络分区，无法连接协调者，将会提交事务，造成数据不一致
Paxos算法
也是一种一致性协议算法，另行理解吧