Go微服务: 基于使用场景理解分布式之二阶段提交

概述

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

场景

  • 现在假设有这么一个场景: 用户下单成功添加积分服务, 同时扣减库存
  • 为什么上图是二阶段提交呢?
  • 首先看下订单的时候的扣减库存,扣减的时候,库存服务要开启本地的数据库事务,但是并未提交
  • 我们的业务,下订单的时候就给积分,调用积分服务,增加完积分时,也是开启本地数据库事务,也是不提交的
  • 这个时候,准备阶段已经结束了,这里有2个远程服务需要操作,这2个服务成功了,就可以本地生成订单和订单详情
  • 之后就是提交阶段,确认库存扣减可以commit了,确认积分增加可以commit了
  • 这样,我们就达到了2阶段提交,如果在生成订单和订单详情出错了,怎么办呢?看下图
  • 订单和订单详情的生成失败,说明了本地有问题,这样就需要告诉远程,这个操作失败,需要你们相关事务进行回滚
  • 这种二阶段提交,看似是非常好的一种解决方案,但是这里会不会有其他问题呢?
  • 首先,肯定有性能问题,在这两个阶段中,订单服务在协调库存服务和订单服务时,三者都是存在挂起的状态,也就是资源被锁住,只有当所有阶段性准备完毕,事务的协调着才会进行事务的提交,这里面性能损失比较大,在高并发下有非常大的风险
  • 其次,订单服务作为一个协调者,如果被协调者参与众多,这个过程就很长,这对性能是一个极大的考验,每个服务都会有超时时间,超时机制要随着服务的增加而增大,不增大的话,调用失败的失败率就会非常高
  • 还有,就是单个服务节点出现故障,比如订单服务这个节点出故障,库存服务和积分服务就不会提交,若库存或积分服务有问题或网络波动导致,订单没有收到响应,则订单取消,库存和积分事务回退,这种问题,如果积压过多,平台效能下降,也是一个问题
  • 以上是二阶段提交保证分布式数据一致性的问题
相关推荐
数据智能老司机5 小时前
CockroachDB权威指南——CockroachDB SQL
数据库·分布式·架构
数据智能老司机6 小时前
CockroachDB权威指南——开始使用
数据库·分布式·架构
数据智能老司机7 小时前
CockroachDB权威指南——CockroachDB 架构
数据库·分布式·架构
IT成长日记7 小时前
【Kafka基础】Kafka工作原理解析
分布式·kafka
州周8 小时前
kafka副本同步时HW和LEO
分布式·kafka
lmryBC4910 小时前
golang接口-interface
java·前端·golang
爱的叹息10 小时前
主流数据库的存储引擎/存储机制的详细对比分析,涵盖关系型数据库、NoSQL数据库和分布式数据库
数据库·分布式·nosql
浮尘笔记11 小时前
go-zero使用elasticsearch踩坑记:时间存储和展示问题
大数据·elasticsearch·golang·go
千层冷面11 小时前
RabbitMQ 发送者确认机制详解
分布式·rabbitmq·ruby
ChinaRainbowSea11 小时前
3. RabbitMQ 的(Hello World) 和 RabbitMQ 的(Work Queues)工作队列
java·分布式·后端·rabbitmq·ruby·java-rabbitmq