大促全链路稳定性复盘：
压测发现、流量治理与保障闭环

1大促全链路压测现场

陈默（化名）团队负责某电商平台大促稳定性。系列前序已落地秒杀架构、多级缓存、可靠性模式与可观测大盘，但大促零点要求这些能力在真实拓扑上同时成立。大促前一周进入 T-7 全链路压测窗口：目标是在不伤害真实用户的前提下，用染色流量走完整下单-支付-履约路径，验证容量模型与治理规则。行业公开材料中，头部电商曾提出「逆流而上」思路——在业务仍处高位、依赖链路与大促一致的生产环境做压测，而非在缩容预发做理想态测试。

指挥室设定：预估零点峰值约 8 万 QPS（合成假设），分三波注入——20:00 预热 30%、22:00 爬坡 60%、23:30 冲刺 90%。SRE 要求各域 P99 RT 不超过基线 1.5 倍、错误率低于 0.1%、下游 MQ Lag 不超过 5 分钟。21:17，第一波尚未结束，告警面板开始变红。

三告警看似独立，根因链是：染色链路不完整 → 无效流量打到生产热点 → 限流未全量生效 → 下游被击穿。指挥长暂停压测注入，但已产生脏数据需 2 小时清理——若发生在 11·11 零点前 2 小时，业务后果不可接受。陈默复盘时意识到：全链路压测的价值不仅是「QPS 能不能上去」，更是在真实依赖与发布态下暴露染色泄漏、治理未生效、预案不可执行三类系统性风险。

复合故障的可怕之处不在于单点算力不足，而在于观测面分裂：压测大盘显示 QPS 达标，订单库连接池却打满；网关监控显示流量平稳，Sentinel block 计数几乎为零；影子对账任务误报偏差，而真实用户订单量并未异常。没有跨层染色标与规则版本 hash，值班工程师会在三个控制台之间往返，每一层都觉得自己已执行预案，整体却仍在恶化窗口内。

1.2 22:40：扩容救不了规则漂移

团队紧急水平扩容订单 Pod 与 DB 只读实例，RT 短暂回落，但 22:40 第二波爬坡时错误率再次上升。根因并非算力不足：Sentinel 热点参数限流在容器重建后从本地缓存加载旧版 JAR 内嵌规则，未从控制台拉取最新活动 SKU 列表。热点 SKU 从 200 个扩到 2000 个，限流名单仍覆盖旧集合——新爆款无保护，DB 行锁再次堆积。这一环说明：大促压测不仅要测容量，还要测配置与规则的发布一致性。

1.3 五条根因链

暂停注入后，架构组抽样 500 条失败请求，归纳五条可复现根因链：RPC 边界染色丢失——Dubbo 泛化调用未透传 Attachment，库存侧按生产路径扣减；修复方向是框架层强制 RpcContext 透传，Consumer 端无标拒绝写。读写分离延迟放大——主从延迟在压测写入高峰达 8s，用户重复提交触发幂等键冲突与补偿 Job 风暴；大促期间核心读路径应切强一致或缩短重试窗口。批任务与压测抢资源——23:00 定时对账 Job 与第二波重叠，DB IO 饱和；T-14 起批任务窗口须避让表，大促周仅保留 P0 对账。Trace 采样误配——为省成本将采样降至 0.1%，指挥室无法定位慢调用；压测与零点应强制 100% 采样或 tail-based sampling。依赖方未联压——风控接口仍走同步强校验，RT 300ms+ 占下单链路 60%；大促模式应异步风控加事后拦截，或纳入联压扩容。这五链说明「全链路」包含旁路任务、框架默认值、二方包行为，任何一环未纳入脚本都会在零点以复合故障回归。

1.4 压测指挥室前十分钟

OnCall 前 10 分钟不要急于扩容，先回答三问：染色——压测标缺失率是否为零，生产表是否有时段内异常增量？治理——429/block 率是否与预期水位匹配，各集群规则 hash 是否一致？漏斗——CDN 到 DB 各层 QPS 是否守恒，是否存在下游 QPS 超过上游通过量（泄漏或重试风暴）？陈默团队在 21:20 若先停注入跑对账，可缩短脏数据清理窗口；但指挥长当时选择「先扩容再查」，导致第二波在问题未修复时继续注入，扩大了污染面。这一决策在复盘中被标记为反模式：压测现场暂停注入优先于扩容，除非已确认染色完整且瓶颈纯算力。

1.5 若把同一现场移到零点

tabletop 推演：假设 Part 1 三告警未在 T-7 发现，零点真实流量叠加秒杀。21:17 的 DB 连接池打满将在 90 秒内扩散为支付回调堆积、库存负数告警、客服进线激增。429 未生效意味着用户仍看到「可下单」，体验劣于「排队页」——治理失败的产品代价往往大于技术 downtime。预案 403 则 RTO 从 5 分钟滑到 30 分钟以上。压测窗口存在的理由：把零点风险翻译成 T-7 的可修复工单。

版本说明：文中 QPS、Lag、连接池等数字若无特别标注均为合成示例，用于说明量级与排障顺序。机制描述以公开稳定性工程实践与《亿级流量网站架构核心技术》限流章节为准。阅读前提：你已理解全链路压测、Sentinel 限流与 MQ Lag；本文聚焦大促场景下压测-治理-保障如何闭环。

2染色、影子与隔离不变量

全链路压测的核心不变量是：压测流量在任意存储层不得与生产终态混淆。典型实现包括流量染色、影子库表、外联 Mock 与数据回收四件套。架构评审应问：「若 Header 丢失，默认走生产还是拒绝？」——默认走生产是事故温床。

流量染色由网关或 RPC 框架注入 X-Shadow-Flag / traffic-mark=stress，全链路透传；缺失标则拒绝进入压测写路径或强制走影子。影子库包括 MySQL 影子 schema、Redis 独立 key 前缀、MQ 独立 Topic 或 Tag；写路径由 MyBatis 插件或分库分表中间件按标路由。支付、物流、短信等不可对真实第三方压测，需沙箱或录制回放——未 Mock 的外联是常见泄漏点。

压测准入不是一次性网关配置，而是每条新链路的 CI 门禁。陈默案例中营销域新接口绕过染色，即违反变更准入的典型反例。大促前 T-14 起，任何写路径变更须附带染色检查项：无标默认拒绝、影子对账脚本、外联 Mock 清单三项缺一不可。

2.2 压测观测维度

压测指挥不应只盯 QPS 与 RT。有效观测维度包括：染色完整性（压测标缺失率、影子/生产写入比）；漏斗各层（CDN → 网关 → 业务 → DB 各层 QPS 与拒绝率）；治理生效（429/503 占比、Sentinel block 计数、规则版本 hash）；异步堆积（MQ Lag、Consumer 重试率）；数据一致性（影子对账、库存三角校验）。压测报告必须回答：在预估峰值 N 倍注入下，哪一层先触顶、触顶时错误形态是什么、治理是否按设计介入。

2.3 压测注入模型

合格压测不是阶跃式一次打到 100%，而是模拟预热爬升、整点脉冲、秒杀叠加、支付回调第二波。复合场景采用三波注入，第三波叠加 10% 秒杀 SKU 混合比例，验证主站与秒杀域资源隔离。若秒杀 Pod 与主站 Pod 共享节点池，压测中会看到 Node 级 CPU steal 上升，提示需工作负载分离或独立节点池。注入端应分散多地域与 ISP，避免压测机房网络成为假瓶颈；保留 5%–10% 无标对照流量走生产只读路径，对比染色链路与真实链路 RT 差异——若差距过大，说明影子路径与生产路径代码分支不一致，压测结论失效。

2.4 外联 Mock 与数据回收

支付、物流、短信、实名认证等不可对真实第三方发起压测流量。典型做法包括：沙箱环境、录制回放、Mock Server 与契约测试。陈默团队曾遗漏物流轨迹回调 Mock，压测中真实调用承运商接口，触发对方限流并收到合规警告——此类遗漏在零点虽不一定重现，但说明依赖矩阵每一行外联都须标注「压测态行为」。数据回收是压测结束后的强制 Gate：批量清理影子数据，跑对账确认生产行数零增长，库存回滚走台账而非 DELETE。压测污染生产时的技术善后顺序已在第六章展开；此处强调对账必须是自动化的，对账未通过则不允许进入下一波注入。

2.5 变更准入三门禁

大促前 T-14 起，任何写路径变更须通过稳定性委员会三门禁：染色门禁——新接口是否接入压测路由，无标默认行为是否明确；限流门禁——是否配置网关与 Sentinel 规则，是否纳入全集群 hash 巡检；预案门禁——是否影响 L1–L4 触发条件，是否需要更新 dry-run。营销域新接口绕过染色，三门禁均未执行，属于流程失效而非个人疏忽。架构师在评审时应要求变更单附带压测脚本 diff，而非仅代码 diff。

3压测-治理-保障闭环

大促稳定性不是三个独立项目，而是时间轴上的闭环。压测（发现）在生产等价环境验证容量模型、依赖瓶颈、染色与数据隔离，输出第一层触顶组件清单与容量水位表。治理（削峰）在入口到数据层之间设置限流、熔断、降级、隔离，把流量整形到系统可持续处理范围；阈值来自压测曲线而非拍脑袋。保障（托底）是预案、值班、多活切换、数据修复与对外公告；当治理仍不足时，用有损服务换可用性，并保证 RTO 可执行。

三者缺一环：只压测不治理，峰值仍打穿；只治理不压测，阈值无据；只写预案不演练，零点无人敢按红色按钮。陈默团队在 T-7 后建立反馈边：压测瓶颈清单直接驱动治理阈值调整；治理 block 率与 429 曲线回灌压测脚本验证；预案 dry-run 结论修正压测验收 DoD。

组织与流程是闭环的另一半：T-30 架构评审与依赖梳理，输出依赖矩阵与容量初估；T-21 各域交付治理规则清单与水位草稿；T-14 冻结非必要变更，稳定性委员会开始审批 hotfix；T-7 全链路压测，输出瓶颈清单与开放风险项；T-3 预案 sign-off 与值班表白名单确认；T-1 仅允许 P0 hotfix 且必须 80% 峰值烟雾压测；T-0 作战室分级响应，对外公告模板就绪。每条 T-14 后新链路须稳定性委员会审批——检查染色、限流、预案三项是否齐全。技术闭环无流程闭环，仍会重演陈默式营销接口绕过染色。

3.2 反馈边与工程变更单

压测未通过的项须产生工程变更单，而不是只更新 PPT。陈默团队在 T-7 后关闭了三类工单：全集群规则 hash 巡检上线、营销域补接压测路由、预案平台大促值班账号白名单。每项工单附带复测标准——如下次压测 429 占比在 70% 容量时须大于 5%，规则 hash 不一致集群数须为零，L2 dry-run RTO 须小于 5 分钟。开放风险项若无法在 T-0 前关闭，须 stability committee sign-off 接受，并绑定零点额外观测与人工兜底方案，禁止「已知风险无 owner」带入作战室。

3.3 「逆流而上」的工程边界

公开材料中的「逆流而上」常被误解为「不设闸硬扛峰值」。工程正确含义是：在业务仍处高位、依赖链路与大促一致的生产环境做验证，同时染色隔离、分层限流与预案托底必须就绪。没有闸的逆流是冒险；有水位与预案的逆流是验收。陈默指挥室在 21:17 后的正确顺序应是：停注入 → 对账 → 查染色与规则 hash → 修复 → 再注入，而非先扩容掩盖泄漏。这一顺序应写入压测 Runbook 首页，作为指挥长 checklist 第一项。

4流量治理分层设闸

流量治理不是「网关限个流」。资深架构师按漏斗分层设闸，每层职责不同。陈默案例中「429 异常低」本质是网关层闸未全量生效，而 DB 层尚无独立热点保护，瓶颈下沉到最贵一层。正确做法：压测画出 RT 陡增点，把限流阈值设在陡增点之前，并配置多层冗余——网关挡无效流量，Sentinel 挡慢依赖，DB 前缓存挡读，MQ 挡写放大。

4.2 降级谱系

流量治理终态是降级——主动关闭或简化功能以保全核心交易。无损降级：关闭个性化推荐、延长 CDN 缓存 TTL。弱有损：关闭评论实时刷新、延迟非关键推送。强有损：排队页、关闭下单仅保留浏览。每一档须在压测中实测切换耗时与错误率曲线，并绑定 L1–L4 预案。陈默 L2 静态化属于强有损前置形态；未演练则业务方零点拒绝切换。

4.3 规则生命周期

限流规则、热点名单、预案脚本应与应用代码一样走版本化、灰度、回滚。推荐：规则存 Git/Nacos，deploy 后自动执行规则一致性巡检 Job——对比各集群内存规则 hash 与期望 hash，不一致则告警并阻断下一批发布。Sentinel 本地 fallback 与控制台规则并存时，必须在架构层写死优先级，禁止实例各自为政。Kubernetes 滚动发布、Nacos 长轮询、Sidecar 热更新三条路径若混用，极易出现部分实例行为不一致，在压测流量下被放大为随机 500。大促前最后一次规则发布应在 T-3 完成，T-1 仅允许 hotfix 且必须复跑 80% 峰值 15 分钟烟雾压测。Part 1 中 2/8 网关灰度未全量，本质是把规则发布当成了低风险的配置 tweak，而未纳入与代码同级的发布门禁。

4.4 重试预算与舱壁

治理层常被忽视的一环是重试预算。超时过短加无上限重试，会在压测中形成调用链 QPS 放大比大于 3 的重试风暴，网关限流未触发但下游已被放大流量打穿。架构师应为核心链路配置：单次请求最大重试次数、指数退避上限、熔断后 half-open 探活间隔，并在压测中观测放大比。线程池舱壁与 Sentinel 慢调用隔离配合，可防止支付 Mock 超时拖死整个 Tomcat 线程池——陈默团队在 22:40 第二波中曾出现订单服务因风控超时而级联超时，根因是舱壁未按依赖域拆分。

5容量模型与水位校准

压测输出容量水位表：每个核心服务在目标 RT 下的 max QPS、CPU/内存/GC 拐点、依赖下游 limit。大促目标容量 = 预估峰值 × 安全系数（常见 1.3–1.5）。治理阈值通常取 0.6–0.8 × 目标容量，留 headroom 给重试、爬虫、突发热点。切忌把压测「跑到的最大 QPS」直接当零点目标——应取SLO 仍满足的最大可持续 QPS作为水位线。

「水位」把模糊「扛不住」翻译成可告警数字。复合场景推荐三类核心水位：同步路径（网关 5xx 率、P99 RT、DB 连接池使用率大于 85% 持续 2min）；异步路径（MQ Lag 大于 5min 黄色、大于 15min 红色暂停非关键 Producer）；资源路径（CPU 大于 75%、GC pause 累计、磁盘 IO 饱和度）。水位阈值应在压测中校准：80% 目标峰值时记录各指标设为黄色线；100% 时设为红色线。

零点作战室大屏只展示「距红色水位还有多少 headroom」，减少临场心算。压测期间应用「大促模式」告警阈值，避免演练触发真实 P0 误报或阈值过松漏检。

5.2 压测验收 DoD

1. 染色完整率 100%，压测结束生产核心表零增量（对账证明）。
2. 目标峰值 90% 注入下，核心链路 SLO 满足（错误率、RT、Lag 均在预案水位内）。
3. 网关 / Sentinel / 热点规则全集群版本一致（抽检 + 配置 hash 比对）。
4. 至少执行一次 L1–L2 预案 dry-run，RTO 小于预案承诺。
5. 输出瓶颈清单与跟进 owner、截止日期——未关闭项视为大促风险项。

5.3 容量水位表示例结构

每个核心域一行，列包括：服务名、目标 RT 下 max QPS、CPU 拐点、内存/GC 拐点、依赖下游 limit、安全系数后目标容量、治理阈值（0.7×目标）、第一层触顶组件、触顶时错误形态、建议动作。陈默团队订单域在压测中记录：max 可持续 QPS 约 5.2 万（合成），触顶组件为 DB 热点行锁，触顶形态为连接池等待而非 5xx——说明瓶颈下沉到数据层时，网关 429 可能仍很低，须用连接池与行锁监控补位。水位表应作为大促评审附件，与 SLA 文档交叉引用；SLA 变更须附带最近一次压测实测值，禁止纸面容量。

5.4 与 HPA 的对齐

资源路径水位须与 HPA 策略对齐：若 HPA 基于 CPU 75% 扩容，而压测显示连接池在 CPU 60% 时已触顶，自动扩容将滞后于流量尖刺。推荐在压测中同时记录「指标触顶时间」与「HPA 扩容生效时间」的 delta，若 delta 大于 3 分钟，应预扩容或降低治理阈值，而非依赖 HPA 救场。大促零点常见尖刺形态是整点脉冲加支付回调第二波，HPA 冷却时间可能错过第一波峰值——T-1 预扩容与 T-0 手动 hold 副本数应写入作战室 SOP。

6预案分级与 dry-run 验证

预案不是 Word 文档，而是可执行、可度量、有人负责的状态机。陈默 L2 dry-run 403 说明：预案验证 = 真实账号 + 真实权限 + 真实依赖，在压测窗口执行，而非 tabletop 讨论。

零点作战室需要单页升级矩阵：行是水位黄/红，列是域（网关/订单/支付/MQ），单元格写谁决策、谁执行、最长等待时间。MQ Lag 红色 5 分钟，SRE 有权无需业务审批暂停非关键 Producer；订单错误率红色 3 分钟，需业务值班与 SRE 双签后触发 L3。压测期间应用作战室 lite 模式预演：真实值班人员走一遍告警 → 决策 → 执行 → 验证，记录每步耗时。任何一步超过预案 RTO 的 50%，则 T-7 至 T-0 必须修复。

6.2 产品 sign-off 与有损文案

L2 排队页、L3 关闭下单等强有损预案，必须在 T-14 前由产品 sign-off 文案与触发条件，避免故障时现场争论「能不能关下单」。sign-off 应包含：用户可见提示语、预计恢复时间沟通口径、客服 FAQ、与 L4 切换的边界。陈默团队 L2 静态化文案在 T-3 才定稿，导致 dry-run 时业务方对「静态页是否展示预计恢复时间」仍有分歧——此类分歧在零点会被放大为决策延迟。架构师应推动有损预案作为产品需求项，而非 SRE 内部文档。

6.3 压测失败善后 SOP

压测污染生产时，善后顺序：立即停止注入并冻结相关写 API；对账脚本圈定污染订单 ID 范围；业务确认是否可批量关单或标记作废；库存回滚走台账而非 DELETE；支付回调须核对是否产生真实扣款，若有则走退款 SOP；发布事故复盘与染色门禁加固。复合场景中 2 小时清理窗口若在 T-0 发生，将直接冲击 GMV——因此压测对账必须是自动化 Gate。陈默团队在 T-7 后将对账脚本接入压测控制台，下一波注入按钮须对账通过才可用，从工具层消除「先跑再说」的人为绕过。

7与系列前序能力的衔接

大促稳定性是系列收束题：秒杀（T12）解决单点链路，异地多活（T15）解决机房级容灾，可观测（T09）与可靠性模式（T10）解决日常运行态——零点要求四者同时成立且纳入同一压测脚本。

• 秒杀（T12）：零点叠加秒杀；压测须含预扣、MQ 异步、三角对账，否则主站扛住、库存域击穿仍会发生。
• 多级缓存（T11）：读降级依赖缓存命中率；压测验证击穿/雪崩策略在大促参数下是否生效。
• 可靠性模式（T10）：熔断、重试、超时在压测中常因重试风暴放大流量——需全局重试预算与幂等。
• 可观测（T09）：水位告警、分级 On-call 依赖统一指标命名；压测与零点共用 drill_id 贯穿日志与链路。
• 异地多活（T15）：压测应含单单元摘流演练，验证调度器与数据同步延迟；跨单元调用比例失控会导致结构性不均衡。

单元化是横向扩展手段：按用户 ID 或地域划分流量到独立单元，单元内闭环读写。压测流量按单元注入，观察单单元极限与全局调度。架构师应问：最坏单元故障下，剩余单元能否承接 redirected 流量且 SLO 不破？ 答案必须来自压测数据，而非设计文档。若「本应本地读」的请求在压测中大量跨单元，说明路由表或缓存失效，零点会出现某单元过热而其他单元空闲的结构性不均衡——此类问题无法靠全局扩容解决，须回到单元路由与缓存亲和设计。

7.2 大促模式下的可观测差异

T09 可观测体系在日常与压测/零点须切换「大促模式」：告警阈值、采样率、Dashboard 默认视图、On-call 升级路径均不同。日常阈值过松会在压测中漏检连接池触顶；过紧则演练触发真实 P0 误报。推荐为 drill_id 贯穿日志、链路、预案审计，压测开始时生成 drill_id 并注入所有相关系统，事后可用同一时间线对齐「规则 hash 变更」「注入波次」「429 曲线」三条曲线。陈默团队在 21:17 因 Trace 采样 0.1% 无法快速定位营销域绕过路径，若有大促模式强制采样，根因定位时间可缩短一个数量级（合成推断，须本环境验证）。

8大促稳定性 FMEA 与决策框架

框架篇占约一成，目标是把闭环落到可执行决策问题，而非替代压测数据。架构师在大促中须回答四个问题：压测做在生产还是预发——依赖链路与数据规模一致时优先生产染色压测；阈值谁拍板——压测数据 + SLO 反推，业务定可接受降级范围，SRE 定技术水位；零点允许多大有损——提前产品 sign-off L2/L3 文案；变更冻结后如何修 P0——仅 hotfix 通道，必须带压测回归与染色检查项。

大促前每个核心域交付四页纸等价物：容量水位表、治理规则清单与版本、预案 runbook 与 RTO、压测报告与开放风险项。评审通过条件：不存在未接入染色的写路径；不存在仅单集群验证过的限流；L2 以上预案在 T-7 前至少演练一次。

# 压测后染色对账 Gate（模式通用，表名按实际调整）
mysql -e "
  SELECT COUNT(*) AS prod_delta FROM orders
  WHERE created_at BETWEEN @stress_start AND @stress_end
    AND shadow_flag = 0 AND source != 'stress';
"
# prod_delta 须为 0 才允许下一波注入

8.2 零点指挥 SOP 摘要

9混沌注入与压测观测

仅加 QPS 不足以验证保障链。压测中应注入：单 AZ 网络延迟、Redis 主从切换、支付 Mock 超时、Nacos 短暂不可用。观察治理是否误判、重试是否风暴、预案是否可触发。陈默案例中 Sentinel 加载旧规则，可通过随机 kill 30% Pod 暴露——新实例与旧实例行为不同，说明规则源未统一。

压测观测除黄金指标外，必须监控：染色标缺失率、规则版本 hash 分布、DAG/预案步骤耗时、回调 URL 探活。Postmortem 必填：重试放大估算、Lag 峰值与恢复时间、各阶段 RTO 实测、对账差额。与 T09 衔接：大促指标应进入统一 Grafana 大盘，与 DB 连接池、跨 Region RPC 比例同屏——单独网关绿点无法发现「429 应触发而未触发」。

混沌实验须在 shadow 或与生产同构的压测环境执行，shadow 需与生产同构配置，否则结论无法迁移。季度无预告小流量演练可与 T-7 全链路压测合并，但须明确标注「有预告联调」与「无预告检验响应速度」的区别——前者验能力，后者验组织。Postmortem 模板应固定字段：注入波次、第一层触顶组件、规则 hash 快照、429 曲线、Lag 峰值、dry-run 是否执行、开放 risk 关闭情况，便于年度对比与架构债追踪。

9.2 演练级别与通过标准

公开分享中常提到单元化、全链路压测平台、智能限流——架构师应提取机制（染色、影子、漏斗治理、预案分级），而非把「零故障 N 年」当作可复用容量数字。每家企业的 SKU 结构、支付链路、合规约束不同，水位必须自测，机制可以借鉴。

10大促保障检查表与延伸阅读

带走三句话：第一，压测在生产等价环境发现真实瓶颈，而非预发理想态。第二，治理阈值来自压测水位，规则发布与代码同级门禁。第三，预案 dry-run 在 T-7 前证明可执行——陈默 403 的主因是权限未演练，而非技术方案缺失。

「逆流而上」的工程含义是在高位真实环境验证，不是冒险不设闸；闸的阈值来自压测水位，不是宣传稿峰值。检查表不是 paperwork，而是 Part 1 复合事故中缺失条目的制度化——缺一项，T-7 压测就可能重演为 T-0 事故。

10.1 大促保障检查表

10.2 延伸阅读

1. BOOK周志明《凤凰架构：构建可靠的大型分布式系统》— 容量、韧性与失败设计章节
2. BOOK李运华《亿级流量网站架构核心技术》— 大促限流与全链路压测相关章节
3. DOCAlibaba Sentinel 1.8.x — 限流、热点参数、集群流控官方文档
4. SERIES同系列 T09《可观测体系建设》— 大促模式阈值与 drill_id
5. SERIES同系列 T10《可靠性模式》— 熔断、重试预算与幂等
6. SERIES同系列 T12《秒杀架构》— 库存预扣与三角对账
7. SERIES同系列 T15《异地多活》— 单元摘流与流量调度