这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
热门排名系统 - 完整架构设计
1. 系统概述
热门排名系统是一个高并发、低延迟的实时数据处理系统，用于计算和展示各类内容的热度排名。系统需要支撑每日亿级的事件处理量，并在秒级内完成热度计算和排名更新。
1.1 设计目标
- 高吞吐量：支持 10 万 + QPS 的事件写入
- 低延迟：排名更新延迟 < 1 秒
- 高可用：99.99% 的服务可用性
- 可扩展：支持水平扩展以应对流量增长
- 数据一致性：保证最终一致性，关键数据强一致
1.2 核心指标
| 指标 | 目标值 | 说明 |
|---|---|---|
| 写入吞吐量 | 100,000 QPS | 峰值事件处理能力 |
| 查询延迟 | < 50ms | P99 排名查询延迟 |
| 计算延迟 | < 1s | 事件到排名更新的延迟 |
| 数据保留 | 30 天 | 原始事件数据保留周期 |
| 可用性 | 99.99% | 月度服务可用性 |
2. 系统架构图
┌─────────────────────────────────────────────────────────────────────────────┐
│ 客户端层 (Client Layer) │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Web │ │ iOS │ │ Android │ │ API │ │ 第三方 │ │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
└───────┼─────────────┼─────────────┼─────────────┼─────────────┼────────────┘
│ │ │ │ │
└─────────────┴──────┬──────┴─────────────┴─────────────┘
│
┌────────▼────────┐
│ 负载均衡器 │
│ (Load Balancer)│
└────────┬────────┘
│
┌────────────────────────────┼────────────────────────────────────────────────┐
│ 接入层 (Access Layer) │
│ ┌─────────────────────────┴─────────────────────────┐ │
│ │ API Gateway (Kong/Nginx) │ │
│ │ • 请求路由 • 限流熔断 • 身份认证 • 日志记录 │ │
│ └─────────────────────────┬─────────────────────────┘ │
└────────────────────────────┼────────────────────────────────────────────────┘
│
┌────────────────────┼────────────────────┐
│ │ │
▼ ▼ ▼
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ 写入服务 │ │ 查询服务 │ │ 管理服务 │
│ Write Service│ │ Query Service │ │ Admin Service │
└───────┬───────┘ └───────┬───────┘ └───────┬───────┘
│ │ │
│ │ │
┌───────▼───────────────────▼───────────────────▼───────┐
│ 消息队列层 (Message Queue) │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Apache Kafka / Pulsar │ │
│ │ • events-topic • ranking-topic • sync-topic │ │
│ └─────────────────────────────────────────────────┘ │
└───────────────────────────┬───────────────────────────┘
│
┌───────────────────┼───────────────────┐
│ │ │
▼ ▼ ▼
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ 实时计算引擎 │ │ 数据存储层 │ │ 缓存层 │
│ (Flink/Storm)│ │ (Storage) │ │ (Redis) │
│ • 热度计算 │ │ • MySQL │ │ • 排名缓存 │
│ • 窗口聚合 │ │ • ClickHouse │ │ • 热点数据 │
│ • 实时排名 │ │ • Elasticsearch│ │ • 分布式锁 │
└───────┬───────┘ └───────┬───────┘ └───────┬───────┘
│ │ │
└───────────────────┼───────────────────┘
│
┌───────────────────────────▼───────────────────────────┐
│ 监控与运维层 (Observability) │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────┐ │
│ │ Prometheus│ │ Grafana │ │ ELK │ │ Jaeger│ │
│ └──────────┘ └──────────┘ └──────────┘ └──────┘ │
└───────────────────────────────────────────────────────┘3. 核心组件详解
3.1 接入层 (Access Layer)
接入层是系统的入口，负责处理所有外部请求。
3.1.1 API Gateway
配置要点
- 配置表达的是环境差异和运行参数，不是业务规则本身。
3.1.2 负载均衡
策略：加权轮询 (Weighted Round Robin)
健康检查：每 5 秒检测后端服务状态
会话保持：基于用户 ID 的一致性哈希3.2 服务层 (Service Layer)
3.2.1 写入服务 (Write Service)
负责接收和处理用户行为事件。
写入流程：
- 接收事件请求，进行参数校验
- 生成全局唯一事件 ID
- 写入消息队列（异步解耦）
- 返回成功响应
- 后台消费者处理事件
3.2.2 查询服务 (Query Service)
负责提供排名查询接口。
查询优化策略：
- 多级缓存：本地缓存 + Redis + 数据库
- 预计算：定时预计算常用维度的排名
- 分页优化：使用游标分页避免深度分页问题
- 读写分离：查询走从库，减轻主库压力
3.2.3 管理服务 (Admin Service)
提供系统管理和配置功能。
功能模块：
- 排名规则配置：调整热度计算公式参数
- 数据查看：查看原始事件和计算结果
- 系统监控：查看系统运行状态
- 异常处理：手动修正异常数据
- 灰度发布：控制新规则的发布范围3.3 消息队列层 (Message Queue)
3.3.1 Topic 设计
主题规划：
├── events-raw # 原始事件（保留 30 天）
│ ├── partitions: 32
│ └── replication: 3
│
├── events-processed # 处理后事件（保留 7 天）
│ ├── partitions: 16
│ └── replication: 3
│
├── ranking-updates # 排名更新通知（保留 1 天）
│ ├── partitions: 8
│ └── replication: 3
│
└── system-events # 系统事件（保留 90 天）
├── partitions: 4
└── replication: 33.3.2 消息格式
配置要点
- 配置表达的是环境差异和运行参数，不是业务规则本身。
3.4 实时计算引擎 (Stream Processing)
3.4.1 Flink 作业设计
3.4.2 热度计算公式
热度分数 = Σ(事件权重 × 时间衰减因子 × 质量系数)
其中：
事件权重：
- 浏览 (view): 1
- 点赞 (like): 3
- 评论 (comment): 5
- 分享 (share): 10
- 收藏 (favorite): 8
时间衰减因子：
decay(t) = e^(-λt)
λ = 0.1 (可调参数，控制衰减速度)
质量系数：
- 新用户行为：0.8
- 活跃用户行为：1.0
- 高价值用户行为：1.2
- 异常行为检测：0.0 (直接过滤)3.5 数据存储层 (Storage Layer)
3.5.1 MySQL - 元数据存储
数据设计要点
- 核心是在
targets里保存业务事实，而不是把规则散落在应用逻辑里。- 索引服务于高频查询，重点是缩小扫描范围，而不是堆更多字段。
- 关键字段包括
id、target_type、target_id、title、created_at、updated_at、ranking_score、rank_position，它们决定后续查询和管理能力。
3.5.2 ClickHouse - 事件明细存储
数据设计要点
- 核心是在
events_raw里保存业务事实，而不是把规则散落在应用逻辑里。- 关键字段包括
event_time、processing_time、time_bucket，它们决定后续查询和管理能力。
3.5.3 Elasticsearch - 搜索与日志
索引设计：
- events-logs-*: 事件日志，用于问题排查
- ranking-history-*: 排名历史，支持复杂查询
- system-metrics-*: 系统指标，用于监控分析3.6 缓存层 (Cache Layer)
3.6.1 Redis 数据结构设计
# 实时排名缓存 (有序集合)
ZSET ranking:video:24h
- video_001: 95.678
- video_002: 89.234
- video_003: 82.456
# 目标分数缓存 (哈希)
HASH score:video:video_001
- value: 95.678
- updated_at: 1699999999
- time_range: 24h
# 排名位置缓存 (字符串)
STRING rank:video:video_001:24h = 5
# 去重缓存 (集合)
SET viewed:user_123:video_001:20240101
# 限流计数器
STRING rate:user_123:write = 150 (TTL: 60s)3.6.2 缓存策略
缓存更新策略：
- 写入时更新：新事件到达时更新相关缓存
- 定时刷新：每 5 分钟全量刷新排名
- 懒加载：查询时如缓存失效则回源加载
缓存失效策略：
- 基于时间：排名缓存 5 分钟过期
- 基于事件：目标状态变更时失效
- 主动失效：管理操作触发失效4. 数据流设计
4.1 写入数据流
用户请求 → API Gateway → Write Service → Kafka → Flink → Redis/DB
│ │
│ ▼
│ ClickHouse (归档)
│
▼
异步响应 (立即返回)4.2 查询数据流
用户请求 → API Gateway → Query Service → Redis (缓存命中?)
│ │
│ 命中: 返回
│ │
▼ ▼
未命中: 查询数据库 返回
│
▼
更新缓存
│
▼
返回结果4.3 排名计算流
Kafka (events) → Flink (窗口聚合) → 分数计算 → 排名计算
│
▼
Redis (实时更新)
│
▼
Kafka (通知) → 其他服务5. 技术选型
5.1 技术栈总览
| 层级 | 技术 | 选型理由 |
|---|---|---|
| 接入层 | Nginx + Kong | 高性能、插件丰富、易于扩展 |
| 服务层 | Java + Spring Boot | 生态完善、团队熟悉、稳定性高 |
| 消息队列 | Apache Kafka | 高吞吐、持久化、生态成熟 |
| 流计算 | Apache Flink | 精确一次、低延迟、状态管理 |
| 关系数据库 | MySQL 8.0 | 成熟稳定、支持事务 |
| 分析数据库 | ClickHouse | 列式存储、查询性能优异 |
| 缓存 | Redis Cluster | 高性能、数据结构丰富 |
| 搜索引擎 | Elasticsearch | 全文检索、日志分析 |
| 监控 | Prometheus + Grafana | 云原生、可视化强大 |
| 链路追踪 | Jaeger | 分布式追踪、问题定位 |
5.2 版本规划
第一阶段 (基础版):
- Kafka + Flink + Redis + MySQL
- 支持基础排名功能
第二阶段 (增强版):
- 增加 ClickHouse 存储
- 完善监控和告警
第三阶段 (高级版):
- 增加机器学习预测
- 支持个性化排名6. 部署架构
6.1 集群规划
生产环境集群：
├── K8s 集群 (应用服务)
│ ├── 命名空间：ranking-prod
│ ├── 节点数：20
│ └── 资源：80C 256G
│
├── Kafka 集群
│ ├── Broker 数：6
│ └── 存储：10TB SSD
│
├── Flink 集群
│ ├── JobManager: 3 (HA)
│ ├── TaskManager: 20
│ └── 资源：160C 512G
│
├── Redis 集群
│ ├── 节点：18 (6 主 12 从)
│ └── 内存：512GB
│
├── MySQL 集群
│ ├── 主从：1 主 3 从
│ └── 存储：2TB SSD
│
└── ClickHouse 集群
├── 节点：8
└── 存储：50TB HDD6.2 高可用设计
多活部署：
- 同城双活：两个可用区同时提供服务
- 数据同步：数据库主从复制 + 消息队列镜像
- 故障切换：自动检测 + 快速切换 (< 30s)
容灾备份：
- 数据备份：每日全量 + 每小时增量
- 异地灾备：关键数据异地备份
- 恢复演练：每季度进行灾备演练7. 性能优化
7.1 写入优化
- 批量写入：累积一定数量后批量写入，减少网络开销
- 异步处理：写入后立即返回，后台异步处理
- 分区策略：按目标类型分区，提高并行度
- 压缩传输：启用消息压缩，减少带宽占用
7.2 查询优化
- 索引优化：建立合理的复合索引
- 查询下推：将过滤条件下推到存储层
- 结果缓存：缓存热点查询结果
- 预计算：提前计算常用维度的结果
7.3 计算优化
- 状态后端：使用 RocksDB 状态后端，支持大状态
- 增量计算：只计算变化的部分
- 并行度调优：根据数据量调整并行度
- 反压处理：合理处理反压，避免数据丢失
8. 监控与告警
8.1 核心指标
业务指标：
- 事件写入速率 (QPS)
- 排名查询速率 (QPS)
- 排名更新延迟 (秒)
- 热门目标数量
系统指标：
- CPU 使用率
- 内存使用率
- 磁盘使用率
- 网络带宽
质量指标：
- 服务可用性 (%)
- 请求错误率 (%)
- P99 延迟 (毫秒)
- 数据一致性8.2 告警规则
严重告警 (电话 + 短信):
- 服务不可用 > 1 分钟
- 错误率 > 5%
- 数据延迟 > 5 分钟
警告告警 (短信 + 邮件):
- CPU > 80%
- 内存 > 85%
- 磁盘 > 80%
- 延迟 > 1 秒
提示告警 (邮件):
- 流量异常波动
- 配置变更
- 定期报告9. 安全设计
9.1 访问控制
- 身份认证：所有请求需要有效令牌
- 权限校验：基于角色的访问控制
- 接口限流：防止恶意请求
- 敏感操作：关键操作需要二次确认
9.2 数据安全
- 传输加密：全链路 HTTPS
- 数据脱敏：敏感信息脱敏存储
- 访问审计：所有操作记录日志
- 数据备份：定期备份防止丢失
10. 总结
本架构设计提供了一个完整的热门排名系统解决方案，具备以下特点：
- 高可用：多层冗余设计，保证服务持续可用
- 高性能：优化的数据流和缓存策略，支持高并发
- 可扩展：微服务架构，支持水平扩展
- 易维护：完善的监控和告警，便于问题定位
- 安全可靠：多层次安全防护，保障数据安全
后续可根据实际业务需求进行迭代优化，逐步完善系统功能。