实时计算

热榜如果几个小时才更新一次，就无法反映突发事件。实时计算的目标是让用户行为在秒级或分钟级影响榜单，同时控制计算成本和抖动。

本章主线

本章包含：

1. 流式计算架构：用户行为事件持续进入计算链路。
2. 时间窗口聚合：按 1 分钟、5 分钟等窗口统计热度增量。
3. Flink 实现：用流处理框架维护状态和容错。

事件流

榜单事件可以包括：

view, click, comment, share, like, favorite, report

事件进入消息队列后，由流式任务按 item_id 聚合。聚合结果再更新 Redis ZSet 或中间热度存储。

窗口选择

窗口太短，榜单抖动；窗口太长，热点反应慢。可以组合使用：

• 1 分钟窗口：捕捉突发增长。
• 5 分钟窗口：平滑噪音。
• 1 小时窗口：判断持续热度。

最终热度分可以融合多个窗口。

乱序和延迟

用户事件可能延迟到达。流式系统需要处理事件时间和处理时间的差异。对于热榜，通常允许少量迟到事件补算，但不会无限等待，否则实时性会下降。

降级策略

实时计算链路故障时，榜单不能空白。可以降级到：

• 最近一次榜单快照。
• 离线计算榜单。
• 热门内容兜底。

实时计算提升新鲜度，但也更容易被刷榜攻击影响。下一章会补防刷榜能力。