新闻热点高并发
新闻热点高并发和秒杀抢购，在技术挑战上有着本质的不同。如果说秒杀是**“写”的战争**（争抢库存），那么新闻热点就是**“读”的洪灾**（海量阅读）。
新闻热点的核心矛盾是：一瞬间，几百万人同时点开同一篇文章/视频，巨大的读流量直接把服务器内存、带宽和数据库打爆。
针对“突发性极强、读多写少、数据一致性要求不高（允许几秒延迟）”的特点，优化策略如下：
第一层：边缘防御（CDN 与静态化）—— 最强杀手锏
对于新闻热点，CDN（内容分发网络）是绝对的核心，能扛住 90% 以上的流量。
- 纯静态化推送：热点新闻一旦审核发布，后台立即将文章详情页（HTML）全量生成为静态文件，并主动推送到全国各地的 CDN 边缘节点。
- 用户访问直达边缘：用户请求直接被 CDN 节点拦截，直接返回 HTML 文件。请求压根不会到达你的源站服务器，这不仅扛住了流量，还省了带宽成本。
- 动静彻底分离：图片、视频等大文件必须放在对象存储（OSS）+ CDN 上，严禁从应用服务器读取。
第二层：应用层防护（多级缓存与“热 Key”隔离）
热点新闻无法被 CDN 完全缓存的部分（如“浏览量 +1”接口、登录态判断），需要靠应用层来扛。
- 本地缓存（进程级）是主力：相比于秒杀必须用 Redis 分布式锁保证库存准确，新闻阅读允许极短时间的误差。直接在应用服务器内存中使用 Caffeine/Guava Cache 缓存文章详情，响应时间在微秒级（比 Redis 快 10 倍），且不占用网络 IO。
- 解决“热 Key”击穿：一篇百万阅读的文章在 Redis 中是一个“热 Key”。如果它失效了，瞬间百万请求涌向数据库。
- 方案一（互斥锁）：第一个请求去查数据库并重建缓存，其他请求等待 10ms 重试。
- 方案二（逻辑过期）：更推荐。缓存永不过期，后台开启一个定时线程，发现缓存中的数据“逻辑过期”后，异步去数据库拉取新数据。在此期间，所有用户读到的都是旧缓存（允许几秒延迟），绝不阻塞用户请求。
第三层：动态接口的“精简与合并” （评论/点赞/阅读数）
热点新闻下，评论刷屏、点赞暴涨，这些动态数据不能直接查库。
- 阅读数（PV）采用批量累加：不要每次浏览都
UPDATE数据库。将计数操作放入 Redis，执行INCR article:1001:view，每隔 5-10 秒再将 Redis 中的增量一次性flush到数据库。 - 评论列表分层加载：
- 第一屏（前 20 条热门评论）：在文章发布时预计算好，直接缓存在 Redis 或本地缓存中，直接返回。
- 第二屏及以后（普通评论）：走 ES（Elasticsearch）或分库分表，允许秒级延迟加载。
- 接口合并（BFF 聚合层）：前端一次请求，后端网关层同时并发调用“文章详情”、“评论数”、“点赞状态”三个服务，合并成一个结果返回，减少客户端建立三次连接的开销。
第四层：特殊的“流量削峰”与“防爬虫”
新闻热点极易引来搜索引擎爬虫和竞品采集脚本，它们的流量甚至超过真人用户。
- UA 与 IP 限流：在 Nginx 层针对
User-Agent为空或频繁请求的 IP，直接返回 403 或验证码挑战，拦截机器流量。 - 降级非核心功能：当热点爆发、CPU 飙高时，立刻降级“相关推荐”、“发布时间线”、“作者粉丝数”等非核心组件，只保证文章正文和评论区能正常展示。
第五层：数据库的“读写分离”与“归档”
- 读流量全部走从库：主库只负责后台编辑写稿，所有前台查询请求一律路由到 2-3 个只读从库，且从库配置为
read_only。 - 冷热分离：当前热点文章放在 SSD 高速存储或 Redis 中；3 天前的历史新闻转移到机械硬盘或 HBase 归档，即使有人翻看也不影响热点库性能。
💡 新闻热点 vs 秒杀抢购 核心差异总结
| 维度 | 秒杀抢购 | 新闻热点 |
|---|---|---|
| 核心压力 | 写压力（扣库存、下订单） | 读压力（浏览、加载图片） |
| 数据一致性 | 极强（不能超卖，必须精确） | 极弱（阅读数差几秒无所谓） |
| 首选武器 | Redis + MQ 异步写 | CDN + 本地缓存（多级缓存） |
| 数据库瓶颈 | 行锁竞争（UPDATE stock） | 连接数被打满（SELECT 过多） |
| 失败后果 | 用户愤怒（抢不到） | 服务器宕机（白屏） |
🚀 一句话实战口诀
新闻热点，尽量把数据“推”到离用户最近的边缘（CDN），实在推不走的（阅读数/评论），用本地缓存扛住，最后用异步写回数据库稀释压力。
如果你是做资讯类 APP 或网站的，最立竿见影的两个动作是：1. 接入 CDN 加速详情页；2. 给热点文章的 Redis 缓存设置“永不过期”+ 异步刷新。这样绝大多数流量根本碰不到你的数据库。