Go微服务中无法实现跨服务数据库事务，需采用Saga模式保障最终一致性，辅以幂等设计、状态机编排、独立协调服务及事务日志与重试监控。
Go 微服务里没法直接用数据库事务跨服务
分布式系统中，一个事务涉及多个独立部署、独立数据库的 Go 服务时，SQL COMMIT 或 database/sql 的本地事务完全失效。这不是 Go 语言的问题，而是 CAP 和网络不可靠性决定的底层约束——你不能指望 user-service 和 order-service 同时成功提交或同时回滚。
常见错误现象包括：用户扣款成功但订单没创建、库存减了但支付没到账，这类“半截事务”往往在日志里只看到一方成功、另一方超时或失败，却找不到回滚入口。
- 不要尝试用长事务（Long Running Transaction）+ 全局锁 + 超时重试来模拟 ACID，这在高并发下极易死锁或雪崩
- Go 标准库和主流 ORM（如
gorm、sqlx）都不提供跨服务事务能力，它们只管单库 - 哪怕用
gRPC或HTTP把两个服务调用包进一个defer tx.Rollback()，也毫无意义——第二个服务的数据库操作根本不在这个tx上下文中
Saga 模式是 Go 微服务最实用的落地选择
Saga 把全局事务拆成一系列本地事务，每个步骤都有对应的补偿操作（Compensating Action），失败时反向执行补偿逻辑。它不保证强一致性，但能保障最终一致性，且天然适配 Go 的并发模型和轻量级服务设计。
使用场景：下单（创建订单 → 扣库存 → 扣余额 → 发通知）、退款（退余额 → 加库存 → 更新订单状态）等有明确步骤顺序的业务流。
立即学习“go语言免费学习笔记（深入）”；
- 推荐用状态机驱动 Saga：用
go-statemachine或自定义switch状态流转，避免回调地狱 - 每个子事务必须幂等：例如
deductBalance(userID, amount)要先查当前余额再更新，且对重复请求返回成功 - 补偿操作也要幂等：
refundBalance(userID, amount)需检查原扣款是否已发生，防止重复退钱 - 建议把 Saga 协调逻辑下沉到独立的
saga-orchestrator服务（用gin或gRPC暴露接口），而不是放在某个业务服务里硬编码流程
TCC 模式在 Go 中可行但成本高，慎选
TCC（Try-Confirm-Cancel）要求每个服务提供三个接口：Try（预留资源）、Confirm（真正提交）、Cancel（释放预留）。它比 Saga 更可控，但对业务侵入极深，尤其在 Go 生态中缺乏成熟框架支持。
典型问题：库存服务的 TryDeductStock() 要加 Redis 分布式锁 + 过期时间，而 ConfirmDeductStock() 必须处理锁过期后重复 Confirm 的情况；一旦 Confirm 失败，Cancel 又可能因网络抖动没收到，导致资源长期被冻结。
-
Try阶段不能写主业务表，得另建stock_reservation表或用 Redis Hash 存临时占用 -
Confirm和Cancel必须是纯本地操作，不能依赖其他服务，否则又陷入嵌套分布式问题 - Go 项目若已用
ent或gorm，需额外为每个 TCC 接口维护两套 DAO 层逻辑，测试复杂度陡增 - 除非金融级强一致性要求（如实时资金清算），否则优先用 Saga
别忽略事务日志、重试和监控这些“脏活”
无论选 Saga 还是 TCC，真正难的不是流程编排，而是让失败可追溯、可恢复、可感知。很多 Go 团队卡在这一步：Saga 执行到第三步失败，没人知道该不该重试、重试几次、补偿是否执行成功。
- 必须持久化 Saga 日志：用 PostgreSQL 或 MySQL 记录每一步的
service_name、operation、payload、status、created_at、updated_at - 实现异步重试器：监听日志表中
status = 'failed'的记录，按指数退避（time.Sleep(1 ）发起重试，最多 5 次后告警 - 给每个关键步骤打结构化日志（
zerolog或zap），带上saga_id字段，方便全链路追踪 - 在 Prometheus 中暴露
saga_failed_total{step="deduct_stock"}这类指标，配合 Grafana 告警——比看日志快得多
最容易被忽略的是补偿操作的“延迟生效”：比如库存补偿要在订单取消后 10 分钟才执行，以防用户极速重下同一单。这种时间维度的控制，得靠定时任务或消息延迟队列（Redis ZSET 或 RocketMQ delay level），不是加个 time.AfterFunc 就完事的。
