这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
数据结构
排行榜是互联网产品中常见的基础功能，无论是热搜榜、热销榜还是活跃用户榜，都需要高效的数据结构来支撑实时的排名计算和查询。本文将介绍排行榜系统所需的核心数据结构设计。
一、核心需求分析
在设计排行榜数据结构前，我们需要明确几个核心需求：
- 实时更新：分数（热度值）需要能够频繁更新
- 快速排名：能够快速获取某个元素的排名
- 范围查询：支持获取前 N 名或某个排名区间的元素
- 自动排序：元素能够根据分数自动排序
- 高性能：支持高并发读写操作
二、Redis ZSet 结构
2.1 ZSet 简介
Redis 的 Sorted Set（ZSet）是排行榜系统的理想选择。它是一个有序集合，每个元素关联一个分数（score），元素根据分数自动排序。
┌─────────────────────────────────────┐
│ Redis ZSet │
├─────────────────────────────────────┤
│ member: "topic_123" score: 9850 │
│ member: "topic_456" score: 8720 │
│ member: "topic_789" score: 7650 │
│ member: "topic_234" score: 6540 │
│ member: "topic_567" score: 5430 │
└─────────────────────────────────────┘2.2 ZSet 的优势
时间复杂度优秀：
- 添加/更新元素：O(log N)
- 获取排名：O(log N)
- 获取前 N 名：O(log N + M)，M 为返回元素数量
内置排序：无需手动维护顺序
原子操作：支持原子性的分数增减
丰富命令：提供多种查询和操作命令
2.3 常用 Redis 命令
验证要点
- 命令只用于验证系统状态，读者不需要记具体参数。
2.4 Key 命名策略
推荐采用分时间维度的命名方式：
hot_ranking:{date} # 日榜：hot_ranking:2026-03-31
hot_ranking:{week} # 周榜：hot_ranking:2026-W14
hot_ranking:{month} # 月榜：hot_ranking:2026-03
hot_ranking:all # 总榜三、数据库表结构设计
虽然 Redis 适合实时排行，但持久化存储和业务数据仍需关系型数据库。
3.1 话题/内容主表
数据设计要点
- 核心是在
topics里保存业务事实，而不是把规则散落在应用逻辑里。- 索引服务于高频查询，重点是缩小扫描范围，而不是堆更多字段。
- 关键字段包括
id、title、content、category_id、author_id、created_at、updated_at，它们决定后续查询和管理能力。
3.2 热度统计表
数据设计要点
- 核心是在
topic_heat_stats里保存业务事实，而不是把规则散落在应用逻辑里。- 索引服务于高频查询，重点是缩小扫描范围，而不是堆更多字段。
- 关键字段包括
id、topic_id、stat_date、view_count、like_count、comment_count、share_count、heat_score，它们决定后续查询和管理能力。
3.3 排行榜快照表
数据设计要点
- 核心是在
ranking_snapshots里保存业务事实，而不是把规则散落在应用逻辑里。- 索引服务于高频查询，重点是缩小扫描范围，而不是堆更多字段。
- 关键字段包括
id、ranking_type、ranking_date、topic_id、ranking_position、heat_score、score_change、rank_change，它们决定后续查询和管理能力。
3.4 热度计算配置表
数据设计要点
- 核心是在
heat_config里保存业务事实，而不是把规则散落在应用逻辑里。- 索引服务于高频查询，重点是缩小扫描范围，而不是堆更多字段。
- 关键字段包括
id、config_key、config_value、description、updated_at、INSERT，它们决定后续查询和管理能力。
3.5 常用查询示例
数据设计要点
- 查询目标是快速定位状态、任务或资源，避免在关键路径上做大范围扫描。
四、数据同步策略
4.1 Redis 与数据库同步
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ 业务服务 │ ───► │ Redis │ ───► │ MySQL │
│ │ │ (实时排行) │ │ (持久化存储) │
└──────────────┘ └──────────────┘ └──────────────┘
│ │ │
│ 1. 更新热度 │ 3. 异步落库 │
│ 2. 读取排行榜 │ 4. 定时快照 │
▼ ▼ ▼4.2 同步方案
- 写操作：先更新 Redis，异步写入数据库
- 读操作：优先读取 Redis，降级到数据库
- 定时任务：每小时/每天将 Redis 数据持久化到快照表
- 数据校准：定期对比 Redis 和数据库，修复不一致
五、小结
排行榜的数据结构设计需要兼顾性能和持久化：
- Redis ZSet：负责实时排行计算，提供毫秒级查询响应
- 关系数据库：负责数据持久化和复杂查询分析
- 合理分片：按时间维度拆分数据，避免单键过大
- 冗余设计：快照表记录历史数据，支持趋势分析
下一节我们将深入探讨热度值的具体计算算法。