Transcation
分布式事务的实现算法有很多,有基于 XA 协议的 2PC、3PC,也有业务的分布式事务实现 TCC,还有基于消息的分布式事务。
分布式事务是多个单机事务的组合。
2PC
二阶段提交(The two-phase commit protocol, 2PC)是 XA 协议的实现方式之一,强一致性。有两个角色,事务管理器和本地资源管理器。
事务管理器为协调者,负责各个本地资源管理器的提交和回滚。
2PC 有投票(voting)和提交(commit)两个阶段。
事务管理器(协调者)向本地资源管理器(参与者)发送 CanCommit 请求。
参与者执行事务操作,记录日志但不提交。根据执行成功与否,返回 Yes 或 No 消息。
协调者根据 Yes 还是 No 发送 DoCommit 或 DoAbort 请求。
参与者根据 DoCommit 还是 DoAbort 进行事务的提交或回滚,并返回 HaveCommitted 消息。
协调者接受到 HaveCommitted 消息,表示事务结束。
缺点:
同步阻塞问题:本地资源管理器占有临界资源时,其它资源管理器若要访问同一资源,则会处于阻塞状态。
单点故障问题:一单事务管理发生故障,则整个系统不可用。尤其在提交阶段,资源管理器一直锁定事务资源。
数据不一致问题:若提交阶段由于网络异常,仅部分资源管理器收到 DoCommit 请求,则整个系统数据不一致。
3PC
三阶段提交协议(Three-phase commit protocol, 3PC)也是 XA 协议的实现方式,强一致性。对 2PC 做了改进,引入了超时机制和准备阶段。
参与者与协调者都有超时机制,超时后,根据当前状态选择提交或终止整个事务。
CanCommit、PreCommit、DoCommit 三个阶段。
协调者发送 CanCommit 请求。
参与者根据状态发送 Yes 或 No。
协调者若收到 No,则发送Abort。若收到全部是 Yes,则发送 PreCommit 请求。
参与者若收到 Abort 或超时后未收到消息,则执行事务中断。若收到 PreCommit 请求,则执行事务操作,并记录 Undo 和 Redo 日志,并相应 ACK。
协调者若收到 ACK,则发送 DoCommit 请求。
很少被使用,因为相比于 2PC 需要更多的消息协商,增加系统负载和响应延时。
TCC
Try-Confirm-Cancel,最终一致。针对每个操作都要注册一个与其对应的确认操作和撤销操作。确认操作和撤销操作必须是幂等的。是一个业务层面的协议,不依赖于数据库的事务,3 个操作都需要在业务代码中实现。
优点:
不依赖数据库事务。
缺点:
实现复杂
基于消息
最终一致。2PC 和 3PC 都需要锁定资源,通过消息可以解决此问题。
Last updated