高并发文章系统架构实战：缓存穿透击穿雪崩的完整解决方案

搞高并发文章系统这个项目，最初只是某公司的内容平台想解决一个看似简单的问题：热门文章一上线，流量瞬间涌入，数据库经常被拖垮。真正动手之后才发现，这个场景简直是高并发架构的"集齐龙珠"现场——读多写少、热点集中、数据一致性要求不低。这篇博客把我在这个模拟项目X里从设计到落地的全过程整理出来，重点是那些压测才会暴露、文档里查不到的细节。

1. 先把问题想清楚：文章系统的高并发到底难在哪

1.1 读多写少的业务特征决定了技术路线

文章类系统的流量模型非常特殊：绝大部分请求是读请求，用户看文章、刷评论、看点赞数；写请求相对少，主要是发布文章、提交评论、点赞。读和写的比例随便就能到几十比一，热门文章出现时这个比例还会更高。我在项目初期就明确了一个基本判断：系统的一切设计都要围绕"如何用尽量少的资源扛住尽量多的读请求"来展开。

这个判断的重要性在于，它直接决定技术选型和资源投入方向。比如数据库选型上，如果一开始就冲着强一致性的分布式数据库去，开发和运维成本会非常高；而如果采用"读链路尽量走缓存、写链路走消息队列异步化"的思路，用普通的单机数据库配合合理的缓存策略，就能扛住十倍以上的流量。这个思路跟互联网行业的"缓存优先、写异步化"是一脉相承的，只是文章场景下读流量更极端，热点更集中，需要更细的打磨。

另一个特征是文章内容本身是高价值、低变更的数据。一篇文章发布后，正文内容基本不变，变更的主要是点赞数、评论数这样的附属数据。这意味着正文可以非常激进地缓存，缓存的时间甚至可以是永久性的，只要发布或编辑时主动淘汰即可。而附属数据进行异步更新时，即使有几秒钟的延迟，用户也几乎无感知。

1.2 三个必须防住的经典故障：穿透、击穿、雪崩

高并发缓存系统绕不开缓存穿透、缓存击穿、缓存雪崩这三个问题，它们在高并发文章场景里表现得尤其典型，我在项目设计阶段就把它们作为必须防住的底线。

缓存穿透是指请求的数据在缓存和数据库中都不存在，每次请求都会直接打到数据库。文章场景里，典型的穿透是恶意请求或者爬虫拿着不存在的文章ID疯狂访问，如果系统没有做拦截，这些请求会绕过缓存直击数据库，数据库连接池很快被耗尽。解决穿透的通用手段是布隆过滤器或者在缓存中缓存空值，但更务实的做法是提前在入口做参数校验和历史ID校验。

缓存击穿是热点文章缓存过期瞬间，大量并发请求同时穿透到数据库。这里有个对比：穿透是"请求一个本来就不存在的数据"，击穿是"请求一个存在但缓存刚好失效的热点数据"。一篇文章刚被推上首页时，如果没有预热机制，缓存里是空的，几千个用户同时点进来，数据库就会斯巴达。击穿的防护重点是热点数据的缓存重建加锁。

缓存雪崩相比之下更严重，它是指在某个时间点大量缓存的key同时失效，比如缓存设置了统一的过期时间，刚好到点集体过期，此时请求全部穿透到数据库，数据库瞬间被打爆。更糟糕的情况是缓存服务本身挂了，所有请求都直接落到数据库。文章场景里，如果所有文章的缓存过期时间都是一样的值，那么同一批次发布的热门文章就会在几分钟内同时触发缓存重建。解决雪崩的思路包括过期时间加随机值、多级缓存、主从高可用等。

2. 整体架构与数据流设计

2.1 读链路：CDN → 本地缓存 → Redis → 数据库

确定"读多写少、缓存优先"的大方向后，我把读链路设计成了四级：CDN、应用本地缓存、Redis分布式缓存、数据库。每一级承担不同的职责，也对应不同的成本和命中率。

CDN缓存的是文章正文这类完全静态的内容。用户访问一篇文章时，浏览器或APP的请求首先被CDN拦截，如果CDN节点上有该文章的缓存，就直接返回，到源站的流量为零。文章正文几乎不变，非常适合CDN；需要注意的是编辑后台发布或修改文章时，要主动调用CDN刷新接口，否则用户会看到旧内容。实际运营中CDN命中率做到95%以上是很常见的，它默默帮我们挡掉了最多的流量。

应用本地缓存是第二道防线，也是容易被忽视的一道。我在项目里用了一个轻量级的本地缓存组件，每个应用节点都缓存最近被访问的一批热点文章摘要。这部分缓存放不了太多数据，适合放"最近N分钟访问量最高的几十篇文章"这样的热点集合。本地缓存最大的特点是快——不走网络，纳秒级响应；缺点是每个节点一份，存在一致性问题，所以只适合放短期可容忍不一致的数据。

Redis分布式缓存承担了主要的缓存职责。文章的正文摘要、点赞数、评论数前几页等数据都放在这里。Redis的命中率直接决定了数据库的压力，项目稳定运行后Redis的命中率基本保持在99%以上，数据库的读请求量被压得很低。数据库则只负责处理缓存未命中的请求和写请求，承担的压力非常小。

四级缓存的每一级都应该有明确的命中率目标和兜底策略。CDN兜不住时靠本地缓存，本地缓存没有时靠Redis，Redis也没有时才去数据库。每一级的多余流量都会被下一级"接住"，除非某一级彻底失效（比如Redis宕机），那就必须靠限流降级来保护数据库。

2.2 写链路：消息队列削峰 + 异步消费落库

文章系统的写操作虽然总量不大，但存在短时集中爆发的可能，比如一场直播活动中评论区被刷屏、某篇文章被热点事件带火后点赞量暴增。如果所有写操作都同步打到数据库，数据库在主键冲突、行锁竞争上的开销会急剧上升。

写链路我采用了"接口接收 → 消息队列 → 异步消费落库"的模型。用户提交的评论和点赞请求，先快速写入消息队列，接口立即返回"提交成功"，后台的消费服务从队列中拉取消息后批量写入数据库，同时更新缓存里的计数。这样数据库的写入压力从"每秒钟几千个随机点"变成了"每秒钟几百个批量插入"，压力不是一个量级。

这里有个取舍：异步化带来了最终一致性，用户提交点赞后，缓存里的点赞数可能有几秒钟的延迟。好在文章场景里这个延迟完全可以接受，用户看到自己的点赞生效有一两秒的等待，不会产生任何反感。真正需要即时一致的场景，可以把某个操作标记为"重要操作"走同步链路，其他全部异步。我在项目里验证过，99%的写请求走异步，系统的整体吞吐量提升是非常可观的。

2.3 解决一致性问题：延迟双删与版本号

缓存系统最头疼的就是"缓存和数据库数据不一致"的问题。文章正文和摘要的变更频率极低，不一致主要出在计数类数据上，比如点赞数。

我先说一个常见的错误做法：先更新数据库再更新缓存，或者先删缓存再更新数据库。先更新再更新的问题在于，如果更新缓存失败，缓存里还是旧数据；先删再更新的问题是，在此过程中有另一个读请求把旧数据重新写回缓存，数据库更新后缓存还是旧的。

在文章系统里，我最常用的是"延迟双删"策略：更新数据库后，先删除缓存；等100毫秒左右，再次删除缓存。第一次删是让读请求在数据库更新前不会命中旧缓存，延迟一段时间再删，是为了删除"数据库更新前那批请求写回的旧缓存值"。这个策略要求删除操作失败时要有重试机制，否则一致性还是会出问题。

对于更严格的场景，可以用版本号方案，在数据里带一个版本字段，更新数据库时版本号+1，缓存的写入逻辑判断"如果版本号比现有的新才写"。我把延迟双删作为默认方案，性能开销小，实现简单；版本号方案只在金额、库存这类强一致场景使用，文章计数类数据其实用不上。

3. 实操落地：关键代码与配置细节

3.1 布隆过滤器拦截无效请求

前面提到缓存穿透的第一道防线是参数校验，但仅仅校验格式是不够的。如果攻击者用一个不存在的文章ID批量请求，格式完全合法，DB照样被打穿。标准的做法是接入布隆过滤器，把所有可能存在的文章ID都放进去，请求进来先判断ID是否在布隆过滤器中，不在就直接返回404。

布隆过滤器的原理是用多个哈希函数把元素映射到一个位数组中，它可能误判（把不存在的判断为存在），但不会漏判（存在的必然能查到）。误判率可以通过位数组长度和哈希函数数量来控制，我用的一种常用参数组合如下：

/** * 布隆过滤器参数：期望插入数量 10_000_000，误判率 1% * 根据公式，位数组长度约 96M（约 96 比特/10万？这里换算下来约 12MB 内存）， * 哈希函数数量为 6 或 7。 * 这里简化起见使用 Guava 的 BloomFilter。 */ BloomFilter<Long> articleIdFilter = BloomFilter.create( Funnels.longFunnel(), // ID 是 Long 类型 10_000_000, // 准备容纳 1000 万个文章 ID 0.01 // 误判率 1% ); // 发布新文章时加入过滤器 articleIdFilter.put(newArticleId); // 请求进来时判断 if (!articleIdFilter.mightContain(requestArticleId)) { return Response.fail("文章不存在"); }

布隆过滤器最大的问题是无法删除元素。文章ID不会回收，这个问题还好；但如果是评论ID这类可能有删除逻辑的，就不能直接用基本布隆过滤器，要用带计数的变种。我在这个项目里只用它过滤文章ID，因为ID只增不减，不存在删除问题。

布隆过滤器本身可以放在Redis里，用一个字符串位图来维护，多个应用节点共享同一个过滤器，这样即使应用重启也不需要重新构建。代价是每次判断要走一次网络，对大并发请求有一定的开销。我实际的做法是两段式：应用启动时从Redis加载一个快照到本地内存（快照是定期生成的一个位数组文件），平时用自己的本地实例做过滤判断，每天凌晨重新加载一次。这样速度极快，也不会因为Redis抖动影响过滤功能。

3.2 Redis缓存重建的互斥锁设计

缓存击穿的经典解决思路是"互斥锁重建"。在缓存miss的时候，只允许一个请求去查数据库并重建缓存，其他请求等待缓存重建完成后直接读缓存。加锁不能依赖数据库，要让Redis自己做，这样不增加数据库负担。

public ArticleMeta getArticleMeta(Long articleId) { // 1. 先读缓存 Object cached = redis.get("article:meta:" + articleId); if (cached != null) { return (ArticleMeta) cached; } // 2. 缓存miss，尝试获取重建锁 String lockKey = "lock:article:meta:" + articleId; boolean locked = redis.setIfAbsent(lockKey, "1", 3, TimeUnit.SECONDS); if (!locked) { // 没拿到锁，说明有其他线程在重建，短暂等待后重试 Thread.sleep(50); return getArticleMeta(articleId); } try { // 3. 双重检查：锁获取成功后可能缓存已经被其他节点重建 cached = redis.get("article:meta:" + articleId); if (cached != null) { return (ArticleMeta) cached; } // 4. 真正查询数据库并重建缓存 ArticleMeta meta = articleDao.queryMeta(articleId); redis.set("article:meta:" + articleId, meta, 30 + random.nextInt(30), TimeUnit.MINUTES); return meta; } finally { redis.delete(lockKey); } }

这段代码有几个细节值得说一下。第一，锁的过期时间不能太短，否则重建数据库还没完成锁就过期了；也不能太长，否则万一持有锁的节点宕机，其他节点会一直拿不到锁。我用的3秒，在数据库查询正常的情况下足够，但如果数据库出现慢查询，这个时间就紧张了，所以还需要监控告警。

第二，拿到锁之后要先做一次双重检查，因为可能在你等待锁的期间，另一个节点的请求已经重建完缓存了。如果直接查数据库再覆盖缓存，一是浪费了一次DB查询，二是可能用旧数据覆盖新数据。双重检查非常必要。

第三，释放锁时直接把key删掉是有风险的，如果锁已经过期被其他线程重新获取，你会把人家的锁删掉。严谨的做法是使用"比较并删除"，用Lua脚本判断当前值是否是自己设置的值，只有匹配才删除。这个项目里为了方便用了直接删除，但在生产环境我强烈建议用Lua脚本来实现安全释放。

3.3 令牌桶限流与降级开关

就算有缓存，也不能让系统无限承受流量。总会有一些极端场景，比如文章被某个大平台疯转，或者有恶意流量攻击，这时必须有主动的限流机制来保护系统。限流有两种最常见的算法：漏桶和令牌桶。漏桶的优点是输出速率恒定，适合保护下游；令牌桶允许一定程度的突发流量，适合大部分业务接口。

文章系统的读接口，我选的是令牌桶。因为用户的行为本身是突发的，早上通勤时间段的访问量就是会暴涨，令牌桶允许这种突发流量在一段时间内被平滑消化。

// 使用 Guava RateLimiter，每秒放 5000 个令牌 RateLimiter limiter = RateLimiter.create(5000); public void handleReadRequest(HttpServletRequest request) { // 非热点文章的接口，走普通限流 if (!limiter.tryAcquire()) { // 超过阈值，快速返回 503 提示稍后重试 throw new TooManyRequestsException(); } // 正常处理 }

但我要特别提醒：单机限流和分布式限流是不同的。RateLimiter是单机限流，每个节点各自有独立的桶，如果系统有多个节点，总容量是节点数乘以单机容量，这会让限流阈值变得不可控。要么就把RateLimiter的阈值按照节点数分摊，要么用Redis实现全局的滑动窗口或令牌桶。项目初期只有两台机器时我用单机限流，后面扩容到多台后，就把限流逻辑改成了基于Redis的分布式实现。

降级开关是另一个必须有的机制。我设计了一个开关中心，可以动态开启或者关闭某些非核心功能。比如当数据库压力过大时，可以一键关闭"评论详情"的实时加载，改为显示缓存中的摘要信息；点赞功能可以在高峰期改为"只记录用户行为，不实时更新计数"。降级开关的关键是开关本身要足够轻量，且默认是关闭状态，不能因为查开关本身拖垮系统。

3.4 读写分离与分库分表策略

当文章总量和评论总量增长到一定程度，单机数据库写入能力会成为瓶颈。读写分离是最先要做的事：主库负责写入，从库负责读取，缓存未命中的读流量全部打到从库。文章系统的读远大于写，一主两从就能把读压力分散开。

分库分表要根据数据量预估来定，不能想当然。文章表核心字段加上索引，单表承载量一般在千万级左右；评论表增长更快、单行更小，可以承载到亿级。我在项目里对文章表按文章ID做了水平分表，分成16张表，规则是articleId % 16；对评论表按文章ID做了分库分表，分成4个库每个库16张表，规则同样是按文章ID取模。这样同一个文章的评论都在同一张表里，查询时不需要跨库聚合。

分库分表带来的最大问题是跨表查询，比如"全局最新文章列表"如果不带分片键，就需要扫描所有分表再合并。文章场景里这种查询并不频繁，可以在搜索引擎或专门的汇总表中处理。更麻烦的是事务不再跨库，原本一个事务里插入文章、更新文章统计信息的两步操作，分库后可能落在不同的库，只能通过消息队列做最终一致。

4. 压测数据与调优过程

4.1 压测方案与工具选择

压测这件事，很多人一上来就用并发数很大的工具猛打，结果数据一塌糊涂还不知道瓶颈在哪。我的做法是分阶段压测，先测单机再测集群，先测读再测写，每一步都留下可对比的数据。

压测工具我用的是开源的压测工具，支持自定义脚本和聚合报告，可以模拟多个并发用户。压测之前必须明确目标：系统要能承受多大的QPS，平均响应时间是多少，错误率不能超过多少。模拟项目X给的目标是：单机处理3000 QPS的读请求，P95响应时间低于200毫秒，错误率低于0.1%。没有这个目标，压测就变成了无头苍蝇。

压测数据要尽量真实。我造了一批模拟文章数据，包括几百篇热点文章（用来压级缓存命中场景）和几百万篇普通文章（用来压缓存miss和DB查询场景）。请求的路径也模拟了真实用户：先经过网关，再走应用层，最后到Redis或MySQL，把网络开销、序列化开销都包含进去。

4.2 第一轮压测：直接打穿

第一轮压测结果惨不忍睹，虽然在意料之中。直接用2000并发连续打热点文章的详情接口，大概跑了30秒，数据库的CPU就飙到了90%以上，接口的P95响应时间飙升到1.8秒，紧接着出现大量超时和连接池等待异常。

排查发现，问题比我想象的还要多。第一，热点文章的缓存key没有预热，压测一开始所有请求都miss，几百个请求同时去查数据库，数据库连接池立刻满了。第二，应用与Redis之间的客户端连接池配置过小，默认只有50个连接，高并发下大量的获取连接超时。第三，业务代码里每次查询都新建了数据库连接，没有使用连接池复用，这个低级错误在低并发时完全看不出来，并发一高就原形毕露。

这几个问题给了一个重要教训：压测不是要证明系统能扛多少流量，而是要暴露系统在流量冲击下哪里先撑不住。第一轮压测的价值就在于此，它用实际数据告诉我们，代码层面的连接复用、连接池参数、缓存预热这些基础工作没做好之前，谈什么架构都是虚的。

4.3 优化后的效果与参数调整

针对第一轮暴露的问题，我做了三轮修正。第一，修复数据库连接的复用，强制应用使用连接池。第二，调大Redis连接池和应用线程池的参数，比如把Redis连接池从50调到了200，应用服务线程池从200调到500，同时注意给每个线程都预留足够的内存空间。第三，实现了热点文章预热的定时任务，在每天流量高峰来临之前，把最近24小时访问量前100的文章ID提前加载到Redis。

修正之后重新压测，同样2000并发打热点文章详情接口，数据库的CPU稳定在10%以下，Redis的CPU在40%左右，接口的P95响应时间降到了35毫秒，错误率为0。这说明缓存策略正在发挥作用，大部分请求都在Redis层面就返回了，数据库几乎无感。

再往后我做了分级压测：把并发数从1000逐步提升到10000，观察系统的QPS曲线和响应时间变化。结果是在6000 QPS左右时，Redis开始出现热点key的线程阻塞，进一步排查是前面提到的热点key重建锁竞争问题。优化锁策略后，单机峰值能稳定扛到8000 QPS，此时响应时间仍在200毫秒以内。这个数据已经超出预期，如果继续堆应用节点，水平扩容后总能力会线性增长。

5. 实战中的坑与排查清单

5.1 缓存与数据库双写不一致的典型场景

双写不一致在文章系统里最常见的表现是：用户在后台修改了文章标题，前台过了很久还是旧标题。我排查过几次这样的问题，原因几乎都出在"更新数据库成功，但删除缓存失败"上。

不少人的第一反应是"删除失败就重试"，但重试的时机和次数很讲究。我在项目里做了一个失败消息表，删除缓存失败时把任务写进表里，由一个补偿任务每隔一段时间扫描这张表，重新删除缓存。补偿任务要注意去重和退避，同一个key删除失败不能无限重试，否则会变成对Redis的二次攻击。

另一个容易踩的坑是用"更新缓存"代替"删除缓存"。有些同学觉得更新缓存一步到位，还能避免删除后缓存miss的瞬时DB压力。但如果同时有两个更新请求并发，后更新的缓存值可能会被先到达的更新覆盖，导致缓存值与数据库不一致。删除缓存则没有这个问题，因为删除之后无论哪个请求来，都是重新从数据库读最新值，天然收敛到一致状态。

5.2 热点key更新风暴

热点文章往往对应一个集中的Redis key，比如"article:hot:list"这个key存储了热门文章列表。当这个key过期或失效时，所有对热门文章列表的请求都会同时打到数据库，这比单篇文章的击穿可怕得多，因为单个key承载的流量非常大。

我在压测中发现，热点列表key的过期时间用固定值时，每过30分钟就准时出现一次数据库请求尖峰。后来我把过期时间改成30分钟加随机0到5分钟的偏移量，尖峰就消失了。这是对付缓存雪崩的一个基础操作，但真的很有效。

更彻底的办法是热点列表的二级缓存。热门文章列表可以拆成两个部分："最近5分钟的实时热门"放在本地缓存，过期时间设60秒；"全天热门"放在Redis，过期时间设30分钟。用户端的请求优先读本地缓存，本地缓存miss了再读Redis，这样即使是全天热门这个key失效，影响也只限于本节点几秒钟的缓存重建窗口，不会扩散到集群。

5.3 线程池与连接池参数陷阱

高并发系统里很多莫名其妙的问题，最后都指向线程池和连接池的"隐性问题"。比如线程池排队的队列长度设置过长，可能导致请求大量堆积在队列中，响应时间变得很长但错误率不高；队列设置过短，流量稍微一波动就触发拒绝策略，错误率飙升。

我推荐的做法是给线程池配置带监控的拒绝策略。技术上的细节是，拒绝策略不能是简单的抛异常，要记录被拒绝的请求数和来源，并触发降级逻辑，比如把请求改走异步流程或者直接返回"稍后重试"的提示。这样系统在极端情况下虽然损失了一部分请求，但不会雪崩。

连接池的参数也有讲究。很多框架的默认连接池大小只有10或者20，这对单机千级QPS的请求来说明显不够。我遇到过最冤的一次事故，就是压测一切正常，上线后流量一大就超时，查了半天发现是HTTP客户端连接池默认最大连接数只有50，实际需求是300。这个问题在压测时被忽略了，因为压测脚本走的是本地回环，延迟低，连接复用率高。后来我养成了一个习惯：每个外部依赖的连接池大小，都要在文档里写明设计容量和压测验证数据。

5.4 常见问题排查速查表

6. 项目复盘：哪些决策最值得保留

6.1 先防雪崩再谈性能

如果让我重新做一遍这个项目，我会把"防雪崩"作为设计的第一原则。性能调优是随时可以做的，但雪崩是系统级的灾难，一旦发生，所有节点都会被拖下水，恢复时间不可控。

防雪崩的优先级高于性能，这意味着一开始就要做的几件事包括：缓存key的过期时间必须带随机偏移、数据库连接必须走连接池且参数经过估算、应用必须有限流和降级开关、每个外部依赖都要考虑它挂掉时的兜底方案。这几点没有哪个是高深的架构技巧，都是很基础很朴素的手段，但真出问题时它们才是保命的。

6.2 小团队也能做的务实取舍

很多人一谈高并发就想到微服务、容器编排、分布式事务这些重武器。但这个项目给我最深的体会是：小团队做高并发系统，务实的取舍比追求技术先进重要得多。我们最终的核心架构就是一个Spring Boot应用加Redis加MySQL加消息队列，没有复杂的服务拆分，没有微服务全家桶，但正是这套简单的架构，在压测和实际运行中都交出了让人满意的答卷。

微服务拆分带来的好处是模块解耦和独立扩展，但代价是运维复杂度成倍增加。项目早期流量没有大到必须拆分的地步时，保持单体应用、模块内部分层，反而开发效率更高、问题排查更快。把微服务的"接口化"思想用起来，在单体内部做好模块隔离，对小团队来说是更现实的选择。

6.3 个人体会

踩过这么多坑之后，我觉得做高并发系统的核心不是技术有多炫，而是对每一个流量路径都有清晰的预判。文章系统的流量模型其实很简单，但简单的事情在高并发下会放大出无数细节问题。每次压测暴露的新问题，我都会更新一遍自己的排查清单，这些清单在后续做其他项目时同样适用，它已经变成了我做技术判断的底层资产。