Golang微服务中如何处理数据一致性_Golang分布式事务思路-Golang

本地事务在微服务中失效是因为SQL事务仅保障单库ACID，跨服务调用无法协调，导致部分成功引发数据不一致；Saga模式通过可补偿的本地事务链实现最终一致性，是Go微服务中最现实的选择。

为什么本地事务在微服务里直接失效

微服务拆分后，一个业务操作常涉及多个服务的数据库，sql.Tx 只能保证单库 ACID，跨服务时 commit 一半失败，就会出现状态不一致。比如订单服务扣减库存成功，但支付服务写入失败，用户没付款却库存已扣——这不是程序 bug，是架构约束下的必然结果。

• 不要试图用 database/sql 的事务包裹跨服务调用，它对远程 HTTP/gRPC 调用完全无感知
• 两阶段提交（2PC）在 Go 生态中几乎没有成熟、轻量、生产可用的实现，且会显著拖慢性能、提高运维复杂度
• Saga 模式不是“替代方案”，而是当前 Go 微服务中最现实的选择：用可补偿的本地事务链，换取最终一致性

Saga 模式在 Go 中怎么落地（正向 + 补偿流程）

核心是把一个分布式操作拆成一系列本地事务步骤，每步都配一个对应的补偿操作（undo）。Go 里没有框架强制你写补偿逻辑，得靠结构设计兜住。

• 每个服务暴露两个接口：CreateOrder（正向）和 CancelOrder（补偿），两者都必须是幂等的
• 用消息队列（如 Kafka/RabbitMQ）或数据库表（saga_log）记录执行进度，避免因服务重启丢失状态
• 推荐用状态机管理 Saga 流程，例如用 github.com/looplab/fsm 定义 pending → confirmed → cancelled 等状态，防止重复执行或跳步
• 示例片段：

  if err := orderSvc.Create(ctx, req); err != nil {
      // 记录失败，触发补偿链路
      sagaLog.FailStep("create_order", err)
      return compensateInventory(ctx, req.OrderID)
  }

什么时候该用本地消息表，而不是直接发 MQ

直接调 producer.Send() 发消息，若 DB commit 成功但网络抖动导致消息丢失，就会漏掉后续步骤。本地消息表本质是把“发消息”也变成一个本地事务操作。