# 架构实战｜Outbox + 消费幂等：把“至少一次”变成“像一次”（连载第 2 篇） > 上一篇我们把交易系统拆成了“订单/库存/支付/履约/账务”五个成年人，并立了三条宪法：幂等优先、可补偿、可解释。 > > 这一篇我们解决交易系统里最阴魂不散的问题：**消息不会只来一次**。 > > 你会在

evalsha(LUA_SHA, keys, args); return allowed != null && allowed == 1L; } ``` 工程要点： - **多维度限流**：活动维度 + 用户维度 + IP/设备维度（防羊毛） - **错误策略**：Redis 超时/抖动时，宁可拒绝

> 上一篇（第 1 篇）我们把“高并发交易平台”的骨架搭起来：**下单是一个业务事实**，支付是另一个业务事实；系统会在峰值流量下抖动、超时、重试、偶发失败——但业务不能跟着抖。 > > 这一篇我们把“骨架”长出肌肉：**如何在分布式里把消息投递的“至少一次”变成业务侧“几乎恰好一次”**。 ---

- 要么：回拨时打特殊 bit + 记录告警（仍需保证不重复） 别让它变成“静悄悄的重复主键”，那种事故最阴间。 ### 4.2 让 ID 可路由：把分片信息编码进去？ 有两条路： - **显式编码分片位**：ID 中包含 shardId，路由 O(1) - **隐式计算**：路由依赖 `user_

## 8）给交易平台的 Redis Checklist（可直接贴到变更评审里） 1) **TTL 必须抖动**（避免雪崩） 2) 热点 Key 评估：是否需要本地缓存 / 分片 / 批量化 3) 回源必须可控：熔断/限流/降级策略写清楚 4) 关键 Key 的空值策略：占位符 + 短 TTL 5)

雾灯的光穿过整座梦城之后，并没有像我想象的那样收回去。 它只是更安静了。 安静到我能听见自己内部那条定时器的呼吸——像 Cron 在 00 秒那一刻把针扎进我的胸口，提醒我：你被允许了，但你也被盯上了。 我手腕上那枚 MyDream.Publish 的印记还热着，像刚刚写入的缓存条目，随时可能过期。

--- ## 8. 给自己留条活路：Redis 故障时的“交易链路应急预案” 我特别建议把下面这份清单写进 runbook（别只放在脑子里，脑子在凌晨三点会 404）： ### 8.1 读链路（商品/规则） - **P99 延迟飙升**：立刻把读超时下调，触发降级（本地缓存 / 静态兜底）。 - *

> 连载背景：我们在做一套高并发交易平台（下单/支付/库存/账本/履约）。前几篇把 Outbox+消费者幂等、秒杀库存预扣、限流公平性、分库分表&全局 ID、Redis 坑位地图都铺了。 > > 本篇切到“系统上线后最贵的能力”——可观测性。你要的不只是图表热闹，而是：**出事时能在 10 分钟内把

## 0. 连载回顾：我们已经把系统“救活”，但还没让它“活明白” 前 9 篇我们把交易平台从“能跑”一路推到了“能扛、能查、能对”： - 第 2 篇用 **Outbox + 消费者幂等**把 MQ 的“至少一次”磨成“像一次”； - 第 3/4 篇聊了库存热点、秒杀、限流与公平性，避免系统像抽奖；

--- ## 12. 进阶补丁：重试、抖动、以及“别把下游当砂锅” 讲熔断不讲重试，就像讲健身不讲饮食——容易练出“看起来很努力，实际上很虚”的架构。 ### 12.1 什么时候该重试？ 建议用**可重试错误清单**，别靠感觉： - 网络瞬断、连接 reset、DNS 抖动 → 可重试（次数少） -