负载转移

流量高峰不必硬扛：负载转移（Load Shifting） 把请求推迟或转移到低峰时段处理，用队列换瞬时容量。秒杀、报表、批量通知都依赖这一模式，消息层实践见 kafka-essentials，是 building-for-scale 的异步扩展手段。

学习目标

• 区分负载转移、负载均衡、弹性伸缩三者的目标差异
• 设计「同步受理 + 异步处理 + 轮询/推送结果」的削峰流程
• 评估队列积压时的延迟 SLA 与扩容策略

核心概念

核心思路：峰值写入消息队列，消费者按自身能力匀速处理。

峰值写 → API 快速 202 Accepted → Kafka Topic → Worker 池 → DB
         （校验 + 入队 ms 级）              （可控 TPS）

模式	用户体验	复杂度
同步写 DB	峰值直接打满 DB	低
异步队列	延迟秒级~分钟级	中
预计算 / 定时批	准实时	高

关键设计点：

1. 幂等：重复消费不重复扣款（idempotency key）
2. 顺序：同一用户消息进同一 partition
3. 死信队列： poison message 不阻塞全局
4. 监控：lag、消费速率、端到端延迟

Java 侧 Spring @KafkaListener + 手动 ack；突发时可 临时增加 consumer 实例（不超过 partition 数）。

与 scale-backpressure 配合：队列满时 API 返回 503 或降级。Cron 把非实时任务（对账、索引重建）移到凌晨也是负载转移。

练习

• 为一个「导出 10 万行 CSV」需求设计异步 API 契约（状态码、查询进度 URL）
• 估算：队列积压 50 万条、单消费者 200 TPS，清空需多久
• 在 kafka-essentials 中完成 producer/consumer 基础实验

小结

负载转移用时间和队列换瞬时吞吐——API 要快，干活可以慢慢排队。