本地消息表必须与业务表同库，因需单机事务保证“业务操作+消息落库”原子性；跨库会导致订单成功但消息丢失，引发永久数据不一致。
本地消息表必须和业务表在同一个数据库，否则事务无法保证原子性——这是硬约束，不是优化建议。
为什么本地消息表一定要和业务表同库
核心就一条：靠单机事务兜住「业务操作 + 消息落库」这两件事。如果消息表在另一个 MySQL 实例里，哪怕只差几毫秒，就可能出现订单创建成功但消息没写进去的情况。下游服务永远收不到扣库存指令，数据就永久不一致了。
常见错误现象：INSERT INTO order 成功，但 INSERT INTO message 因网络抖动或连接池耗尽失败；日志里只看到“订单已创建”，查 message 表却为空。
- go-zero 中必须共用同一个
*sql.DB实例，不能对业务库和消息库分别调sql.Open() - 建表时别加
ENGINE=MyISAM—— 它不支持SELECT ... FOR UPDATE，后续扫描更新会漏掉并发竞争的记录 -
status字段建议用TINYINT，避免WHERE status = 'sent'导致索引失效
消息发送器怎么做到不漏推、不重推
关键不在“怎么发”，而在“怎么捞 + 怎么标 + 怎么判”。三步必须在一个事务里完成，且更新条件要带状态过滤。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
典型错误写法：SELECT * FROM message WHERE status = 0 LIMIT 10 → 并发时两个 goroutine 同时捞到同一条记录 → 都去发 MQ → 重复消费。
- 正确姿势是：先
UPDATE message SET status = 1 WHERE id = ? AND status = 0，再检查RowsAffected == 1，成功才调 MQ 发送 - 扫描间隔别设固定 1s，改用指数退避：第一次失败后
time.Sleep(time.Second * 2)，再失败翻倍，上限控制在 30s 内 - 别在循环里直接调
kafka.Producer.SendMessage()，先丢进异步任务队列（比如asynq.NewTask("send_to_kafka", payload)），防止网络卡顿拖死整个扫描协程
消费者幂等处理最省事的三种写法
95% 的场景，根本不需要上 Redis 分布式锁或 RocketMQ 事务消息。数据库原生能力就能搞定。
- 用条件更新：库存服务收到
OrderPaidEvent后，执行UPDATE inventory SET stock = stock - ? WHERE sku_id = ? AND version = ?，失败说明已处理过 - 建联合唯一索引：
ALTER TABLE event_log ADD UNIQUE KEY uk_order_event (order_id, event_type)，插入前用INSERT IGNORE - Redis 轻量标记：
SETNX order:123:paid true EX 3600，但必须设EX过期时间，否则宕机后这个 key 永远卡住
重试机制里最容易被忽略的 timeout 和 max_retry
很多人只写了 for i := 0; i ，但没控制每次调用的超时。一次 Kafka 网络延迟就可能卡满 30 秒，压垮整个补偿服务。
- 每次远程调用都要包一层
ctx, cancel := context.WithTimeout(ctx, 3*time.Second) -
max_retry别硬编码，从配置中心读取，大促时可动态调低（比如临时设为 1） - 第 3 次失败后，别再自动重试，写入
compensation_failed表并触发告警——人工介入比盲目重试更可靠
真正难的不是写代码，而是想清楚每一步失败后系统处于什么状态、谁来兜底、兜不住怎么办。本地消息表不是银弹，它只是把“发消息”这件事拉回事务边界内，剩下的，得靠状态记录、重试策略和人工干预闭环。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
