分布式事务——2PC和3PC

资料参考来源拉钩Java高薪训练营


一、事务4个特性ACID

  1. Atomicity(原子性):是说事务是一个不可分割的整体,所有操作要么全做,要么全不做;只要事务中有一个操作出错,回滚到事务开始前的状态的话,那么之前已经执行的所有操作都是无效的,都应该回滚到开始前的状态。
  2. Consistency(一致性):是说事务执行前后,数据从一个状态到另一个状态必须是一致的,比如A向B转账(A、B的总金额就是一个一致性状态),不可能出现A扣了钱,B却没收到的情况发生。
  3. Isolation(隔离性):多个并发事务之间相互隔离,不能互相干扰。关于事务的隔离性,可能不是特别好理解,这里的并发事务是指两个事务操作了同一份数据的情况;而对于并发事务操作同一份数据的隔离性问题,则是要求不能出现脏读、幻读的情况,即事务A不能读取事务B还没有提交的数据,或者在事务A读取数据进行更新操作时,不允许事务B率先更新掉这条数据。而为了解决这个问题,常用的手段就是加锁了,对于数据库来说就是通过数据库的相关锁机制来保证。
  4. Durablity(持久性):事务完成后,对数据库的更改是永久保存的。

二、一致性协议 2PC

2PC定义

2PC ( Two-Phase Commit缩写)即两阶段提交协议,是将整个事务流程分为两个阶段,准备阶段(Preparephase)、提交阶段(commit phase),2是指两个阶段,P是指准备阶段,C是指提交阶段。

  • 准备阶段:事务管理器给每个参与者发送Prepare消息,每个数据库参与者在本地执行事务,并写本地的Undo/Redo日志,此时事务没有提交。(Undo日志是记录修改前的数据,用于数据库回滚,Redo日志是记录修改后的数据,用于提交事务后写入数 据文件)
  • 提交阶段(commit phase):如果事务管理器收到了参与者的执行失败或者超时消息时,直接给每个参与者发送回滚(Rollback)消息;否则,发送提交(Commit)消息;参与者根据事务管理器的指令执行提交或者回滚操作,并释放事务处理过程中使用的锁资源。注意:必须在最后阶段释放锁资源。

2PC执行流程

  1. 成功执行流程:
    在这里插入图片描述

  2. 执行失败中断事务:
    在这里插入图片描述

2PC 优点缺点

优点:

  • 原理简单,实现方便

缺点:

  • 同步阻塞
    在二阶段提交的执行过程中,所有参与该事务操作的逻辑都处于阻塞状态,也就是说,各个参与者在等待其他参与者响应的过程中,无法进行其他操作。这种同步阻塞极大的限制了分布式系统的性能。
  • 单点问题
    协调者在整个二阶段提交过程中很重要,如果协调者在提交阶段出现问题,那么整个流程将无法运转,更重要的是:其他参与者将会处于一直锁定事务资源的状态中,而无法继续完成事务操作。
  • 数据不一致
    假设当协调者向所有的参与者发送 commit 请求之后,发生了局部网络异常或者是协调者在尚未发送完所有 commit请求之前自身发生了崩溃,导致最终只有部分参与者收到了 commit 请求。这将导致严重的数据不一致问题。
  • 过于保守
    如果在二阶段提交的提交询问阶段中,参与者出现故障而导致协调者始终无法获取到所有参与者的响应信息的话,这时协调者只能依靠其自身的超时机制来判断是否需要中断事务,显然,这种策略过于保守。换句话说,二阶段提交协议没有设计较为完善的容错机制,任意一个节点失败都会导致整个事务的失败。

三、一致性协议 3PC

3PC定义

3PC,全称 “three phase commit”,是 2PC 的改进版,将 2PC 的 “提交事务请求” 过程一分为二,共形成了由CanCommit、PreCommit和doCommit三个阶段组成的事务处理协议。
在这里插入图片描述

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
2PC(Two-Phase Commit)是一种常见的分布式事务协议,用于确保多个数据库或服务之间的事务的一致性。它的工作原理如下: 1. 准备阶段(Prepare Phase):事务协调者(Coordinator)向所有参与者(Participants)发送准备请求,并等待它们的响应。参与者执行事务的准备操作,将准备结果(可以提交或中止)返回给协调者。 2. 提交阶段(Commit Phase):如果所有参与者都准备就绪(即返回提交的准备结果),协调者向所有参与者发送提交请求。参与者根据协调者的请求,执行事务的提交操作,并向协调者发送提交完成的通知。 3. 中止阶段(Abort Phase):如果任何参与者返回中止的准备结果,或者在提交阶段中发生通信故障,则协调者向所有参与者发送中止请求。参与者执行事务的中止操作,并向协调者发送中止完成的通知。 2PC采用了两个阶段的提交过程,通过协调者的指导来保证所有参与者在提交或中止事务时达成一致。但是2PC存在一些问题,例如: 1. 同步阻塞:在准备和提交阶段,协调者需要等待所有参与者返回结果,这会导致阻塞,特别是当参与者之间通信故障或者响应时间较长时。 2. 单点故障:协调者是2PC协议的中心节点,如果协调者发生故障,整个分布式系统将无法正常工作。 3. 数据不一致:如果在提交阶段发生通信故障,部分参与者已经提交事务而另一部分参与者无法接收到提交请求,会导致数据的不一致。 因此,虽然2PC是一种常见的分布式事务协议,但它存在一些局限性。在实际应用中,可以考虑使用其他分布式事务协议,如3PC(Three-Phase Commit)或者使用更为灵活的CAP定理相关的协议,根据具体的应用场景选择适合的分布式事务处理方式。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值