这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
关键决策
在本章中，我们将深入探讨热门排名系统设计过程中的核心技术决策。这些决策直接影响系统的性能、可扩展性、维护成本和用户体验。
目录
数据存储策略
决策背景
热门排名系统需要存储大量的行为数据（点赞、评论、分享、浏览等），这些数据具有以下特点：
- 高写入频率：每秒可能产生数万条行为记录
- 时间敏感性：数据需要按时间窗口聚合
- 查询模式多样：需要支持实时查询和历史分析
可选方案对比
| 方案 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|
| 关系型数据库 | ACID 保证、成熟生态 | 写入性能瓶颈、水平扩展困难 | 小规模系统、强一致性要求 |
| NoSQL (MongoDB) | 灵活模式、水平扩展 | 事务支持有限、查询复杂度高 | 中等规模、文档型数据 |
| 时序数据库 (InfluxDB) | 时间序列优化、聚合高效 | 通用查询能力弱 | 纯时序数据场景 |
| 列式存储 (ClickHouse) | 分析查询极快、压缩率高 | 实时更新能力弱 | 离线分析为主 |
| 混合架构 | 各取所长、灵活应对 | 架构复杂、维护成本高 | 大规模生产系统 |
我们的选择：混合架构
┌─────────────────────────────────────────────────────────────┐
│ 数据接入层 │
├─────────────────────────────────────────────────────────────┤
│ Kafka Message Queue (行为事件流) │
└─────────────────────────────────────────────────────────────┘
│
┌───────────────┼───────────────┐
▼ ▼ ▼
┌─────────────────┐ ┌───────────┐ ┌─────────────┐
│ Redis │ │ MySQL │ │ ClickHouse │
│ (实时缓存) │ │ (元数据) │ │ (历史分析) │
└─────────────────┘ └───────────┘ └─────────────┘决策理由：
- Redis 用于存储实时热榜数据，支持毫秒级读取
- MySQL 存储内容元数据和用户信息，保证事务一致性
- ClickHouse 存储历史行为数据，支持复杂分析查询
- Kafka 作为消息中间件，解耦数据生产与消费
代码示例：数据路由策略
实时计算架构
决策背景
热门排名需要实时反映用户行为变化，延迟过高会导致热榜”过时”，影响用户体验。但完全实时计算会带来巨大的资源消耗。
架构选择：流批结合
┌─────────────────────────────────────────────────────────────┐
│ 实时计算层 (Flink) │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 窗口聚合 │ │ 状态管理 │ │ 异常检测 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ 离线计算层 (Spark) │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ T+1 汇总 │ │ 模型训练 │ │ 数据校正 │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
└─────────────────────────────────────────────────────────────┘决策要点
| 考虑因素 | 纯实时方案 | 纯离线方案 | 流批结合方案 |
|---|---|---|---|
| 延迟 | < 1 秒 | 小时级 | 秒级 + 校正 |
| 资源消耗 | 极高 | 低 | 中等 |
| 数据准确性 | 可能有误差 | 准确 | 准确 + 实时 |
| 系统复杂度 | 中等 | 低 | 高 |
| 推荐度 | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐⭐ |
Flink 作业配置示例
计算逻辑要点
- 这里关注排序或聚合的业务含义，不需要记住具体语言写法。
缓存层级设计
决策背景
热门排名是典型的高读低写场景，缓存设计直接决定系统吞吐能力。我们需要在缓存命中率、数据一致性和内存成本之间找到平衡。
三级缓存架构
┌─────────────────────────────────────────────────────────────┐
│ Client 层 │
│ (浏览器/客户端缓存) │
│ TTL: 30 秒，减少重复请求 │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ CDN 层 │
│ (静态热榜页面缓存) │
│ TTL: 60 秒，边缘节点分发 │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ Redis Cluster 层 │
│ (核心热榜数据，分片存储) │
│ 主从复制 + 持久化 │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ DB 层 │
│ (兜底数据源，极少访问) │
└─────────────────────────────────────────────────────────────┘缓存策略决策
| 策略 | 描述 | 适用场景 | 风险 |
|---|---|---|---|
| Cache-Aside | 先查缓存，未命中查 DB | 读多写少 | 缓存穿透 |
| Write-Through | 写缓存同时写 DB | 强一致性要求 | 写入延迟高 |
| Write-Behind | 先写缓存，异步写 DB | 高吞吐写入 | 数据丢失风险 |
| 刷新策略 | 定时刷新整个缓存 | 热榜类场景 | 刷新瞬间压力大 |
我们的选择：混合策略
缓存容量规划
单条热榜数据：~2KB (contentId + score + metadata)
热榜条目数：1000 条/分类
分类数量：50 个
总容量：2KB × 1000 × 50 = 100MB
考虑冗余和预留：
- 主从复制：×2
- 历史热榜（最近 24 小时）：×10
- 预留空间：×2
建议配置：100MB × 2 × 10 × 2 = 4GB 内存时间窗口选择
决策背景
热门排名的”热度”定义依赖于时间窗口。窗口太短会导致排名波动剧烈，窗口太长会失去”实时”意义。
多窗口策略
我们采用多时间窗口并行计算策略，不同场景使用不同窗口：
┌─────────────────────────────────────────────────────────────┐
│ 时间窗口配置 │
├─────────────────────────────────────────────────────────────┤
│ ┌─────────────┬─────────────┬─────────────┬─────────────┐ │
│ │ 实时热榜 │ 小时热榜 │ 日热榜 │ 周热榜 │ │
│ ├─────────────┼─────────────┼─────────────┼─────────────┤ │
│ │ 5 分钟 │ 1 小时 │ 24 小时 │ 7 天 │ │
│ │ 滑动窗口 │ 滑动窗口 │ 固定窗口 │ 固定窗口 │ │
│ │ 首页推荐 │ 频道页 │ 日报推送 │ 周报总结 │ │
│ └─────────────┴─────────────┴─────────────┴─────────────┘ │
└─────────────────────────────────────────────────────────────┘窗口类型对比
| 窗口类型 | 计算方式 | 优势 | 劣势 |
|---|---|---|---|
| 固定窗口 | 按整点/整天划分 | 实现简单、边界清晰 | 窗口切换时数据跳变 |
| 滑动窗口 | 持续向前滑动 | 数据平滑、实时性好 | 计算复杂、状态维护成本高 |
| 会话窗口 | 按用户活跃划分 | 贴合用户行为 | 不适用于全局热榜 |
衰减因子设计
为了平衡新旧数据的权重，我们引入指数衰减：
半衰期参数调优
| 内容类型 | 推荐半衰期 | 理由 |
|---|---|---|
| 新闻资讯 | 2-4 小时 | 时效性极强，快速更替 |
| 短视频 | 6-12 小时 | 传播快，生命周期短 |
| 长文章 | 24-48 小时 | 深度内容，持续发酵 |
| 技术教程 | 7-30 天 | 长尾价值，持续参考 |
权重因子设计
决策背景
不同用户行为对”热度”的贡献不同。点赞、评论、分享的权重需要精心设计，既要反映真实热度，又要防止刷榜作弊。
基础权重配置
用户可信度系数
最终权重 = 基础权重 × 用户可信度 × 时间衰减 × 反作弊系数
用户可信度计算：
- 新用户 (注册<7 天): 0.5
- 普通用户：1.0
- 活跃用户 (月活>20 天): 1.2
- 认证用户：1.5
- 可疑用户 (触发风控): 0.1权重动态调整
降级策略
决策背景
热门排名系统作为核心功能，必须有完善的降级策略应对各种异常情况：服务故障、流量激增、数据异常等。
降级层级
┌─────────────────────────────────────────────────────────────┐
│ 降级策略金字塔 │
├─────────────────────────────────────────────────────────────┤
│ L0: 正常运行 │ 实时计算 + 多级缓存 │
├─────────────────────────────────────────────────────────────┤
│ L1: 轻度降级 │ 停用实时计算，使用缓存 + 定时刷新 │
├─────────────────────────────────────────────────────────────┤
│ L2: 中度降级 │ 延长缓存时间，减少计算频率 │
├─────────────────────────────────────────────────────────────┤
│ L3: 重度降级 │ 返回静态热榜，停用个性化 │
├─────────────────────────────────────────────────────────────┤
│ L4: 紧急降级 │ 返回兜底数据，只读模式 │
└─────────────────────────────────────────────────────────────┘自动降级触发条件
| 指标 | 阈值 | 触发动作 |
|---|---|---|
| Redis 连接失败率 | > 10% | 切换到备用集群 |
| Flink 作业延迟 | > 30 秒 | 暂停实时计算，使用缓存 |
| CPU 使用率 | > 85% | 延长缓存过期时间 |
| 错误率 | > 5% | 启用静态热榜 |
| 响应时间 P99 | > 500ms | 限流 + 降级 |
降级方案落地
兜底数据策略
一致性模型
决策背景
热门排名系统需要在一致性和可用性之间做出权衡。完全一致性会导致性能问题，而过度宽松的一致性会影响用户体验。
我们的选择：最终一致性
┌─────────────────────────────────────────────────────────────┐
│ 一致性策略 │
├─────────────────────────────────────────────────────────────┤
│ 用户行为写入 → Kafka → 异步处理 → 热榜更新 │
│ │
│ 用户读取热榜 → Redis 缓存 → 可能略有延迟 │
│ │
│ 可接受延迟：≤ 5 秒 │
└─────────────────────────────────────────────────────────────┘一致性保证级别
| 场景 | 一致性要求 | 实现方式 |
|---|---|---|
| 热榜展示 | 最终一致 | 异步更新 + 缓存 |
| 个人得分查询 | 强一致 | 直接计算或短时缓存 |
| 排行榜导出 | 强一致 | 离线生成 |
| 实时通知 | 最终一致 | 消息推送 |
数据校正机制
版本号机制
决策总结
关键决策矩阵
| 决策领域 | 选择方案 | 核心理由 | 风险缓解 |
|---|---|---|---|
| 数据存储 | 混合架构 | 各场景最优解 | 增加监控和告警 |
| 实时计算 | 流批结合 | 平衡延迟与准确性 | 定期数据校正 |
| 缓存设计 | 三级缓存 | 最大化命中率 | 缓存穿透保护 |
| 时间窗口 | 多窗口并行 | 满足不同场景 | 统一配置管理 |
| 权重设计 | 动态权重 | 适应变化 | 人工审核通道 |
| 降级策略 | 四层降级 | 渐进式应对 | 自动化触发 |
| 一致性 | 最终一致 | 保证可用性 | 数据校正机制 |
技术债务与未来优化
- 机器学习权重：当前权重为人工设定，未来可引入 ML 模型自动学习最优权重
- 个性化热榜：当前为全局热榜，可考虑加入用户兴趣因子
- 边缘计算：考虑将部分计算下推到 CDN 边缘节点
- 多区域部署：支持跨区域数据同步和灾备
监控指标清单
配置要点
- 配置表达的是环境差异和运行参数，不是业务规则本身。
下一步
在下一章中，我们将深入探讨 性能优化实践，包括具体的优化技巧、基准测试方法和性能调优案例。