第 36 章 场景设计题的答题框架

1
2
3
4
5

POST /api/v1/seckill/order  幂等键 (userId, activityId, skuId)；另带 requestId 做请求级去重
    Body: { activityId, skuId, requestId }；返回 200 { orderNo, status=PENDING } 或 409 ALREADY_JOINED
GET  /api/v1/seckill/result 查询型接口天然幂等，前端轮询用它（Params: requestId）
GET  /api/v1/activity/{id}  读接口，直接走缓存
POST /api/v1/pay/callback   第三方回调，必须按 outTradeNo 幂等（对方会重复推）

1
2
3
4

① QPS  平均 QPS = 日请求总数 / 86400；峰值 QPS = 平均 × 峰值倍数（常见 3~5 倍）；写 QPS 要单列：只有写请求消耗数据库写入与 binlog
② 存储 日增 = 日增条数 × 单条字节 × 放大系数；放大系数含索引（1.3~1.5 倍）、副本（1 主 2 从即 3 倍）、InnoDB 页 16 KB 的行开销与填充率（实测 50%~70%）；总量 = 日增 × 保留天数
③ 带宽 出向 = 读 QPS × 平均响应大小 × 8（× 8 是转 bit/s）；入向 = 写 QPS × 请求大小 × 8；注意读放大：一次页面请求往往触发 N 次后端调用
④ 连接数 用 Little 定律反推：L = λ × W（λ 为峰值 QPS，W 为平均处理耗时/秒）；连接池 / 工作线程数 ≥ L，并留 1.5~2 倍余量应对抖动

1
2
3
4
5
6
7

【QPS】日请求总数 = 1000 万 × 20 = 2 亿 ⟹ 平均 QPS = 2 亿 / 86400 ≈ 2300（验算 ✓）
  峰值 QPS = 2300 × 4 ≈ 1 万（倍数取 3~5 倍；若业务有整点抢购这类明显定点，应按"峰值分钟请求数 / 60"反算，不能套 4 倍）
【存储】日增裸数据 = 2000 万 × 1 KB = 20 GB；含索引 1.5 倍 → 30 GB/天
  逻辑数据年增 ≈ 7.3 TB，含索引 ≈ 10 TB，1 主 2 从物理占用 ≈ 30 TB — 单机放不下，必须分片
【带宽】设读:写 = 10:1，先算总峰值再拆，不能把 10 倍直接乘在均值上
  峰值读 QPS ≈ 9200 × 10/11 ≈ 8360，峰值写 ≈ 840；出向 = 8360 × 2 KB × 8 ≈ 134 Mbps，入向 = 840 × 1 KB × 8 ≈ 6.7 Mbps → 出向是瓶颈，静态内容与图片必须上 CDN
【连接数】W = 200 ms = 0.2 s，λ = 9200 ⟹ L = λ × W = 1840，即瞬时约 1840 个请求在处理中。若数据库连接池只配 200，其余在池外排队、延迟被放大一个数量级以上——"线程数与连接池怎么定"的答案：由 L 与下游承载能力共同约束，不是拍脑袋

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

① 前端 → ② 网关 → ③ 库存预热 → ④ Redis 原子扣减 → ⑤ MQ 削峰 → ⑥ 数据库最终扣减
① 前端：按钮点击后置灰（最廉价的过滤）；答题/验证码拉高机器人成本；静态资源走 CDN；本地倒计时，活动未开始不发请求
② 网关：活动维度令牌桶 + 用户维度 + IP 维度三重限流；黑名单与设备指纹防刷；库存已空的请求直接 302
   到售罄页。效果：把 10 万 QPS 压到后端可承受的 1 万
③ 库存预热：活动前把库存写入 Redis（权威数据源仍是 DB）；预热必须幂等，重复执行不能把库存翻倍；
   预热失败要告警并拒绝开抢，不能带着旧库存开卖
④ 原子扣减：Lua 脚本把"查重 + 判断余量 + 扣减"合并成一个原子步；禁止"先 GET 判断再 DECR"（两步
   之间有 TOCTOU 窗口）；失败直接返回售罄
⑤ MQ 削峰：下单请求入队，峰值写流量摊平到下游能消费的速率；前端不等待，改为轮询 result 接口或
   服务端推送；分区键用 skuId 保序，消费端按业务键幂等
⑥ 数据库最终扣减：UPDATE stock SET qty = qty - 1 WHERE sku_id = ? AND qty > 0，用影响行数判断
   成败（0 行 = 售罄，回滚 Redis 占位）；唯一索引 (user_id, activity_id, sku_id) 兜住重复单

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

库存 Redis 值为 1，两个请求并发到达，用"先查后减"：
  时刻  请求 A       请求 B       库存值
   t1   GET → 1                     1
   t2                GET → 1         1
   t3   判断 1>0 成立                1
   t4                判断 1>0 成立    1
   t5   DECR/SET 0                   0
   t6                DECR/SET -1    -1
  结果：卖出 2 件，库存 1 件 → 超卖 1 件
根因：GET 与 DECR 是两次独立往返，中间存在时间窗口。Redis 单线程保证的是"单条命令原子"，
      不是"两条命令之间不被插入"——这就是检查后使用（time-of-check to time-of-use, TOCTOU）竞态。

1
2
3
4
5
6
7
8
9

-- seckill_deduct.lua：Redis 执行脚本期间不处理其他命令，下面三步对外是一个原子操作，这是消除
-- TOCTOU 窗口的手段。单命令 DECR 也原子，但无法同时写占位记录。
local userId = ARGV[1]
-- 同一用户的重放必须直接拒绝，否则"扣库存成功但请求被重试"会凭空吃掉一件库存
if redis.call('SISMEMBER', KEYS[2], userId) == 1 then return -2 end   -- 已参与过，幂等返回
local stock = tonumber(redis.call('GET', KEYS[1]) or '-1')            -- KEYS[1]=库存 key
if stock <= 0 then return -1 end                                      -- 售罄
redis.call('DECR', KEYS[1]); redis.call('SADD', KEYS[2], userId)      -- KEYS[2]=去重集合
return stock - 1             -- 返回剩余库存，供前端展示

1
2
3
4
5
6

【超卖】卖出量 > 库存量
  根因：并发扣减非原子（"先查后减"，见上一节时序）；多实例各持本地库存副本各扣各的 → 可售总量被放大 N 倍；库存在本地缓存与 Redis 各一份却只更新一处
  修复：单一扣减入口 + 原子脚本 + 所有实例共用同一份 Redis 库存
【少卖】卖出量 < 库存量：库存被扣掉却没生成有效订单
  根因：Redis 扣减成功但 MQ 投递失败（网络抖动、broker 不可用），扣了库存又没建订单且无人回补；投递成功但消费端落库失败且重试耗尽；用户下单后超时未支付而占用到期无人释放；Redis 故障重启，未持久化的扣减丢失，用户侧却已看到"抢购成功"
  修复：扣减与投递之间用本地消息表 / 事务消息，保证"扣减 ⟹ 一定投递"；消费端失败重试 + 死信队列兜底；未支付订单用延迟消息在超时时刻回补（见第 33 章）；Redis 侧开启 AOF everysec 或使用可持久化部署

1
2
3

【302 链路】每次点击都经过服务端，统计完整：浏览器 ──GET /aB3xK──▶ 短链服务（缓存未命中则查 DB）
  ├─▶ 异步写点击日志（先入队，不阻塞跳转）    └─▶ 302 Location: 长链 ──▶ 源站
【301 链路】第 1 次点击服务端可见；第 2 次起浏览器命中本地缓存，请求根本不到服务端。结果：真实点击 100 万次，服务端只记录到第一次，数据失真

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

-- 主表：短码 → 长链。这是重定向的唯一查询路径，必须走主键
CREATE TABLE short_link (
    short_code VARCHAR(10)   NOT NULL COMMENT '62 进制短码；用 VARCHAR 而非定长，未来换方案不必搬迁表',
    long_url   VARCHAR(2048) NOT NULL,
    expire_at  DATETIME      NULL COMMENT 'NULL 表示永不过期；避免用 0 值表达"不过期"导致索引失效',
    created_at DATETIME      NOT NULL DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (short_code),
    KEY idx_long_url (long_url(255)) COMMENT '前缀索引：长链等值查重，255 字节已足够区分',
    KEY idx_expire (expire_at) COMMENT '清理任务按过期时间扫描，靠它避免全表扫'
) ENGINE = InnoDB;
-- 缓存：短码读写比通常 1000:1 以上。Redis string shade:{code} -> longUrl，TTL 与 expire_at
-- 对齐；不存在的映射用空值占位（TTL 60s）防止缓存穿透反复打库（见第 27 章缓存三件套）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

编码：score = 业务分 × 10¹⁰ + (10¹⁰ − 1 − timestamp秒)，后一项使"越早到值越大"
  例：A 在 t=1000、B 在 t=2000 各得 5 分 → A.score = 5×10¹⁰ + 9999998999，B.score = 5×10¹⁰ +
      9999997999，A 排在 B 前（先到者优先）✓
  陷阱：double 只有 53 位有效精度（约 9×10¹⁵），5×10¹⁰ + 10¹⁰ ≈ 6×10¹⁰ 安全；但业务分到 10⁶
        量级再乘 10¹⁰ 就会溢出精度，此时改用业务分 × 10⁶ + (10⁶ − 毫秒偏移)
【内存估算】1000 万用户上榜（元素数超过 zset-max-listpack-entries 后不再用紧凑编码），单元素
  ≈ 成员字符串 16 B + 跳表节点(分数 8 B + 多层指针均摊 16 B) + 哈希表槽位 16 B + 对象头与分配
  对齐 40 B ≈ 100 B → 总量 ≈ 1 GB，日/周/总三榜 ≈ 3 GB
  控制手段：日榜 8 天、周榜 70 天设 EXPIRE 自动清理——主要手段；只把 TOP 10 万放进 ZSet，
  其余分数存 Hash 或落库；总榜按月归档冷数据

1
2
3
4
5
6
7
8

订单号结构（26 字符）：ORD + yyyyMMddHHmmss(14) + 分片号(3) + 节点号(2) + 序列号(6)
  · 业务前缀便于日志与工单里识别单据类型
  · 时间部分保证趋势递增，但时间全放高位会使同一秒的订单挤在同一 B+ 树位置，高并发写入出现
    页分裂热点——这是可读性的代价
  · 分片号是分库分表路由位，拿到订单号即可定位分片；节点号是单机多进程部署时的进程标识；序列号
    在同一毫秒内自增，溢出则自旋等到下一毫秒
时钟回拨的处理层次（见第 34 章分布式 ID 一节）：小幅回拨（< 5 ms）自旋等到下一毫秒；大幅回拨
拒绝发号并告警。绝不允许"倒着发号"——那会直接产生重复。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

CREATE TABLE t_order (
    order_no    VARCHAR(32)   NOT NULL COMMENT '业务发号器生成，可读且趋势递增',
    user_id     BIGINT        NOT NULL,
    activity_id BIGINT        NOT NULL,
    sku_id      BIGINT        NOT NULL,
    status      TINYINT       NOT NULL COMMENT '0 待支付 1 已支付 2 已关闭，供状态机幂等判断',
    amount      DECIMAL(10,2) NOT NULL,
    created_at  DATETIME(3)   NOT NULL DEFAULT CURRENT_TIMESTAMP(3),
    PRIMARY KEY (order_no),   -- 防"重复单据"
    -- 业务幂等键：同一用户对同一活动同一商品只允许一单，与主键互补，防"重复下单"
    UNIQUE KEY uk_user_activity_sku (user_id, activity_id, sku_id),
    KEY idx_user_created (user_id, created_at)
) ENGINE = InnoDB;
-- 依赖唯一索引兜底，而不是先 SELECT 再 INSERT——先查后插在并发下同样存在 TOCTOU 窗口（与
-- 36.4.1 同源）。捕获 DuplicateKeyException 即视为幂等成功
INSERT INTO t_order (order_no, user_id, activity_id, sku_id, status, amount)
VALUES ('ORD20240101120000123000001', 10086, 9001, 5001, 0, 99.00);

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

【混合模式：普通用户推、大 V 拉，读时合并】
  普通用户 A 发动态（粉丝数百到数千）→ 写扩散：ZADD inbox:{粉丝uid} timestamp postId
  大 V B 发动态（粉丝千万级）→ 只写发件箱 outbox:{B}，不扩散，粉丝自己来拉；若对大 V 也
  走推模式，一条动态写一千万次收件箱即为写风暴
  粉丝 U 刷新首页三步：① ZREVRANGE inbox:{U} 0 19 → 候选集 P
                      ② 读 U 关注的大 V 的发件箱（通常只有几十个）→ 候选集 Q
                      ③ 内存按时间戳归并 P + Q，取前 20 条 → 返回
  追问"合并贵不贵"：用户关注的大 V 只有几十个，第 ② 步是个位数到两位数的查询，归并可控
【在线推、离线拉】在线走长连接实时推送；离线不投递，登录时按游标批量拉增量。动机：离线用户
  可能一周不上线，为他每次推送消耗一次写纯属浪费；判在线用网关连接表或位图。

1
2
3
4
5
6
7
8
9

【Bitmap 分片设计】总用户 1 亿，切 1024 片，每片约 10 万 UID
  片号 = uid / 100000；片内偏移 = uid % 100000；单片 = 100000 / 8 = 12500 B ≈ 12.2 KB
  总内存 ≈ 1024 × 12.2 KB ≈ 12.5 MB（与不分片总量相同）；写入 SETBIT online:{片号} 偏移 1，
  统计时各片 BITCOUNT 后求和，复杂度 O(N/8) 可忽略
  三个好处：单 key 从 12.5 MB 降到 12.2 KB（避免大 key 阻塞）、读写打散到不同实例（避免热 key）、
  可按片并行统计。注意只用 Bitmap 分不清"今天登录过"与"当前在线"——需另建以最后心跳时间为 score
  的 ZSet 剔除已下线用户，并按天分 key 便于清理
【HyperLogLog 的 0.81% 误差】可接受：UV 趋势看板、运营大盘、A/B 分组规模对比；不可接受：按在线
  人数发奖励、计费、风控名单——差一人就是一次资损。PFCOUNT 是近似值，PFMERGE 合并继续累积误差