在 Redis 缓存架构中，“被打穿” 是常见且致命的问题，可能直接导致后端数据库崩溃，进而引发系统瘫痪。本文将从核心概念切入，结合实际场景给出可落地的解决办法，助力运维和开发人员筑牢系统缓存防线。

一、Redis 被打穿：是什么与为什么？1. 核心定义

Redis 被打穿指缓存中完全没有请求对应的目标数据，所有请求直接穿透缓存层，集中涌向后端数据库，造成数据库压力骤增、连接池耗尽甚至宕机。

2. 常见触发场景数据不存在导致的穿透：用户请求数据库中本就不存在的 key（如恶意请求不存在的商品 ID），缓存自然无法命中，请求持续直达数据库。热点 key 集中失效：某热门 key（如秒杀商品信息）设置了统一过期时间，到期后大量并发请求同时穿透缓存，瞬间冲击数据库。二、实战解决方案：从防护到落地

解决 Redis 被打穿的核心思路是拦截无效请求、分散缓存压力、保障数据库安全，以下是 4 种主流实战方案，包含具体实现代码与命令。

方案 1：缓存空值 —— 拦截无效请求适用场景

应对 “请求不存在的数据” 场景，比如用户查询不存在的订单、非法 ID 等，避免这类请求反复访问数据库。

实现逻辑当请求查询某 key 时，先查 Redis，若命中直接返回数据。若 Redis 未命中，查询数据库；若数据库也无对应数据，在 Redis 中缓存该 key 的空值（如 "" 或 null），并设置较短过期时间（5-10 分钟，避免占用过多缓存空间）。后续同 key 请求会命中空缓存，直接返回，不再访问数据库。实操代码（Shell+Redis 命令）#!/bin/bash# 缓存空值示例脚本KEY=$1REDIS_CLI="/usr/bin/redis-cli"# 1. 查缓存CACHE_DATA=$($REDIS_CLI GET $KEY)if [ -n "$CACHE_DATA" ]; then echo "缓存命中，返回数据: $CACHE_DATA" exit 0fi# 2. 查数据库（模拟）DB_DATA=$(mysql -u root -p'password' -Nse "SELECT data FROM table WHERE id='$KEY'")if [ -n "$DB_DATA" ]; then # 数据库有数据，写入缓存（过期时间1小时） $REDIS_CLI SET $KEY "$DB_DATA" EX 3600 echo "数据库命中，写入缓存后返回: $DB_DATA"else # 数据库无数据，缓存空值（过期时间5分钟） $REDIS_CLI SET $KEY "" EX 300 echo "数据不存在，缓存空值"fi

方案 2：布隆过滤器 —— 过滤不存在的 key适用场景

数据量极大（如千万级 key）、无效请求频繁的场景，缓存空值会占用过多内存，布隆过滤器可实现高效的 “key 存在性校验”。

实现逻辑提前将数据库中所有有效 key 存入布隆过滤器（一种空间效率极高的概率数据结构）。请求到达时，先经过布隆过滤器校验：若过滤器判断 key 不存在，直接返回；若判断可能存在（存在极小误判率），再走 “缓存→数据库” 流程。实操示例（Redis+Bloom Filter）

Redis 4.0 + 支持布隆过滤器插件redisbloom，以下是核心命令：

加载插件：在redis.conf中添加loadmodule /path/to/redisbloom.so，重启 Redis。添加有效 key：# 初始化布隆过滤器（key为bf_product，预计元素数100万，误判率0.01） redis-cli BF.RESERVE bf_product 0.01 1000000 # 批量添加数据库中的有效商品ID redis-cli BF.ADD bf_product 1001 1002 1003 ...请求校验流程：# 校验key是否存在 IS_EXIST=$(redis-cli BF.EXISTS bf_product $KEY) if [ $IS_EXIST -eq 0 ]; then echo "key不存在，直接返回" exit 0 else # 继续查询缓存和数据库 ... fi方案 3：互斥锁（分布式锁）—— 避免缓存并发重建适用场景

热点 key 集中失效时，防止大量请求同时查询数据库并重建缓存，通过 “串行化重建” 分散压力。

实现逻辑缓存未命中时，尝试获取该 key 的分布式锁，只有获取到锁的请求才能查询数据库并重建缓存。未获取到锁的请求，等待一段时间后重试（或返回默认值），避免同时冲击数据库。重建缓存完成后，释放锁，后续请求即可命中缓存。实操代码（Java+Redisson 实现）

Redisson 是 Redis 的 Java 客户端，简化了分布式锁的实现：

import org.redisson.api.RLock;import org.redisson.api.RedissonClient;import java.util.concurrent.TimeUnit;public Object getHotData(String key) { // 1. 先查缓存 Object cacheData = redissonClient.getBucket(key).get(); if (cacheData != null) { return cacheData; } // 2. 尝试获取分布式锁（锁key与数据key绑定，避免全局锁） RLock lock = redissonClient.getLock("lock:" + key); boolean isLocked = false; try { // 0秒等待获取锁，30秒自动释放（防死锁） isLocked = lock.tryLock(0, 30, TimeUnit.SECONDS); if (!isLocked) { // 未获锁，等待100ms后重试（限制重试次数避免死循环） Thread.sleep(100); return getHotData(key); } // 3. 二次查缓存（防止其他线程已重建） cacheData = redissonClient.getBucket(key).get(); if (cacheData == null) { // 查数据库并重建缓存（设置1小时过期） cacheData = db.query("SELECT * FROM product WHERE id = ?", key); redissonClient.getBucket(key).set(cacheData, 3600, TimeUnit.SECONDS); } return cacheData; } catch (InterruptedException e) { Thread.currentThread().interrupt(); return null; } finally { // 4. 释放锁（必须在finally中执行） if (isLocked) { lock.unlock(); } }}

原生 Redis 命令实现简单锁

若不依赖客户端，可直接用SET命令的原子性实现锁：

# 获取锁：只有key不存在时才设置成功（NX），过期时间10秒（EX）redis-cli SET lock:1001 1 NX EX 10# 释放锁：需用DEL命令删除锁key（需确保只有持有锁的线程能释放）redis-cli DEL lock:1001

方案 4：优化缓存过期策略 —— 避免集中失效适用场景

热点 key 场景下，通过分散过期时间，从源头减少 “同时失效” 的概率。

实现逻辑

给热点 key 的基础过期时间添加随机值（如 10-60 秒），确保即使是同一批热点数据，也会在不同时间点过期，避免并发穿透。

实操示例# 基础过期时间1小时（3600秒），添加10-60秒随机值BASE_EXPIRE=3600RANDOM_EXPIRE=$((RANDOM % 51 + 10)) # 生成10-60的随机数TOTAL_EXPIRE=$((BASE_EXPIRE + RANDOM_EXPIRE))# 写入缓存时设置随机过期时间redis-cli SET product:1001 "{'name':'爆款手机','stock':1000}" EX $TOTAL_EXPIRE三、配套保障措施：让方案更可靠监控告警：通过 Prometheus+Grafana 监控 Redis 命中率（redis_info{metric="keyspace_hits"}/redis_info{metric="keyspace_misses"}），当命中率骤降时触发邮件 / 短信告警。数据库限流：用 Nginx 或 Sentinel 对数据库请求设置限流阈值（如每秒 1000 次），超出阈值时返回 “服务繁忙”，避免数据库被压垮。备份与恢复：即使缓存和数据库出问题，也要通过前文提到的数据库备份策略（如 MySQL 的 mysqldump、PostgreSQL 的 pg_dump）保障数据可恢复。权限控制：限制 Redis 和数据库的访问权限，禁止外部直接访问，减少恶意请求风险。四、总结：分层防护体系

Redis 被打穿的解决需结合场景分层设计，推荐组合策略：

基础层：用 “缓存空值 + 随机过期时间” 覆盖常规场景。海量数据层：叠加 “布隆过滤器” 过滤无效请求。热点场景层：用 “分布式锁” 保障缓存重建时的数据库安全。保障层：通过监控、限流、备份形成闭环，确保系统稳定运行。

通过以上方案，可有效拦截穿透请求、分散数据库压力，让 Redis 真正成为系统的 “性能盾牌” 而非 “安全短板”。