流量洪峰：热门短链接带来的流量冲击

场景

想象一下这个场景：

1. 某明星突然宣布结婚 📱

   • 粉丝疯狂转发相关链接
   • 一小时内点击量从 1000 爆发到 1000万+

2. 重大新闻发布 📰

   • 权威媒体报道重要新闻
   • 相关短链接在社交媒体病毒式传播

3. 限时优惠活动 🎁

   • 网络红人发布限时折扣
   • 短链接瞬间被几十万人同时点击

4. 热门话题讨论 💬

   • 热点话题引发热议
   • 相关讨论和分享激增

真实案例：

• 某电商平台黑五活动期间，短链接点击量单日突破 1 亿次
• 某新闻客户端热门新闻的短链接，3 分钟内被访问 500 万次
• 某娱乐明星绯闻相关链接，2 小时内访问量破千万

问题：系统崩溃的痛苦

当流量突然暴增时，我们的短链接系统会面临什么？

现状问题分析

让我们先看看我们的”完美”系统是如何设计的：

落地思路

• 这个「完美」系统的跳转链路只有一步：拿短码查 urls 表，靠 idx_short_code 定位到那一条记录，取出目标长 URL 直接返回 302。
• 每一次点击都对应一次真实的数据库查询，前面没有任何缓存或旁路能挡掉这次查询。
• 应用实例直接连 MySQL，连接池是链路上唯一的闸门——请求量涨上来时它最先被占满。

这个简单系统在流量洪峰面前的表现：

落地思路

• 洪峰到来时，连接池里的连接被排队占满，新请求拿不到连接就只能等，超时后报 “too many connections”。
• 排在后面的请求要等前面的慢查询做完，响应时间被拉长到秒级，用户点击后长时间无反应。
• 处理速度追不上到达速度时，请求在服务内部持续堆积，内存占用一路上涨，最后被 OOM Killer 直接干掉。
• 整条链路没有任何限流点：后端已经被压垮了，入口层还在源源不断地把请求送进来。

具体故障表现

应对策略：层层递进的防御体系

策略 1：缓存层防护 🛡️

首先，我们需要在最前面加上缓存层：

落地思路

• 在跳转链路最前面插一层 Redis，存「短码 → 目标长 URL」的映射，命中缓存就直接返回 302，不碰数据库。
• 缓存是只读旁路：缓存里没有也不影响主流程，查不到就回落到数据库查询再回填。
• 这一层把绝大多数请求挡在 MySQL 之前，数据库只处理缓存未命中的那部分流量。
• 兜底是 Redis 不可用时降级成直查数据库，而不是让整个跳转功能直接不可用。

缓存策略配置：

落地思路

• 键就用短码本身，不加额外前缀，值存目标长 URL，TTL 按热点时长来定。
• 写入顺序是「先更新数据库，再删缓存」：直接改缓存里的值会和数据库产生不一致。
• 热点短码的 TTL 要比普通链接长，让官宣、抽奖这类短链接在洪峰期一直留在缓存里。
• 兜底是给「查不到」的短码也缓存一个短 TTL 的空标记，防止不存在的短码被反复打到数据库上。

策略 2：负载均衡 ⚖️

单个服务器扛不住？那就用多个！

落地思路

• 在应用前面放一组反向代理（Nginx 或云负载均衡），把请求按连接数或轮询分给多个应用实例。
• 代理侧限制每个上游的并发连接数，避免某一个实例被慢请求占满把整组拖下水。
• 代理必须透传 X-Forwarded-For 和 X-Real-IP，否则后端拿到的全是代理 IP，限流和访问日志都会失真。
• 某个实例挂掉时，代理把它摘掉、流量转给健康实例，用户感知到的是偶发失败而不是整站不可用。

策略 3：流量削峰 📊

防患于未然，在流量达到峰值前就采取措施：

落地思路

• 点击事件不直接同步写 MySQL：入口只做「短码 → 长 URL」的解析，把点击记录投进消息队列，由消费者批量落库。
• 队列把「瞬时到达的点击」和「数据库能消化的写入速度」解耦，突发流量先在队列里排队。
• 队列积压超过阈值时先告警、再降速消费，宁可让统计数据延迟，也不能把数据库写垮。
• 跳转本身不依赖这条链路，所以队列积压只影响统计口径，不影响用户能不能点开链接。

策略 4：降级机制 🔧

系统扛不住时，优雅降级：

落地思路

• 数据库不可用时降级成「只读缓存」：缓存里有就直接 302，没有就返回明确的服务异常页，而不是让请求长时间挂起。
• 给数据库调用设置超时上限，超过就快速失败，把慢查询占住的连接尽快还给连接池。
• 熔断器统计下游失败比例，超过阈值就打开、直接跳过真实调用，快速失败比排队等超时更友好。
• 降级期间只保留核心的「短码 → 长 URL」跳转，统计上报这类非核心能力先关掉。

性能对比测试

让我们对比不同策略的效果：

落地思路

• 对比方式是同一台压测机上逐级叠加策略：裸查数据库 → 加缓存 → 加负载均衡 → 加队列削峰，每一级记录吞吐和响应时间。
• 关注三组数据：缓存命中率、平均响应时间和错误率，跟本章小结里的目标值（命中率 > 80%、响应 < 100ms、错误率 < 1%）对齐。
• 洪峰用突增流量模拟，验证的是系统从峰值回落后能不能自动恢复，而不只是峰值那一瞬间的极限吞吐。
• 结论看趋势：缓存层对数据库负载的削减最直接，削峰和降级决定的是系统会不会崩。

实战策略拆解

Redis 缓存配置

验证要点

• 命中率用 INFO stats 里的 keyspace_hits 和 keyspace_misses 相除得到，这是判断缓存层有没有生效的第一手数据。
• 再用 TTL <短码> 确认热点短码的剩余有效期没有比预期更早归零——TTL 设短了，命中率会莫名其妙往下掉。
• 抽查一个短码的缓存值（GET <短码>），确认里面存的是目标长 URL 而不是整个 302 响应，否则回源时拿到的不是想要的东西。
• 期望看到的命中率达到本章小结里的 80% 目标；低于这个数，先查 TTL 和键的过期策略。

入口层限流策略

入口配置要点

• 入口层负责接住流量，并把请求转发到后端服务。
• 限流和连接控制放在入口层，可以更早保护后端。
• 代理配置的重点是保留必要请求信息，方便后端识别来源和生成日志。

本章小结

面对流量洪峰，我们的防御体系包括：

关键指标

设计原则

1. 缓存优先：尽量使用缓存，减少数据库访问
2. 降级处理：宁可降级也不崩溃
3. 监控预警：及时发现异常，主动处理
4. 弹性伸缩：根据流量动态扩缩容

下一步

我们解决了流量洪峰问题，但还有一个关键挑战：如何在分布式环境中生成全局唯一的短链接 ID？

答案：分布式 ID 生成器。我们将在下一章深入探讨。

---

练习题

练习 1

如果缓存命中率只有 60%，流量从 1000 QPS 增加到 10000 QPS，数据库负载增加了多少？

练习 2

熔断器机制的原理是什么？为什么要在系统中实现熔断？

练习 3

设计一个滑动窗口限流算法，如何实现？

上一章节

限流设计

下一章节

分布式 ID