【面试场景题】微博热点新闻系统设计方案

需求

微博热点新闻系统设计，包括top50排行榜，每个新闻的热门评论，评论列表，点赞数统计，转发数统计等

微博热点新闻系统设计方案

一、系统整体架构

微博热点新闻系统需支撑高并发读写（如突发热点事件的流量峰值）、实时数据更新（点赞 / 转发数秒级刷新）和复杂排序逻辑（热点排行、评论热度排序），整体采用 “分层架构 + 微服务拆分” 设计，核心架构如下：

用户层 → CDN → 接入层（Nginx） → 应用服务层 → 缓存层 → 存储层

1. 核心服务拆分

• 热点新闻服务：负责热点排行榜生成、新闻元数据管理
• 互动服务：处理点赞、转发、评论等用户行为
• 内容存储服务：管理新闻正文、评论内容的持久化存储
• 计数服务：实时维护点赞数、转发数、评论数等统计指标
• 搜索服务：支持新闻关键词检索（非核心，可选）

2. 技术栈选型

• 应用框架：Spring Cloud（微服务）、Netty（高并发通信）

• 缓存：Redis Cluster（热点数据）、本地 Caffeine 缓存（高频访问数据）

• 存储：MySQL（结构化数据）、MongoDB（非结构化评论）、Kafka（消息队列）

• 计算：Flink（实时热点计算）、Elasticsearch（全文检索）

二、核心功能设计

1. Top50 热点排行榜

核心需求

• 实时性：热点新闻需分钟级更新（如每 5 分钟刷新一次）

• 准确性：反映真实用户关注度，避免刷量作弊

• 多样性：覆盖不同领域（社会、娱乐、科技等），避免单一话题霸榜

实现方案

• 热度评分公式：

热度 = (点赞数 ×1 + 转发数 ×3 + 评论数 ×2) × 时间衰减系数 + 互动增长率

*   时间衰减系数：发布时间越久系数越低（如 1 小时内 1.0，1-6 小时 0.8，6-24 小时 0.5）*   互动增长率：近 10 分钟内的互动增量，突出 "突发热点"

• 计算流程：

1. 原始数据采集：通过 Kafka 收集用户互动行为（点赞 / 转发 / 评论），实时写入 Flink

2. 实时计算：Flink 按新闻 ID 聚合数据，每 5 分钟计算一次热度得分

3. 候选池筛选：过滤低质内容（如违规新闻），按领域分配候选名额（如社会类 10 个、娱乐类 10 个）

4. 最终排序：从候选池中取综合得分前 50 的新闻，存入 Redis ZSet（hot_news:top50）

5. 缓存更新：应用服务从 Redis 读取排行榜，设置 5 分钟过期时间

• 防作弊机制：

• 对异常账号（如新注册、无历史行为）的互动降权

• 限制单用户对同一新闻的互动频率（如 1 小时内最多转发 1 次）

• 人工审核通道：支持运营干预异常热点

2. 新闻详情与互动数据

新闻元数据存储

• MySQL 表结构（news表）：

CREATE TABLE news (news_id BIGINT PRIMARY KEY,title VARCHAR(200) NOT NULL,content TEXT NOT NULL,author_id BIGINT NOT NULL,category VARCHAR(20) NOT NULL, -- 领域分类publish_time DATETIME NOT NULL,status TINYINT NOT NULL -- 0-正常，1-下架
);

• 缓存策略：

• 热门新闻（Top50）全量缓存至 Redis（news:{news_id}），设置 1 小时过期

• 非热门新闻按需缓存，访问时从 MySQL 加载，缓存 30 分钟

互动数据统计

• 计数存储：

• Redis Hash 存储实时计数（news_stats:{news_id}）：

{"like\_count": 12500,"forward\_count": 5300,"comment\_count": 3200}

• 异步持久化：每 10 分钟通过定时任务将 Redis 计数同步至 MySQL（news_stats表），避免高频写库

• 更新机制：

1. 用户点击 “点赞” 后，先更新 Redis 计数（HINCRBY news_stats:{news_id} like_count 1）

2. 同时发送消息至 Kafka，由计数服务异步处理持久化和热点计算

3. 前端通过 WebSocket 实时刷新计数（无需轮询）

3. 评论系统

核心需求

• 分层展示：支持一级评论和二级回复（评论的评论）

• 热门评论：突出显示高赞评论，优先展示

• 高并发：热门新闻的评论数可能达 10 万 +，需支持快速加载

实现方案

• 存储设计：

• 一级评论：MongoDB 集合（comments），每条记录包含comment_id、news_id、user_id、content、like_count、publish_time

• 二级回复：嵌套在一级评论的replies数组中（适合回复数较少的场景），或单独集合（replies）关联parent_comment_id

• 热门评论筛选：

1. 条件：发布时间在 24 小时内，点赞数≥100，无违规内容

2. 排序：按（点赞数 ×0.7 + 回复数 ×0.3）降序，取前 20 条存入 Redis List（news:comments:hot:{news_id}）

3. 缓存更新：每 30 分钟刷新一次

• 评论列表分页：

• 按发布时间倒序（最新在前），支持分页查询（skip + limit）

• 缓存优化：热门新闻的前 100 条评论缓存至 Redis，后续分页从 MongoDB 加载

• 加载策略：前端默认加载前 20 条 + 热门评论，滚动到底部时加载更多

4. 点赞与转发功能

点赞实现

• 数据存储：

• Redis Set 记录点赞用户（news:likes:{news_id}），支持 O (1) 判断用户是否点赞

• 计数同步至news_stats表（如前所述）

• 交互流程：

1. 用户点击点赞 → 前端发送请求至互动服务

2. 服务端判断是否已点赞：

• 未点赞：SADD添加用户 ID，HINCRBY递增计数

• 已点赞：SREM移除用户 ID，HINCRBY递减计数

3. 返回更新后的计数，前端切换图标状态

转发实现

• 数据存储：

• MySQL 表（forwards）：记录转发关系（forward_id、news_id、user_id、content、forward_time）

• 转发计数同步至news_stats表

• 防重复机制：

• Redis 设置用户 - 新闻转发记录（user:forwards:{user_id}），过期时间 24 小时

• 转发前检查该用户是否 24 小时内已转发同一新闻

三、缓存策略设计

1. 多级缓存架构

• 本地缓存：应用服务器内存缓存热点新闻详情（Top50），减轻 Redis 压力

• Redis 集群：

• 主集群：存储排行榜、互动计数、热门评论等核心数据

• 从集群：处理读请求，支持读写分离

• 缓存淘汰策略：

• 热点数据：设置较长过期时间（如 1 小时），主动更新

• 非热点数据：设置较短过期时间（如 30 分钟），LRU 淘汰

2. 缓存一致性保障

• 更新策略：先更新数据库，再删除缓存（避免缓存脏数据）

• 延迟双删：更新数据库后，先删缓存，1 秒后再删一次（解决并发更新问题）

• 缓存预热：Top50 热点新闻在非高峰时段提前加载至缓存

四、高可用与扩展性

1. 高可用设计

• 服务熔断降级：

• 用 Sentinel 监控服务响应时间，超时或错误率过高时触发熔断

• 降级策略：非核心功能（如热门评论）不可用时，仅返回基础评论列表

• 限流措施：

• 接入层：Nginx 限制单 IP 请求频率（如 100 次 / 分钟）

• 应用层：对评论发布、转发等接口限流（如单用户 10 次 / 分钟）

• 容灾备份：

• 数据库主从复制，Redis 集群主从 + 哨兵模式

• 多可用区部署：服务和数据跨机房存储，避免单点故障

2. 扩展性设计

• 水平扩展：所有服务均无状态，可通过增加实例扩展容量

• 数据分片：

• MySQL 按news_id分表（如 1024 张），避免单表过大

• MongoDB 按news_id分片存储评论，提高查询效率

• 弹性伸缩：基于云平台自动扩缩容（如根据 CPU 利用率、请求量）

五、监控与运维

1. 核心监控指标

• 业务指标：Top50 更新成功率、评论加载延迟、互动操作响应时间

• 技术指标：Redis 命中率、数据库读写 QPS、服务错误率

• 告警阈值：如评论加载延迟 > 500ms、错误率 > 1% 时触发告警

2. 灰度与回滚

• 灰度发布：新功能先对 10% 用户开放，观察无异常后全量上线

• 回滚机制：关键服务部署多版本，支持一键切换至稳定版本

• 数据备份：MySQL 每日全量备份 + binlog 增量备份，MongoDB 定时快照

六、总结

本方案通过分层架构和微服务拆分，实现了热点新闻系统的核心功能，重点解决了：

1. 实时热点计算：基于 Flink 的分钟级热度更新

2. 高并发互动：Redis 缓存 + 异步持久化，支撑百万级用户同时操作

3. 复杂评论系统：MongoDB 存储 + 热门评论预筛选，平衡性能与体验

系统可根据业务增长平滑扩展，同时通过防作弊机制和容灾设计保障稳定性，适合支撑微博级别的热点新闻场景。