目录
1. CAP理论
2. 2PC
2.1 2PC存在的问题
3. 3PC
4. 最终一致性模型
1. CAP理论
CAP 理论可以表述为，一个分布式系统最多只能同时满足一致性、可用性和分区容错性这三项中的两项。一致性是指所有节点在同一时间的数据完全一致。可用性是指“任何时候，读写都是成功的”，即服务一直可用，而且是正常响应时间。分区容错性具体是指当部分节点出现消息丢失或者分区故障的时候，分布式系统仍然能够继续运行。典型的就有CP 和 AP架构。对于 CP 来说，放弃可用性，追求一致性和分区容错性。对于 AP 来说，放弃强一致性，追求分区容错性和可用性，这是很多分布式系统设计时的选择。对于多数大型互联网应用的场景，结点众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到N个9（99.99..%），并要达到良好的响应性能来提高用户体验，因此一般都会做出如下选择：保证P和A，舍弃C强一致，保证最终一致性。
2. 2PC
两阶段提交，就是将提交过程划分为2个阶段：
准备阶段：TM（事务管理器）通知各个RM（资源管理器）准备提交它们的事务分支。如果RM判断自己进行的工作可以被提交，那就对工作内容进行持久化，再给TM肯定答复；要是发生了其他情况，那给TM的都是否定答复。以mysql数据库为例，在第一阶段，事务管理器向所有涉及到的数据库服务器发出prepare"准备提交"请求，数据库收到请求后执行数据修改和日志记录等处理，处理完成后只是把事务的状态改成"可以提交"，然后把结果返回给事务管理器。
提交/回滚阶段：TM根据阶段1各个RM prepare的结果，决定是提交还是回滚事务。如果所有的RM都prepare成功，那么TM通知所有的RM进行提交；如果有RM prepare失败的话，则TM通知所有RM回滚自己的事务分支。
2.1 2PC存在的问题
同步阻塞问题：2PC 中的参与者是阻塞的。在第一阶段收到请求后就会预先锁定资源，一直到 commit 后才会释放。
单点故障：由于协调者的重要性，一旦协调者TM发生故障，参与者RM会一直阻塞下去。尤其在第二阶段，协调者发生故障，那么所有的参与者还都处于锁定事务资源的状态中，而无法继续完成事务操作。
数据不一致：若协调者第二阶段发送提交请求时崩溃，可能部分参与者收到commit请求提交了事务，而另一部分参与者未收到commit请求而放弃事务，从而造成数据不一致的问题。
3. 3PC
3PC 将事务提交拆分为 CanCommit、PreCommit、DoCommit 三步：
CanCommit（准备阶段）：协调者：向所有参与者发送CanCommit?请求，询问是否具备事务执行条件。参与者：检查本地资源（无锁、无冲突），回复 Yes 或 No。特点：不锁定资源、不执行事务，仅做可行性投票。
PreCommit（预提交阶段）：协调者：收到 全 Yes → 发送 PreCommit 指令。收到 任一 No 或超时 → 发送 Abort 回滚。参与者：收到 PreCommit → 执行本地事务、锁定资源、写 Undo/Redo 日志，但不最终提交。回复 ACK 确认。关键：此阶段让所有节点达成 “准备就绪” 的共识。
DoCommit（最终提交 / 回滚阶段）：协调者：收到全ACK → 发送 DoCommit 正式提交。超时或异常 → 发送 Abort。参与者：收到 DoCommit → 提交事务、释放资源。收到 Abort → 利用日志回滚。超时未收到指令 → 自动提交（因已确认全员就绪）
