概述

  • 二阶段提交(Two-Phase Commit,2PC)是一种分布式事务协议,用于在分布式系统中确保多个参与者的操作具有原子性
  • 即所有参与者要么全部提交事务,要么全部回滚事务,以维持数据的一致性
  • 它分为两个阶段进行:第一阶段:准备阶段(Prepare Phase),第二阶段:提交阶段(Commit Phase)

场景

  • 现在假设有这么一个场景: 用户下单成功添加积分服务, 同时扣减库存
  • 为什么上图是二阶段提交呢?
  • 首先看下订单的时候的扣减库存,扣减的时候,库存服务要开启本地的数据库事务,但是并未提交
  • 我们的业务,下订单的时候就给积分,调用积分服务,增加完积分时,也是开启本地数据库事务,也是不提交的
  • 这个时候,准备阶段已经结束了,这里有2个远程服务需要操作,这2个服务成功了,就可以本地生成订单和订单详情
  • 之后就是提交阶段,确认库存扣减可以commit了,确认积分增加可以commit了
  • 这样,我们就达到了2阶段提交,如果在生成订单和订单详情出错了,怎么办呢?看下图
  • 订单和订单详情的生成失败,说明了本地有问题,这样就需要告诉远程,这个操作失败,需要你们相关事务进行回滚
  • 这种二阶段提交,看似是非常好的一种解决方案,但是这里会不会有其他问题呢?
  • 首先,肯定有性能问题,在这两个阶段中,订单服务在协调库存服务和订单服务时,三者都是存在挂起的状态,也就是资源被锁住,只有当所有阶段性准备完毕,事务的协调着才会进行事务的提交,这里面性能损失比较大,在高并发下有非常大的风险
  • 其次,订单服务作为一个协调者,如果被协调者参与众多,这个过程就很长,这对性能是一个极大的考验,每个服务都会有超时时间,超时机制要随着服务的增加而增大,不增大的话,调用失败的失败率就会非常高
  • 还有,就是单个服务节点出现故障,比如订单服务这个节点出故障,库存服务和积分服务就不会提交,若库存或积分服务有问题或网络波动导致,订单没有收到响应,则订单取消,库存和积分事务回退,这种问题,如果积压过多,平台效能下降,也是一个问题
  • 以上是二阶段提交保证分布式数据一致性的问题

点赞(0) 打赏

评论列表 共有 0 条评论

暂无评论

微信公众账号

微信扫一扫加关注

发表
评论
返回
顶部