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

概述

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

场景

• 现在假设有这么一个场景: 用户下单成功添加积分服务, 同时扣减库存

• 为什么上图是二阶段提交呢？
• 首先看下订单的时候的扣减库存，扣减的时候，库存服务要开启本地的数据库事务，但是并未提交
• 我们的业务，下订单的时候就给积分，调用积分服务，增加完积分时，也是开启本地数据库事务，也是不提交的
• 这个时候，准备阶段已经结束了，这里有2个远程服务需要操作，这2个服务成功了，就可以本地生成订单和订单详情
• 之后就是提交阶段，确认库存扣减可以commit了，确认积分增加可以commit了
• 这样，我们就达到了2阶段提交，如果在生成订单和订单详情出错了，怎么办呢？看下图

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