分布式事务模型详解

目录1. CAP理论2. 2PC2.1 2PC存在的问题3. 3PC4. 最终一致性模型1. CAP理论CAP 理论可以表述为一个分布式系统最多只能同时满足一致性、可用性和分区容错性这三项中的两项。一致性是指所有节点在同一时间的数据完全一致。可用性是指“任何时候读写都是成功的”即服务一直可用而且是正常响应时间。分区容错性具体是指当部分节点出现消息丢失或者分区故障的时候分布式系统仍然能够继续运行。典型的就有CP 和 AP架构。对于 CP 来说放弃可用性追求一致性和分区容错性。对于 AP 来说放弃强一致性追求分区容错性和可用性这是很多分布式系统设计时的选择。对于多数大型互联网应用的场景结点众多、部署分散而且现在的集群规模越来越大所以节点故障、网络故障是常态而且要保证服务可用性达到N个999.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. 3PC3PC 将事务提交拆分为 CanCommit、PreCommit、DoCommit 三步CanCommit准备阶段协调者向所有参与者发送CanCommit?请求询问是否具备事务执行条件。参与者检查本地资源无锁、无冲突回复 Yes 或 No。特点不锁定资源、不执行事务仅做可行性投票。PreCommit预提交阶段协调者收到 全 Yes → 发送 PreCommit 指令。收到 任一 No 或超时 → 发送 Abort 回滚。参与者收到 PreCommit → 执行本地事务、锁定资源、写 Undo/Redo 日志但不最终提交。回复 ACK 确认。关键此阶段让所有节点达成 “准备就绪” 的共识。DoCommit最终提交 / 回滚阶段协调者收到全ACK → 发送 DoCommit 正式提交。超时或异常 → 发送 Abort。参与者收到 DoCommit → 提交事务、释放资源。收到 Abort → 利用日志回滚。超时未收到指令 → 自动提交因已确认全员就绪4. 最终一致性模型Try 阶段调用 Try 接口尝试执行业务完成所有业务检查预留业务资源。Confirm 或 Cancel 阶段两者是互斥的只能进入其中一个并且都满足幂等性允许失败重试。Confirm 操作对业务系统做确认提交确认执行业务操作不做其他业务检查只使用 Try 阶段预留的业务资源。Cancel 操作在业务执行错误需要回滚的状态下执行业务取消释放预留资源。Try 阶段失败可以 Cancel如果 Confirm 和 Cancel 阶段失败了怎么办TCC 中会添加事务日志如果 Confirm 或者 Cancel 阶段出错则会进行重试所以这两个阶段需要支持幂等如果重试失败则需要人工介入进行恢复和处理等。