在面向公众的业务线中，一篇关于特定心理健康话题的热门科普文章，往往会在短时间内迎来巨大的访问流量。如果后端系统仅依靠传统的 SQL 语句直连数据库（例如 SELECT * FROM article WHERE id = X）来提供服务，底层关系型数据库很容易在瞬间的读请求高峰下达到性能瓶颈。
为了缓解数据库压力，开发人员通常会在架构中引入 Redis 作为中间缓存层。然而，在面对高并发请求时，简单的缓存读写逻辑容易暴露出系统脆弱的一面。应对缓存雪崩、穿透与击穿等典型高可用问题，需要后端工程师进行更加细致的防御设计。
随机过期策略应对缓存雪崩
在批量初始化或预热热门心理文章缓存时，如果使用统一的固定过期时间，例如：redisTemplate.set(articleKey, data, 3600, TimeUnit.SECONDS);
这将导致大量文章的缓存在未来的同一时刻集体失效。此时，庞大的并发请求会发现缓存未命中，进而全部转向底层 MySQL 数据库发起查询。这种瞬间的流量洪峰被称为“缓存雪崩”，极易造成数据库资源耗尽甚至宕机。
更为稳健的做法是为缓存的过期时间增加一定范围的随机扰动值（Jitter）。redisTemplate.set(articleKey, data, 3600 + RandomUtils.nextInt(0, 600), TimeUnit.SECONDS);
通过在基础时效上叠加几分钟的随机偏移，可以将大量 key 的失效时间均匀打散。数据库只需承担平缓的回源压力，从机制上避免了集中失效带来的风险。
布隆过滤器阻断缓存穿透
系统在运行过程中，可能面临针对无效参数的恶意请求，例如不断请求一个明显不存在的文章 ID（如 -9999）。由于这类数据在数据库中本就不存在，相应的查询结果自然无法被缓存。这就导致每一次针对该 ID 的请求都会绕过 Redis，直接对数据库发起查询。这种现象被称为“缓存穿透”。
为了防范此类资源消耗攻击，在网关层或 Redis 之前引入布隆过滤器（Bloom Filter）是一种高效的解决方案。系统启动时，将已有真实文章的 ID 经过多次哈希运算映射到位图（BitMap）中。当接到访问请求时，布隆过滤器能快速计算并验证该 ID 的合法性。如果判定 ID 绝对不存在，则直接拦截请求并返回 404 响应，有效切断了恶意请求对后端数据库的扫描。
互斥锁控制缓存击穿
当某篇拥有极高访问量的现象级文章刚好到达缓存过期时间的临界点，可能存在数以千计的并发请求在同一时刻发现 Redis 缓存为空。这些线程如果同时回源查询数据库，试图获取最新数据并回填缓存，会造成瞬间的局部过载，这便是典型的“缓存击穿”问题。
为了规范回源行为，橙星云技术团队在查询底层数据库前增加了分布式锁（例如基于 SETNX 实现的互斥锁）机制。当多个线程同时遭遇缓存未命中时，系统要求它们必须先在 Redis 中竞争获取互斥锁。仅有成功获取锁的单个线程才能执行数据库查询及缓存回填操作，其余线程则进入短暂休眠，随后重试读取缓存。这样一来，同一时刻对相同数据的并发回源被限制在可控范围内，确保了整个文章阅读服务在流量突增情况下的平稳运行。