database/sql.tx 在跨服务调用中无效，因其仅绑定单个数据库连接，对 http/grpc 调用或远程 db 操作完全无感知；一个服务 tx.commit() 成功时，另一服务的数据库早已独立执行或失败，状态互不感知，导致订单创建成功但库存未扣、余额已减但支付记录缺失等数据不一致问题。
database/sql.Tx 在跨服务调用中为什么无效
因为 sql.Tx 只绑定单个数据库连接，对 HTTP/gRPC 调用、远程 DB 操作完全无感知。你在一个服务里 tx.Commit() 成功，另一个服务的数据库早已执行完毕或失败，两者状态互不感知。
常见错误现象：
– 订单创建成功但库存没扣，用户看到“已下单”却查不到库存变更
– 余额已减，支付记录却未生成，账务对不上
– 补偿逻辑未触发，因消息丢失或消费者 crash 后未重试
- 所有跨服务写操作必须拆解为「本地事务 + 外发事件」两步：先在本库落日志（如
saga_log表），再发消息；不能先发消息再 commit - 别在事务里混用
db.Exec()和tx.Exec()——前者可能走不同连接，导致部分提交 -
tx不是线程安全的，禁止跨 goroutine 复用；每个请求新建一个tx，用完立刻Close()或Rollback()
Saga 模式落地时补偿接口必须满足什么条件
补偿不是“再跑一遍正向逻辑”，而是要能反复执行且不翻车。它失效的典型场景是：同一笔订单被重复补偿，导致余额多退、库存多加。
实操建议：
– 补偿函数第一行必须查表确认是否已执行（例如查 refund_log 是否存在 order_id）
– 更新 Saga 进度必须落库，字段至少含 order_id、current_step、version，更新时带 WHERE version = ? 防覆盖
– 不要用 Redis 或内存存进度——节点重启就丢，流程直接断裂
- 幂等 key 推荐组合：业务主键 + 步骤名，如
"order_123_create_order" - 补偿任务建议通过
asynq或machinery异步投递，避免阻塞主流程 - 死信队列不是备选方案，是必选项：补偿失败三次后进 DLQ，触发人工干预告警
本地消息表 vs 直接 Kafka Producer.Send() 怎么选
直接调 producer.Send() 看似简单，但网络抖动时极易丢消息：DB 已 commit，消息却没发出去，后续步骤永远卡住。
本地消息表本质是把“发消息”也纳入本地事务边界：
- 写入一条记录：
INSERT INTO message (topic, payload, status) VALUES ('inventory.decrease', '{"order_id":"123"}', 'pending') - 同事务内完成业务操作（如创建订单），再
tx.Commit() - 独立 goroutine 轮询
status = 'pending'记录，调producer.Send()并更新为'sent' - 轮询间隔建议指数退避（1s → 2s → 4s），避免压垮 DB
Kafka 事务支持（transactional.id）虽可用，但要求 Kafka ≥ 0.11 且集群开启对应配置，实际部署约束多，不如本地表通用可靠。
最终一致性下读操作怎么避免脏读
用户端订单列表、商品详情页这类读场景，根本不需要强一致——延迟 1~3 秒完全无感，但硬上 SELECT FOR UPDATE 会拖垮性能。
正确做法是分层读取：
- 管理后台查明细：用
db.QueryRowContext(ctx, "SELECT ... FOR UPDATE", ...)，配context.WithTimeout(ctx, 3*time.Second) - 用户端列表页：走只读从库或缓存（Redis），数据来源是消费 Kafka 事件后异步更新的物化视图
- 关键状态判断（如“能否再次下单”）：查本地
order_status表 + 版本号，不依赖其他服务实时响应
Saga 流程中每一步的状态变更，必须经由显式状态机驱动（比如用 looplab/fsm），禁止绕过状态校验直接 UPDATE order SET status = 'paid'。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
