架构案例与项目方案库

1. 使用方式

本文件用于把技术知识转成项目级架构方案。面试时不要只说“我用了 Redis（远程字典服务）”或“我用了 MQ（消息队列）”，而要按固定结构讲：

背景 -> 目标 -> 架构 -> 核心流程 -> 失败场景 -> 兜底 -> 观测 -> 取舍 -> 结果

2. 案例一：库存防超卖架构方案

2.1 背景和目标

WMS（仓储管理系统）或电商订单系统中，库存扣减必须保证不超卖，同时还要扛住高峰下单流量。

目标：

• 库存不能扣成负数。
• 高峰请求不能拖垮数据库。
• 重复请求不能重复扣减。
• 失败后能释放库存或补偿。

2.2 架构方案

sequenceDiagram
    participant U as 用户
    participant O as 订单服务
    participant R as Redis（远程字典服务）
    participant S as 库存服务
    participant DB as MySQL（关系型数据库）
    participant MQ as MQ（消息队列）
    U->>O: 提交订单
    O->>O: 幂等校验
    O->>R: 热点库存预扣
    R-->>O: 预扣结果
    O->>S: 请求冻结库存
    S->>DB: 条件更新库存
    DB-->>S: 冻结成功/失败
    S->>MQ: 发送库存事件
    MQ-->>O: 异步补偿/确认

2.3 关键设计

2.4 面试话术

库存防超卖我会分两层：性能层和正确性层。Redis（远程字典服务）负责热点预扣和削峰，MySQL（关系型数据库）条件更新负责最终不超卖。订单请求必须有幂等键，库存冻结有状态机，支付超时后释放冻结库存。如果消息或服务失败，通过本地消息表、补偿任务和库存对账修正。

3. 案例二：支付资金一致性方案

3.1 背景和目标

支付系统最重要的是资金正确性。外部支付通道可能重复回调、延迟回调、乱序回调，系统必须保证订单状态、支付流水和账务一致。

3.2 架构方案

flowchart TD
    A["支付发起"] --> B["创建支付流水"]
    B --> C["调用支付通道"]
    C --> D["等待 Webhook（回调通知）"]
    D --> E["验签和防重放"]
    E --> F["幂等入库"]
    F --> G["状态机流转"]
    G --> H["发送支付成功事件"]
    H --> I["库存/订单/账务消费"]
    G --> J["对账任务"]
    J --> K["差异补偿"]

3.3 关键设计

• 支付流水号全局唯一。
• 通道事件 ID（标识）做幂等。
• Webhook（回调通知）必须验签、防重放。
• 状态机限制非法流转。
• 支付成功事件通过 MQ（消息队列）通知下游。
• 每日对账发现差异并补偿。

3.4 面试话术

支付一致性不能只靠回调成功。我的设计会先保证支付流水可审计，回调验签后按通道事件 ID（标识）幂等入库，订单状态通过状态机流转。下游库存、账务、通知走 MQ（消息队列）最终一致，消费端必须幂等。最后通过对账和补偿任务兜底，保证资金结果能被发现和修正。

4. 案例三：跨境物流履约架构

4.1 背景和目标

跨境物流链路长，涉及下单、面单、轨迹、清关、签收、异常件。外部接口慢、不稳定、状态回传延迟是常态。

4.2 架构设计

4.3 面试话术

跨境物流不能假设外部系统稳定，所以我会把外部调用从主链路中隔离出来。面单拉取、轨迹同步使用独立线程池和 MQ（消息队列）削峰，状态用状态机控制，重复轨迹用业务 key（键）幂等，失败进入重试和死信。查询侧可以用 Elasticsearch（搜索引擎）提升体验，但主状态仍以数据库为准。

5. 案例四：IoT（物联网）报警风暴治理

5.1 背景和目标

IoT（物联网）设备异常时可能短时间上报大量重复报警，导致消息堆积、告警刷屏、人工无法处理。

5.2 架构方案

flowchart TD
    A["设备报警"] --> B["接入层限流"]
    B --> C["MQ（消息队列）削峰"]
    C --> D["报警聚合服务"]
    D --> E["窗口去重"]
    D --> F["规则分级"]
    F --> G["通知渠道"]
    D --> H["报警存储"]
    H --> I["报表和复盘"]

5.3 关键设计

• 以 deviceId（设备标识） + alarmCode（报警编码） + window（时间窗口） 做聚合 key（键）。
• Redis（远程字典服务）做窗口计数和去重。
• MQ（消息队列）削峰，避免接入层直接打爆处理服务。
• 告警按级别路由到不同通知渠道。
• 告警风暴触发自动降噪策略。

5.4 面试话术

报警风暴治理核心不是简单限流，而是让重要报警不被噪声淹没。我会在接入层限流，MQ（消息队列）削峰，处理层做时间窗口聚合和去重。Redis（远程字典服务）保存短期计数，数据库保存最终报警记录。高频重复报警降噪，严重报警仍然穿透通知。

6. 案例五：异步任务与 Runner（执行器）调度

6.1 目标

异步任务系统要解决任务可靠执行、失败重试、并发控制、状态可见和人工补偿。

6.2 关键设计

6.3 面试话术

Runner（执行器）调度我会重点保证任务不丢、不重、可追踪。任务先落库，调度器按分片拉取，用乐观锁抢占执行权。执行失败按错误类型决定是否重试，重试要退避和限次，超过次数进入人工补偿。不同任务类型拆线程池，避免慢任务拖垮核心任务。

7. 高频追问清单

1. 库存预扣成功但订单创建失败怎么办？
2. 支付回调重复到达怎么办？
3. MQ（消息队列）消息发送失败怎么办？
4. 消费者处理成功但 ACK（确认）失败怎么办？
5. 物流轨迹乱序到达怎么办？
6. 报警风暴导致 MQ（消息队列）积压怎么办？
7. Runner（执行器）任务执行一半服务重启怎么办？
8. 分库分表后跨库查询怎么办？
9. 灰度发布发现错误如何回滚？
10. 如何证明你的架构方案有效？

8. 本模块复习清单

• 能完整讲库存防超卖架构。
• 能完整讲支付资金一致性架构。
• 能完整讲跨境物流履约架构。
• 能完整讲 IoT（物联网）报警风暴治理。
• 能完整讲 Runner（执行器）调度。

9. 精通级分册入口与学习路线

本节是旧根的只增量收口入口。旧正文保持原样，其基线 SHA-256（安全散列算法）为 5ac2a70ebf7e2f110952db5f1f2b1c5ef187913d55afa1316d149163c4954a8d；后续学习、引用与验收以分册为准，不把本入口中的汇总数字倒写成已被源码或线上记录证实的项目事实。

9.1 九篇分册与正式图

9.2 E0 至 E3 事实边界

同一案例可以同时含有不同等级的陈述。回答时先说明事实边界，再讲不变量、失败路径、验证和恢复；不能用更多图表、更多组件或更长口述替代证据。

9.3 推荐顺序与快速复习

推荐顺序是 00 -> 01 -> 02 -> 03 -> 04 -> 05 -> 06 -> 07 -> 08：先建立索引和证据边界，再依次完成交易正确性、外部履约、异步执行、告警治理和数据产品的纵向训练，最后用评审与综合题把方案收口。

快速复习时，先读 00 的事实卡和十一字段方案合同；随后按当前面试项目选择 01、02、03、05 或 06 中的一篇，练习“背景、约束、不变量、主链、失败、止血、恢复、证据边界”；最后读 08 的失败路径、迁移与综合题。04 和 07 用于补齐异步批处理、数据责任和多模型选型追问。

9.4 统计口径与复算结果

统计只覆盖下表的 00 至 08 九篇正式分册，不把受保护旧根正文计入合计。知识标记按知识小节标记计数；六字段题按题目行计数；口述答案按对应字段计数；Mermaid（图表语法）按图表围栏计数；时序图按 sequenceDiagram（时序图声明） 计数；标准表按表头紧邻分隔行计数；数据演绎按对应编号标题计数；正式图按非空的 PlantUML（开源建模工具）与 PNG（便携式网络图形）文件计数。

正式图资产为 9 个 PlantUML（开源建模工具）文件和 9 个 PNG（便携式网络图形）文件；验收同时要求两类文件均非空、对应的 Mermaid（图表语法）正文可真实渲染、链接有效，并以实际审计输出为准。