如何在短时间内向 100 万用户发送促销码？

Question

IT Interview Practice · Accepted Answer

绝不要在请求处理器中遍历 100 万用户——而应**通过队列进行扇出（fan out）**，将速率限制到每个 provider 能接受的水平，让每次发送都**幂等（idempotent）**，并把失败路由到 DLQ 以便重试。API 调用只负责入队；由 worker 完成缓慢的 I/O。

## 架构

```text
Admin ─▶ Campaign API ─▶ [enqueue job] ─▶ Kafka/SQS ─┐
                                                     ▼
   ┌──────────────── Worker pool (autoscaled) ───────────────┐
   │  claim ─▶ dedup(Redis SETNX) ─▶ rate-limiter ─▶ provider │
   └──────────┬──────────────────────────────┬───────────────┘
              │ ok                            │ fail (5xx/timeout)
              ▼                               ▼
        sent_log (DB)                    Retry (backoff) ─▶ DLQ
```

## 组件与流程

- **Campaign API** 写入活动记录并将任务入队——每个用户一个任务，或每 **约 500 个一批**以降低队列开销。它立即返回；100 万次发送在队列后面完成。
- **队列（Kafka / SQS）**既是缓冲区，也是*重放（replay）*日志。如果 worker 崩溃，消息仍然保留；不会丢失任何 code。按 `user_id` 进行 partition，使每个用户的顺序保持稳定。
- **Worker 池**拉取任务，并根据队列积压（lag）自动扩缩容。每个 worker：(1) 预留一个唯一的促销码，(2) 在 Redis 中检查**去重键（dedup key）** `SETNX sent:{campaign}:{user}`，使重新投递的消息绝不会重复发送，(3) 通过按 provider 配额设定大小的 **rate limiter**，(4) 调用 Email/SMS/Push。
- **Rate limiter** 是关键：一旦超过限额，SendGrid 或 Twilio 会对你限流或拉黑。每个 provider 一个 Redis token bucket，无论运行多少 worker，都会限制出站 RPS。
- **DLQ** 在经过 N 次带指数退避（exponential backoff）+ 抖动（jitter）的重试后捕获毒丸消息（poison message），使一个错误地址绝不会阻塞整个活动。

## 面试视角

面试官在考察你是否理解**解耦（decoupling）与反压（back-pressure）**。一个"出色"的回答会指出确切的故障点：没有幂等性，at-least-once 队列加上重试就等于用户收到三个 code；没有 rate limiter，你会自己对 provider 发起 DDoS，被限流到零。常见陷阱是同步做扇出（"直接 `Promise.all`"）——那会占满连接、没有重试，并在一次部署时丢失所有内容。

## 权衡与故障

- **At-least-once 与 exactly-once**：队列以低成本提供 at-least-once；你用 Redis dedup key 换来"实际上一次（effectively once）"，而不是用昂贵的 exactly-once broker。
- **Throughput 与 provider 限额**：你可以无限增加 worker，但 provider 配额才是真正的上限——在活动前申请提高配额或提前预热。
- **故障**：Redis 宕机 → 发送停滞（fail closed，不要跳过 dedup 而冒重复发送的风险）。维护一个按活动计数的 counter，使你在事故后能够恢复（resume）而非重新开始（restart）。

架构

组件与流程

面试视角

权衡与故障

相关问题