4. 削峰填谷概念：流量峰值产生原因、削峰策略与 ZSET 优势

在报表系统中，数据上报与任务处理往往呈现明显的“潮汐效应”。削峰填谷是保障系统稳定性的核心手段，本章将深入剖析流量峰值的成因、三大削峰策略，并重点论证为何 ZSET 是实现削峰填谷的理想数据结构。

4.1 流量峰值产生原因

流量峰值并非随机出现，而是由业务规律、系统行为与外部触发共同导致。理解成因是设计削峰策略的前提。

4.2 三大削峰策略：排队、限流、异步

削峰的本质是“将瞬时高流量转化为持续平稳的负载”。业界主流策略可归纳为三种，各有适用场景与权衡。

4.2.1 排队（Queueing）

将请求放入队列，按 FIFO 或优先级顺序逐个处理。适用于对顺序敏感、允许等待的场景。

• 优点： 保证处理顺序，实现简单。
• 缺点： 队列堆积时延迟增加，需监控队列深度。
• 典型实现： 阻塞队列、Kafka、RocketMQ。

4.2.2 限流（Rate Limiting）

直接拒绝超出阈值的请求，保护下游系统不被冲垮。适用于对实时性要求高、可接受部分失败的场景。

• 优点： 响应迅速，资源消耗可控。
• 缺点： 丢弃请求可能影响业务完整性。
• 典型实现： 令牌桶、漏桶、滑动窗口。

4.2.3 异步（Asynchronous Processing）

请求立即返回“已接收”，后台异步处理。适用于对最终一致性要求高、可容忍延迟的场景。

• 优点： 解耦生产与消费，吞吐量高。
• 缺点： 增加系统复杂度，需处理回调与补偿。
• 典型实现： 消息队列、延迟队列、事件驱动架构。

4.3 ZSET 削峰的核心优势

相比传统消息队列，Redis ZSET 在报表延迟队列场景中具备独特优势。以下从五个维度进行对比分析。

4.3.1 优势对比表

4.3.2 ZSET 削峰流程架构

下图展示了 ZSET 延迟队列如何将瞬时峰值流量转化为平稳的消费速率，实现“削峰填谷”。

4.3.3 削峰效果对比图

下图直观对比了“无削峰”与“ZSET 削峰”两种模式下系统负载的变化曲线。

4.4 为什么报表场景首选 ZSET

• 有序性保障： 报表任务通常依赖时间顺序（如先上报后汇总），ZSET 的 score 天然支持按时间戳排序。
• 原子性避免重复： 使用 ZREM 配合 ZRANGEBYSCORE 可实现“取即删”的原子操作，防止任务被重复消费。
• 动态延期能力： 当报表依赖的上游数据未就绪时，可直接修改 score 实现任务延期，无需重新投递。
• 资源占用可控： 报表任务多为短生命周期（秒级到分钟级），ZSET 的内存模型非常适合这种高频创建与销毁的场景。

// 示例：ZSET 原子性取任务（取即删）
String taskId = jedis.zrangeByScore("report:delay:queue", 0, now, 0, 1);
if (taskId != null) {
    Long removed = jedis.zrem("report:delay:queue", taskId);
    if (removed > 0) {
        // 成功获取任务，开始处理
        processReport(taskId);
    }
}