完整系统

完整热搜榜单系统可以拆成五条链路：

事件采集 -> 实时聚合 -> 热度计算 -> 榜单存储 -> 展示与治理

用户行为进入事件流，流式任务按窗口聚合，热度服务计算分数，Redis ZSet 承载实时榜单，治理系统负责防刷和降权。

最终架构

一次榜单更新可以这样发生：

1. 用户产生浏览、评论、分享、点赞、搜索等事件。
2. 事件进入消息队列。
3. 流式计算按 item_id 和时间窗口聚合增量。
4. 热度服务应用公式、时间衰减和风险权重。
5. Redis ZSet 更新各类榜单。
6. 榜单服务读取 TopN，补充内容元数据。
7. 防刷系统持续调整权重和名单。
8. 榜单快照定期落库，用于回放和分析。

关键决策

1. 热度公式如何定义：不能只看点击，要综合强弱互动、时间衰减和风险降权。
2. 实时性和稳定性如何平衡：窗口越短越实时，榜单越容易抖动。
3. Redis 是否足够：ZSet 适合实时 TopN，但历史榜单和分析需要落库。
4. 刷榜如何处理：可疑互动降权、确认作弊移除、策略调整要可回放。
5. 榜单和 Feed 是否共用排序：可以共用特征，但展示目标不同。

上线检查清单

• 榜单类型、时间窗口和刷新频率是否明确？
• 热度公式是否有版本和回放机制？
• Redis ZSet key 是否按榜单维度和窗口拆分？
• 实时计算链路是否有延迟、积压和失败监控？
• 是否有榜单快照和降级兜底？
• 防刷榜是否接入账号、设备、IP 和行为异常信号？
• Feed 是否把热度作为特征而不是唯一排序依据？
• 榜单结果是否能解释为什么上榜？

课程总结

热搜榜单系统的本质是公共注意力排序。它既要反映真实热点，又要避免被刷榜操纵；既要实时，又要稳定；既要全站统一，又要能服务个性化 Feed。

设计榜单系统时，始终问：

• 热度代表什么行为价值？
• 时间衰减如何影响新旧内容？
• 异常互动如何降权？
• 榜单更新失败时用户看到什么？

能回答这些问题，榜单系统才具备生产级完整性。