17370845950

Go 无内置分布式事务支持，需集成外部方案；Saga 模式最实用，推荐 Dapr 实现，需启用 --enable-saga 参数并手动记录补偿日志。

Go 里没有内置的分布式事务支持

Go 标准库和主流 ORM（如 gorm、sqlx）只提供本地事务（Begin/Commit/Rollback），无法跨服务、跨数据库协调。所谓“在 Go 中实现分布式事务”，实际是选用或集成外部方案，而非语言层原生能力。

常见选型：Saga 模式最实用

相比两

阶段提交（2PC），Saga 更轻量、更符合 Go 微服务场景。核心是把一个分布式操作拆成一系列本地事务，每个步骤有对应补偿动作。失败时反向执行补偿，保证最终一致性。

实操建议：

• 用 go-stripe 或自研状态机管理 Saga 流程，避免手写大量 if err != nil 补偿逻辑
• 每个子事务必须幂等；补偿操作也必须幂等（例如用 UPDATE ... SET status = 'canceled' WHERE id = ? AND status = 'pending'）
• 超时控制关键：Saga 步骤间需设 context.WithTimeout，防止卡死；补偿失败要进死信队列（如写入 saga_dead_letter 表）
• 推荐库：asim/go-micro/v4 的 broker + 自定义 Saga 协调器，或直接用 dapr 的 saga 构建块（通过 HTTP/gRPC 调用）

不要在 Go 里硬套 XA 或 Seata

XA 协议依赖数据库端支持（如 MySQL 的 xa_start），且 Go 驱动（go-sql-driver/mysql）不实现 XA 接口；Seata 的 Go 客户端（seata-golang）仍处实验阶段，社区维护弱，生产环境易遇 timeout waiting for tc response 或分支事务状态不同步问题。

典型错误现象：

• 调用 tm.Begin 后，多个 rm.Register 成功，但某次 rm.Commit 返回 rpc error: code = DeadlineExceeded
• 数据库已提交，但 Seata TC 认为超时回滚，导致数据不一致
• 日志里反复出现 GlobalTransaction is not active —— 实际是 Go 客户端上下文未透传或超时设置不合理

Dapr 是目前 Go 微服务最省心的选择

Dapr 把分布式事务抽象成可插拔的构建块，Go 服务只需发 HTTP 请求或调用 SDK，由 Dapr Sidecar 处理协调逻辑。它底层默认用 Saga，支持自动重试、超时、补偿跟踪。

最小可行示例（使用 Dapr SDK）：

import "github.com/dapr/go-sdk/client"

func executeSaga(client client.Client) error {
	// 1. 开启全局事务
	saga := client.NewSaga("order-process")
	
	// 2. 添加子事务（每个都是本地 HTTP 调用）
	saga.AddStep("http://inventory-service/v1/deduct", "POST", `{"id":123,"qty":2}`)
	saga.AddStep("http://payment-service/v1/charge", "POST", `{"order_id":"abc","amount":99.9}`)

	// 3. 添加补偿（顺序相反）
	saga.AddCompensatingStep("http://payment-service/v1/refund", "POST", `{"order_id":"abc"}`)
	saga.AddCompensatingStep("http://inventory-service/v1/restore", "POST", `{"id":123,"qty":2}`)

	return saga.Execute(context.Background())
}

注意：dapr run --app-id order-svc --dapr-http-port 3500 go run main.go 启动时必须带 --enable-saga 参数，否则 saga.Execute 会返回 ERR_SAGA_NOT_ENABLED。

真正容易被忽略的是补偿接口的可观测性：Dapr 不自动记录每步的响应体，出错时仅返回 failed step: payment-service，你需要在 /v1/charge 接口里主动打结构化日志，包含 trace_id 和请求参数快照。