一、概述
1.1 背景介绍
2024年3月15日凌晨02:37，某电商平台突发大规模故障，用户无法正常下单，页面响应时间从平均200ms飙升至30秒以上，引发大量用户投诉。经紧急排查，这是一起由Redis缓存集群大面积失效引发的雪崩事故，导致数据库瞬间承受超过正常20倍的流量，最终引发全链路系统崩溃。
故障影响：
- 持续时间：43分钟
- 影响订单：约15万单
- 直接损失：约200万元
故障根因：
运营人员在凌晨批量更新商品数据时，未遵循灰度发布流程，导致10万+热门商品缓存同时设置了相同的过期时间（30分钟）。当这批缓存在02:37同时失效时，瞬间引发缓存雪崩，大量请求直接打到MySQL主库，触发连锁反应。
1.2 技术特点
| 特点 |
说明 |
| 高并发脆弱性 |
大规模缓存同时失效导致流量瞬间击穿到数据库 |
| 连锁反应特性 |
缓存层故障迅速传导至数据库层、应用层 |
| 时间敏感性 |
故障发生时间窗口极短（秒级），需要自动化机制 |
| 影响范围广 |
单点缓存故障可能影响整个业务系统 |
1.3 适用场景
本文档适用于以下场景的技术团队：
- 电商平台：秒杀、促销活动等高并发场景
- 社交媒体：热点内容推荐、用户Feed流
- 金融系统：用户账户信息、交易记录缓存
- 内容平台：视频、文章等静态资源缓存
- IoT平台：海量设备状态信息缓存
- 企业应用：会话缓存、权限缓存
1.4 环境要求
| 组件 |
版本要求 |
说明 |
| 操作系统 |
CentOS 7.9+ / Ubuntu 20.04+ |
内核版本需支持TCP优化参数 |
| Redis |
6.2.6+ / 7.0+ |
建议使用Redis 7.0获得更好性能 |
| Redis Cluster |
3主3从 |
最小高可用配置，生产建议6主6从 |
| MySQL |
8.0.28+ |
需要配置主从复制和读写分离 |
| Java |
JDK 11+ / JDK 17+ |
应用服务器运行环境 |
| Spring Boot |
2.7.x / 3.x |
应用框架 |
| Sentinel |
1.8.6+ |
阿里Sentinel流量防护组件 |
| Prometheus |
2.40+ |
监控告警系统 |
| Grafana |
9.3+ |
监控可视化 |
| 硬件配置 |
16C32G |
Redis节点最低配置，建议32C64G |
| 网络带宽 |
万兆网卡 |
缓存集群间需要高速网络 |
二、故障详细复盘
2.1 故障时间线
2.1.1 凌晨01:50 - 平静的夜晚
运维值班工程师正在监控大屏前查看系统指标，一切正常：
# Redis集群状态检查
redis-cli --cluster check 10.0.1.101:6379
# 输出显示：
# M: 10.0.1.101:6379 slots:0-5460 (5461 slots) master
# M: 10.0.1.102:6379 slots:5461-10922 (5462 slots) master
# M: 10.0.1.103:6379 slots:10923-16383 (5461 slots) master
# [OK] All nodes agree about slots configuration.
# [OK] All 16384 slots covered.
关键指标监控正常：
- QPS: 85,000/s（正常范围）
- 内存使用率: 65%
- 命中率: 98.7%
- 响应时间: P99 < 5ms
2.1.2 凌晨02:07 - 运营批量更新
运营人员收到紧急需求，需要批量更新10万个SKU的价格信息。由于时间紧急，未遵循灰度发布流程，直接执行了批量更新脚本：
# 问题代码：批量更新缓存，统一设置30分钟过期
def batch_update_product_cache(product_ids):
redis_client = get_redis_client()
for product_id in product_ids:
product_data = fetch_from_db(product_id)
cache_key = f"product:detail:{product_id}"
# ⚠️ 危险操作：所有key设置相同的过期时间
redis_client.setex(cache_key, 1800, json.dumps(product_data))
print(f"Updated {len(product_ids)} products cache")
# 执行批量更新
product_ids = get_hot_product_ids(limit=100000)
batch_update_product_cache(product_ids) # 02:07执行
2.1.3 凌晨02:37 - 灾难降临
30分钟后，10万个热门商品缓存同时到期失效。此时恰逢凌晨流量小高峰，瞬间发生：
# 监控告警开始疯狂闪烁
# 02:37:02 - Redis命中率暴跌
Redis hit rate: 98.7% -> 12.3% (CRITICAL)
# 02:37:05 - 数据库连接数告警
MySQL connections: 150 -> 2000/2000 (MAX) (CRITICAL)
# 02:37:08 - 应用响应时间告警
API P99 latency: 200ms -> 28000ms (CRITICAL)
# 02:37:12 - 服务器CPU告警
Application server CPU: 25% -> 95% (WARNING)
# 02:37:15 - 数据库慢查询堆积
MySQL slow query count: 0 -> 3500+ (CRITICAL)
运维人员手机开始疯狂响起告警：
# 查看Redis实时命中率
redis-cli info stats | grep keyspace_hits
# 输出：
# keyspace_hits:125847362
# keyspace_misses:892735481 # 缓存未命中数暴增
# instantaneous_ops_per_sec:156782 # QPS暴增
2.1.4 凌晨02:38 - 应急响应
立即拉起应急响应群，开始排查：
# 1. 检查Redis集群状态
redis-cli --cluster check 10.0.1.101:6379
# 集群状态正常，但QPS异常高
# 2. 查看应用日志
tail -f /var/log/application/app.log | grep "ERROR"
# 大量错误日志：
# [ERROR] com.zaxxer.hikari.pool.HikariPool - Connection is not available
# [ERROR] org.springframework.dao.DataAccessResourceFailureException
# 3. 查看MySQL连接数
mysql -u admin -p -e "show processlist" | wc -l
# 输出：2000（已达上限）
# 4. 查看MySQL慢查询
mysql -u admin -p -e "show full processlist" | grep "Sending data"
# 发现大量SELECT查询堵塞
2.1.5 凌晨02:42 - 紧急止血
判断是缓存雪崩，立即采取止血措施：
# 1. 紧急扩容Redis连接池（临时措施）
# 修改应用配置
spring.redis.lettuce.pool.max-active=500
spring.redis.lettuce.pool.max-idle=200
# 2. 限流降级（关键操作）
# 启用Sentinel限流规则
curl -X POST http://sentinel-dashboard:8080/api/rules/flow \
-H "Content-Type: application/json" \
-d '{
"resource": "getProductDetail",
"grade": 1,
"count": 1000,
"strategy": 0,
"controlBehavior": 0
}'
# 3. 数据库读写分离切换
# 将查询流量切换到从库
mysql -u admin -p -e "SET GLOBAL read_only=ON;" -h mysql-slave-1
# 4. 杀掉慢查询
mysql -u admin -p -e "SELECT concat('KILL ',id,';')
FROM information_schema.processlist
WHERE command='Query' AND time>30
INTO OUTFILE '/tmp/kill_slow_queries.sql';"
mysql -u admin -p < /tmp/kill_slow_queries.sql
2.1.6 凌晨02:50 - 缓存预热
#!/bin/bash
# 脚本：emergency_cache_warmup.sh
REDIS_HOST="10.0.1.101"
REDIS_PORT="6379"
# 从数据库查询TOP 10000热门商品
mysql -u admin -p -e "SELECT product_id FROM products
WHERE status=1
ORDER BY sales_count DESC
LIMIT 10000" -N > /tmp/hot_products.txt
# 批量预热缓存，添加随机过期时间
while read product_id; do
# 从数据库读取数据
product_json=$(curl -s "http://api-internal/products/${product_id}")
# 写入Redis，过期时间添加随机值（1800-3600秒）
random_ttl=$((1800 + RANDOM % 1800))
redis-cli -h $REDIS_HOST -p $REDIS_PORT \
SETEX "product:detail:${product_id}" ${random_ttl} "${product_json}"
echo "Warmed up product: ${product_id}, TTL: ${random_ttl}s"
done < /tmp/hot_products.txt
2.1.7 凌晨03:20 - 故障恢复
经过40分钟的紧张处理，系统逐步恢复：
# 验证系统状态
# 1. Redis命中率恢复
redis-cli info stats | grep keyspace
# keyspace_hits:125983746
# keyspace_misses:892856234
# 命中率：93.5%（逐步恢复中）
# 2. 数据库连接数下降
mysql -u admin -p -e "show processlist" | wc -l
# 输出：287（正常范围）
# 3. 应用响应时间恢复
curl -w "@curl-format.txt" -o /dev/null -s "https://api.example.com/health"
# time_total: 0.156s（恢复正常）
# 4. 服务器CPU恢复
top -bn1 | grep "Cpu(s)"
# Cpu(s): 28.3%us（正常范围）
2.2 根因分析
2.2.1 直接原因
缓存雪崩三要素同时满足：
1. 大规模缓存同时失效
# 检查缓存过期时间分布
redis-cli --scan --pattern "product:detail:*" | \
xargs -I {} redis-cli TTL {} | \
sort | uniq -c
# 发现10万个key的TTL完全一致
# 100000 1800
2. 高并发访问请求
# 凌晨时段QPS分析
02:00-02:30 平均QPS: 85,000/s
02:37-02:40 峰值QPS: 156,000/s（几乎翻倍）
3. 数据库承载能力不足
-- MySQL连接池配置过小
SHOW VARIABLES LIKE 'max_connections';
-- max_connections: 2000（不足以应对突发流量）
-- 未配置查询缓存
SHOW VARIABLES LIKE 'query_cache%';
-- query_cache_type: OFF
2.2.2 深层原因
架构设计缺陷：
-
缺乏多级缓存架构
- 只有Redis单层缓存，没有本地缓存（Guava/Caffeine）
- 没有CDN/Nginx缓存层
-
缺乏熔断降级机制
- 未部署Sentinel/Hystrix等熔断组件
- 缓存穿透直接打到数据库，无任何保护
-
监控告警不完善
- 缺少缓存命中率突降告警
- 缺少缓存过期时间分布监控
- 告警阈值设置不合理
-
运维流程不规范
- 批量操作未经过灰度验证
- 凌晨变更未进行风险评估
- 缺少缓存更新规范
2.3 Redis三大缓存问题解析
2.3.1 缓存雪崩（Cache Avalanche）
定义：大量缓存在同一时间失效，导致请求直接打到数据库，引发数据库压力激增。
典型场景：
- 促销活动时批量设置相同过期时间
- Redis服务器宕机导致所有缓存失效
- 缓存预热时未设置随机过期时间
特征表现：
# 缓存命中率断崖式下跌
# 数据库连接数瞬间爆满
# 应用响应时间暴增
# 监控特征
redis-cli info stats
# instantaneous_ops_per_sec: 瞬间翻倍或更高
# keyspace_misses: 短时间内大量增加
2.3.2 缓存穿透（Cache Penetration）
定义：查询一个不存在的数据，缓存和数据库都没有，导致每次请求都打到数据库。
典型场景：
- 恶意攻击，故意查询不存在的key
- 业务逻辑bug，生成了错误的缓存key
- 爬虫遍历，尝试大量无效ID
特征表现：
# 缓存和数据库都查询不到数据
# 数据库慢查询日志中大量SELECT返回空结果
# 示例攻击请求
GET /api/product/999999999 # 不存在的商品ID
GET /api/product/888888888
GET /api/product/777777777
# ... 大量无效请求
2.3.3 缓存击穿（Cache Breakdown/Hotkey）
定义：某个热点key在失效的瞬间，大量并发请求同时访问这个key，导致请求直接打到数据库。
典型场景：
- 热门商品缓存过期
- 明星微博缓存失效
- 秒杀活动开始时缓存失效
特征表现：
# 单个key的访问量极高
redis-cli --hotkeys
# 或使用monitor命令观察
redis-cli monitor | grep "product:detail:12345"
# 数据库中针对某个ID的查询突增
# 同一时间有上千个相同查询
三者对比
| 特性 |
缓存雪崩 |
缓存穿透 |
缓存击穿 |
| 影响范围 |
大量key |
不存在的key |
单个热点key |
| 发生频率 |
周期性集中爆发 |
持续性攻击 |
偶发性瞬时爆发 |
| 数据库压力 |
极高（全面压力） |
中等（无效查询） |
高（集中压力） |
| 业务影响 |
全局服务降级 |
部分性能下降 |
局部抖动 |
| 典型场景 |
批量过期、服务宕机 |
恶意攻击、爬虫 |
热点数据过期 |
三、解决方案实施
3.1 缓存雪崩解决方案
3.1.1 过期时间随机化
// 方案一：在基础过期时间上添加随机值
@Service
public class ProductCacheService {
@Autowired
private RedisTemplate<String, String> redisTemplate;
private static final int BASE_EXPIRE_TIME = 1800; // 30分钟
private static final int RANDOM_RANGE = 600; // 10分钟随机范围
public void cacheProduct(Long productId, ProductDTO product) {
String key = "product:detail:" + productId;
String value = JSON.toJSONString(product);
// 添加随机过期时间：30-40分钟
int expireTime = BASE_EXPIRE_TIME + new Random().nextInt(RANDOM_RANGE);
redisTemplate.opsForValue().set(key, value, expireTime, TimeUnit.SECONDS);
}
// 批量更新时的随机化策略
public void batchCacheProducts(List<ProductDTO> products) {
products.parallelStream().forEach(product -> {
String key = "product:detail:" + product.getId();
String value = JSON.toJSONString(product);
// 每个商品的过期时间都不同
int expireTime = BASE_EXPIRE_TIME +
ThreadLocalRandom.current().nextInt(RANDOM_RANGE);
redisTemplate.opsForValue().set(key, value, expireTime, TimeUnit.SECONDS);
// 避免批量操作过快，添加微小延迟
try {
Thread.sleep(1);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
});
}
}
3.1.2 Redis Cluster高可用配置
#!/bin/bash
# Redis 7.0 Cluster部署脚本
# 文件：setup_redis_cluster.sh
# 集群配置参数
REDIS_VERSION="7.0.12"
CLUSTER_NODES=6
BASE_PORT=7000
# 创建集群目录
mkdir -p /data/redis-cluster
cd /data/redis-cluster
# 为每个节点创建配置
for port in $(seq $BASE_PORT $((BASE_PORT + CLUSTER_NODES - 1))); do
mkdir -p ${port}
cat > ${port}/redis.conf <<EOF
# 基础配置
port ${port}
bind 0.0.0.0
protected-mode yes
requirepass "YourStrongPassword123!"
masterauth "YourStrongPassword123!"
# 持久化配置
dir /data/redis-cluster/${port}
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
# RDB配置
save 900 1
save 300 10
save 60 10000
dbfilename dump.rdb
# 集群配置
cluster-enabled yes
cluster-config-file nodes-${port}.conf
cluster-node-timeout 5000
cluster-require-full-coverage no
# 内存配置
maxmemory 8gb
maxmemory-policy allkeys-lru
# 性能优化
tcp-backlog 511
timeout 300
tcp-keepalive 300
hz 10
dynamic-hz yes
# 慢查询日志
slowlog-log-slower-than 10000
slowlog-max-len 128
# 客户端连接
maxclients 10000
# AOF重写优化
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# 安全配置
rename-command FLUSHDB ""
rename-command FLUSHALL ""
rename-command CONFIG "CONFIG_SECURE_2024"
EOF
# 启动Redis实例
redis-server ${port}/redis.conf --daemonize yes
echo "Started Redis instance on port ${port}"
done
# 等待所有实例启动
sleep 5
# 创建集群（3主3从）
redis-cli --cluster create \
127.0.0.1:7000 \
127.0.0.1:7001 \
127.0.0.1:7002 \
127.0.0.1:7003 \
127.0.0.1:7004 \
127.0.0.1:7005 \
--cluster-replicas 1 \
-a "YourStrongPassword123!"
# 验证集群状态
redis-cli -c -h 127.0.0.1 -p 7000 -a "YourStrongPassword123!" cluster info
redis-cli -c -h 127.0.0.1 -p 7000 -a "YourStrongPassword123!" cluster nodes
Redis Cluster高可用验证：
# 测试集群故障转移
# 1. 查看当前主节点
redis-cli -c -p 7000 -a "YourStrongPassword123!" cluster nodes | grep master
# 2. 模拟主节点故障
redis-cli -p 7000 -a "YourStrongPassword123!" DEBUG SLEEP 30
# 3. 观察从节点自动提升为主节点
redis-cli -c -p 7000 -a "YourStrongPassword123!" cluster nodes
# 4. 验证数据一致性
redis-cli -c -p 7000 -a "YourStrongPassword123!" SET testkey "testvalue"
redis-cli -c -p 7001 -a "YourStrongPassword123!" GET testkey
redis-cli -c -p 7002 -a "YourStrongPassword123!" GET testkey
3.1.3 多级缓存架构
// 应用层本地缓存 + Redis分布式缓存
@Configuration
public class CacheConfig {
// Caffeine本地缓存配置
@Bean
public Cache<String, ProductDTO> localCache() {
return Caffeine.newBuilder()
.maximumSize(10_000) // 最大缓存10000个对象
.expireAfterWrite(5, TimeUnit.MINUTES) // 写入后5分钟过期
.expireAfterAccess(3, TimeUnit.MINUTES) // 访问后3分钟过期
.recordStats() // 启用统计
.build();
}
@Bean
public CacheManager cacheManager(RedisConnectionFactory factory) {
// Redis缓存配置
RedisCacheConfiguration config = RedisCacheConfiguration
.defaultCacheConfig()
.entryTtl(Duration.ofMinutes(30)) // 默认30分钟
.serializeKeysWith(
RedisSerializationContext.SerializationPair
.fromSerializer(new StringRedisSerializer())
)
.serializeValuesWith(
RedisSerializationContext.SerializationPair
.fromSerializer(new GenericJackson2JsonRedisSerializer())
)
.disableCachingNullValues();
return RedisCacheManager.builder(factory)
.cacheDefaults(config)
.build();
}
}
// 多级缓存查询服务
@Service
public class MultiLevelCacheService {
@Autowired
private Cache<String, ProductDTO> localCache;
@Autowired
private RedisTemplate<String, ProductDTO> redisTemplate;
@Autowired
private ProductMapper productMapper;
public ProductDTO getProduct(Long productId) {
String cacheKey = "product:detail:" + productId;
// L1: 本地缓存查询
ProductDTO product = localCache.getIfPresent(cacheKey);
if (product != null) {
log.info("Hit L1 cache: {}", productId);
return product;
}
// L2: Redis缓存查询
product = redisTemplate.opsForValue().get(cacheKey);
if (product != null) {
log.info("Hit L2 cache: {}", productId);
// 回填本地缓存
localCache.put(cacheKey, product);
return product;
}
// L3: 数据库查询（加锁防止击穿）
log.info("Cache miss, query from DB: {}", productId);
product = queryWithLock(productId, cacheKey);
return product;
}
private ProductDTO queryWithLock(Long productId, String cacheKey) {
// 使用分布式锁防止缓存击穿
String lockKey = "lock:" + cacheKey;
RLock lock = redissonClient.getLock(lockKey);
try {
// 尝试加锁，最多等待10秒，锁持有30秒自动释放
if (lock.tryLock(10, 30, TimeUnit.SECONDS)) {
try {
// 双重检查，避免重复查询
ProductDTO product = redisTemplate.opsForValue().get(cacheKey);
if (product != null) {
return product;
}
// 从数据库查询
product = productMapper.selectById(productId);
if (product != null) {
// 写入多级缓存
int expireTime = 1800 + ThreadLocalRandom.current().nextInt(600);
redisTemplate.opsForValue().set(cacheKey, product,
expireTime, TimeUnit.SECONDS);
localCache.put(cacheKey, product);
} else {
// 空值缓存防止穿透
redisTemplate.opsForValue().set(cacheKey,
ProductDTO.empty(), 60, TimeUnit.SECONDS);
}
return product;
} finally {
lock.unlock();
}
} else {
// 加锁失败，降级处理
log.warn("Failed to acquire lock for: {}", productId);
return productMapper.selectById(productId);
}
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
throw new RuntimeException("Lock interrupted", e);
}
}
}
3.2 缓存穿透解决方案
3.2.1 布隆过滤器（Bloom Filter）
// 使用Redisson实现布隆过滤器
@Configuration
public class BloomFilterConfig {
@Bean
public RBloomFilter<Long> productBloomFilter(RedissonClient redissonClient) {
RBloomFilter<Long> bloomFilter = redissonClient.getBloomFilter("product:bloom");
// 初始化布隆过滤器：预期元素数量100万，误判率0.01%
bloomFilter.tryInit(1000000L, 0.0001);
return bloomFilter;
}
}
@Service
public class ProductBloomService {
@Autowired
private RBloomFilter<Long> productBloomFilter;
@Autowired
private ProductMapper productMapper;
// 系统启动时加载所有商品ID到布隆过滤器
@PostConstruct
public void initBloomFilter() {
log.info("Initializing product bloom filter...");
List<Long> productIds = productMapper.selectAllProductIds();
productIds.forEach(productBloomFilter::add);
log.info("Bloom filter initialized with {} products", productIds.size());
}
// 新增商品时添加到布隆过滤器
@EventListener
public void onProductCreated(ProductCreatedEvent event) {
productBloomFilter.add(event.getProductId());
}
// 查询前先经过布隆过滤器
public ProductDTO getProduct(Long productId) {
// 布隆过滤器判断
if (!productBloomFilter.contains(productId)) {
log.warn("Product not exist (by bloom filter): {}", productId);
return null; // 一定不存在，直接返回
}
// 可能存在，继续查询缓存和数据库
return multiLevelCacheService.getProduct(productId);
}
}
3.2.2 空值缓存策略
@Service
public class NullValueCacheService {
@Autowired
private RedisTemplate<String, String> redisTemplate;
private static final String NULL_CACHE_VALUE = "NULL";
private static final int NULL_CACHE_TTL = 60; // 空值缓存60秒
public ProductDTO getProduct(Long productId) {
String cacheKey = "product:detail:" + productId;
// 查询Redis
String cachedValue = redisTemplate.opsForValue().get(cacheKey);
// 命中空值缓存
if (NULL_CACHE_VALUE.equals(cachedValue)) {
log.info("Hit null cache: {}", productId);
return null;
}
// 命中正常缓存
if (cachedValue != null) {
return JSON.parseObject(cachedValue, ProductDTO.class);
}
// 查询数据库
ProductDTO product = productMapper.selectById(productId);
if (product != null) {
// 缓存正常数据
redisTemplate.opsForValue().set(cacheKey,
JSON.toJSONString(product), 1800, TimeUnit.SECONDS);
} else {
// 缓存空值，防止穿透
redisTemplate.opsForValue().set(cacheKey,
NULL_CACHE_VALUE, NULL_CACHE_TTL, TimeUnit.SECONDS);
log.warn("Product not found, cached null value: {}", productId);
}
return product;
}
}
3.3 缓存击穿解决方案
3.3.1 互斥锁（Mutex）
@Service
public class MutexCacheService {
@Autowired
private RedissonClient redissonClient;
@Autowired
private RedisTemplate<String, String> redisTemplate;
public ProductDTO getProductWithMutex(Long productId) {
String cacheKey = "product:detail:" + productId;
// 查询缓存
String cachedValue = redisTemplate.opsForValue().get(cacheKey);
if (cachedValue != null) {
return JSON.parseObject(cachedValue, ProductDTO.class);
}
// 缓存未命中，使用互斥锁
String lockKey = "lock:product:" + productId;
RLock lock = redissonClient.getLock(lockKey);
try {
// 尝试获取锁，最多等待3秒
if (lock.tryLock(3, 10, TimeUnit.SECONDS)) {
try {
// 获取锁成功，双重检查缓存
cachedValue = redisTemplate.opsForValue().get(cacheKey);
if (cachedValue != null) {
return JSON.parseObject(cachedValue, ProductDTO.class);
}
// 查询数据库
ProductDTO product = productMapper.selectById(productId);
if (product != null) {
// 写入缓存（添加随机过期时间）
int expireTime = 1800 + new Random().nextInt(600);
redisTemplate.opsForValue().set(cacheKey,
JSON.toJSONString(product), expireTime, TimeUnit.SECONDS);
}
return product;
} finally {
lock.unlock();
}
} else {
// 获取锁失败，休眠后重试
Thread.sleep(50);
return getProductWithMutex(productId); // 递归重试
}
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
throw new RuntimeException("Lock interrupted", e);
}
}
}
3.3.2 逻辑过期（永不过期）
// 缓存数据包装类
@Data
public class CacheData<T> {
private T data; // 实际数据
private Long expireTime; // 逻辑过期时间（时间戳）
}
@Service
public class LogicalExpireCacheService {
@Autowired
private RedisTemplate<String, String> redisTemplate;
@Autowired
private ThreadPoolExecutor rebuildExecutor; // 异步重建线程池
private static final long CACHE_EXPIRE_SECONDS = 1800L;
public ProductDTO getProductWithLogicalExpire(Long productId) {
String cacheKey = "product:detail:" + productId;
// 查询Redis
String cachedValue = redisTemplate.opsForValue().get(cacheKey);
if (cachedValue == null) {
// 缓存不存在，同步查询数据库并缓存
return rebuildCache(productId, cacheKey);
}
// 解析缓存数据
CacheData<ProductDTO> cacheData = JSON.parseObject(cachedValue,
new TypeReference<CacheData<ProductDTO>>() {});
// 检查逻辑过期时间
if (System.currentTimeMillis() < cacheData.getExpireTime()) {
// 未过期，直接返回
return cacheData.getData();
}
// 逻辑过期，异步重建缓存
String lockKey = "lock:rebuild:" + productId;
RLock lock = redissonClient.getLock(lockKey);
// 尝试获取锁（不等待）
if (lock.tryLock()) {
try {
// 获取锁成功，提交异步任务重建缓存
rebuildExecutor.submit(() -> {
try {
rebuildCache(productId, cacheKey);
} finally {
lock.unlock();
}
});
} catch (Exception e) {
lock.unlock();
log.error("Failed to submit rebuild task", e);
}
}
// 返回过期数据（保证可用性）
return cacheData.getData();
}
private ProductDTO rebuildCache(Long productId, String cacheKey) {
// 从数据库查询
ProductDTO product = productMapper.selectById(productId);
if (product != null) {
// 构建缓存数据（带逻辑过期时间）
CacheData<ProductDTO> cacheData = new CacheData<>();
cacheData.setData(product);
cacheData.setExpireTime(System.currentTimeMillis() +
CACHE_EXPIRE_SECONDS * 1000);
// 写入Redis（不设置过期时间，永不过期）
redisTemplate.opsForValue().set(cacheKey,
JSON.toJSONString(cacheData));
}
return product;
}
}
3.4 熔断降级方案
3.4.1 Sentinel流量防护配置
# application.yml
spring:
cloud:
sentinel:
transport:
dashboard: localhost:8080 # Sentinel控制台地址
port: 8719
datasource:
flow:
nacos:
server-addr: localhost:8848
dataId: ${spring.application.name}-flow-rules
groupId: SENTINEL_GROUP
rule-type: flow
degrade:
nacos:
server-addr: localhost:8848
dataId: ${spring.application.name}-degrade-rules
groupId: SENTINEL_GROUP
rule-type: degrade
@RestController
@RequestMapping("/api/products")
public class ProductController {
@Autowired
private ProductService productService;
// 使用Sentinel限流
@GetMapping("/{id}")
@SentinelResource(
value = "getProductDetail",
blockHandler = "handleBlock", // 限流降级处理
fallback = "handleFallback" // 异常降级处理
)
public Result<ProductDTO> getProduct(@PathVariable Long id) {
ProductDTO product = productService.getProduct(id);
return Result.success(product);
}
// 限流降级处理方法
public Result<ProductDTO> handleBlock(Long id, BlockException ex) {
log.warn("Request blocked by Sentinel: productId={}", id);
// 返回降级数据
ProductDTO fallbackProduct = new ProductDTO();
fallbackProduct.setId(id);
fallbackProduct.setName("商品详情加载中...");
fallbackProduct.setStatus(-1); // 降级标识
return Result.fail(429, "系统繁忙，请稍后再试", fallbackProduct);
}
// 异常降级处理方法
public Result<ProductDTO> handleFallback(Long id, Throwable ex) {
log.error("Exception occurred: productId={}", id, ex);
return Result.fail(500, "服务异常，请稍后再试");
}
}
// Sentinel规则配置类
@Configuration
public class SentinelRuleConfig {
@PostConstruct
public void initRules() {
// 流控规则
initFlowRules();
// 熔断降级规则
initDegradeRules();
// 系统保护规则
initSystemRules();
}
private void initFlowRules() {
List<FlowRule> rules = new ArrayList<>();
// QPS限流：商品详情接口限流1000 QPS
FlowRule rule1 = new FlowRule();
rule1.setResource("getProductDetail");
rule1.setGrade(RuleConstant.FLOW_GRADE_QPS);
rule1.setCount(1000);
rule1.setControlBehavior(RuleConstant.CONTROL_BEHAVIOR_WARM_UP); // 预热模式
rule1.setWarmUpPeriodSec(60); // 预热时长60秒
rules.add(rule1);
// 并发线程数限流
FlowRule rule2 = new FlowRule();
rule2.setResource("queryDatabase");
rule2.setGrade(RuleConstant.FLOW_GRADE_THREAD);
rule2.setCount(200); // 最大并发线程数200
rules.add(rule2);
FlowRuleManager.loadRules(rules);
}
private void initDegradeRules() {
List<DegradeRule> rules = new ArrayList<>();
// 慢调用比例熔断：响应时间超过500ms的请求比例超过50%时熔断
DegradeRule rule1 = new DegradeRule();
rule1.setResource("getProductDetail");
rule1.setGrade(RuleConstant.DEGRADE_GRADE_RT);
rule1.setCount(500); // 响应时间阈值500ms
rule1.setSlowRatioThreshold(0.5); // 慢调用比例50%
rule1.setMinRequestAmount(10); // 最小请求数10
rule1.setStatIntervalMs(10000); // 统计时长10秒
rule1.setTimeWindow(30); // 熔断时长30秒
rules.add(rule1);
// 异常比例熔断：异常比例超过30%时熔断
DegradeRule rule2 = new DegradeRule();
rule2.setResource("queryDatabase");
rule2.setGrade(RuleConstant.DEGRADE_GRADE_EXCEPTION_RATIO);
rule2.setCount(0.3); // 异常比例30%
rule2.setMinRequestAmount(5); // 最小请求数5
rule2.setStatIntervalMs(5000); // 统计时长5秒
rule2.setTimeWindow(60); // 熔断时长60秒
rules.add(rule2);
DegradeRuleManager.loadRules(rules);
}
private void initSystemRules() {
List<SystemRule> rules = new ArrayList<>();
// 系统自适应保护：CPU使用率超过80%时限流
SystemRule rule = new SystemRule();
rule.setHighestSystemLoad(8.0); // Load超过8.0限流
rule.setHighestCpuUsage(0.8); // CPU使用率超过80%限流
rule.setQps(10000); // 系统最大QPS
rule.setAvgRt(500); // 平均响应时间500ms
rule.setMaxThread(2000); // 最大并发线程数
rules.add(rule);
SystemRuleManager.loadRules(rules);
}
}
四、最佳实践和注意事项
4.1 最佳实践
4.1.1 缓存设计最佳实践
合理的过期时间设计
// 根据数据特性设置不同的过期时间
public enum CacheExpireTime {
HOT_DATA(3600, 600), // 热点数据：1小时±10分钟
NORMAL_DATA(1800, 300), // 普通数据：30分钟±5分钟
COLD_DATA(600, 60), // 冷数据：10分钟±1分钟
STATIC_DATA(-1, 0); // 静态数据：永不过期
private final int baseSeconds;
private final int randomRange;
public int getExpireSeconds() {
if (baseSeconds == -1) return -1;
return baseSeconds + ThreadLocalRandom.current().nextInt(randomRange);
}
}
缓存预热策略
#!/bin/bash
# 缓存预热脚本：系统启动时预热热点数据
# 文件：cache_warmup.sh
REDIS_HOST="10.0.1.101"
REDIS_PORT="6379"
REDIS_PASS="YourPassword"
echo "Starting cache warmup at $(date)"
# 1. 预热热门商品（TOP 10000）
mysql -u admin -p -e "SELECT id, name, price, stock, image_url
FROM products
WHERE status=1
ORDER BY sales_count DESC, view_count DESC
LIMIT 10000" -N | while IFS=$'\t' read -r id name price stock image; do
# 构建JSON数据
json_data=$(jq -n \
--arg id "$id" \
--arg name "$name" \
--arg price "$price" \
--arg stock "$stock" \
--arg image "$image" \
'{id:$id, name:$name, price:$price, stock:$stock, imageUrl:$image}')
# 计算随机过期时间
random_ttl=$((3600 + RANDOM % 600))
# 写入Redis
redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS \
SETEX "product:detail:${id}" ${random_ttl} "${json_data}"
echo "Warmed up product: ${id}"
done
# 2. 预热分类数据
redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS \
SET "categories:tree" "$(curl -s http://api-internal/categories/tree)"
# 3. 预热配置数据
redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS \
SET "system:config" "$(curl -s http://api-internal/config)"
echo "Cache warmup completed at $(date)"
缓存更新策略（Cache Aside Pattern）
@Service
public class CacheAsideService {
@Autowired
private RedisTemplate<String, String> redisTemplate;
@Autowired
private ProductMapper productMapper;
// 读操作：先读缓存，缓存未命中再读数据库
public ProductDTO getProduct(Long productId) {
String cacheKey = "product:detail:" + productId;
// 1. 读缓存
String cached = redisTemplate.opsForValue().get(cacheKey);
if (cached != null) {
return JSON.parseObject(cached, ProductDTO.class);
}
// 2. 缓存未命中，读数据库
ProductDTO product = productMapper.selectById(productId);
// 3. 写入缓存
if (product != null) {
redisTemplate.opsForValue().set(cacheKey,
JSON.toJSONString(product), 1800, TimeUnit.SECONDS);
}
return product;
}
// 写操作：先更新数据库，再删除缓存（不是更新缓存）
@Transactional
public void updateProduct(ProductDTO product) {
String cacheKey = "product:detail:" + product.getId();
// 1. 更新数据库
productMapper.updateById(product);
// 2. 删除缓存（延迟双删）
redisTemplate.delete(cacheKey);
// 3. 延迟500ms后再次删除（防止主从延迟导致的脏数据）
CompletableFuture.runAsync(() -> {
try {
Thread.sleep(500);
redisTemplate.delete(cacheKey);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
});
}
}
4.1.2 性能优化
Redis连接池优化
# application.yml
spring:
redis:
host: 10.0.1.101
port: 6379
password: YourPassword
database: 0
timeout: 3000
lettuce:
pool:
max-active: 500 # 最大连接数
max-idle: 200 # 最大空闲连接
min-idle: 50 # 最小空闲连接
max-wait: 3000 # 最大等待时间(ms)
shutdown-timeout: 5000 # 关闭超时
cluster:
max-redirects: 3 # 集群重定向次数
nodes:
- 10.0.1.101:7000
- 10.0.1.102:7001
- 10.0.1.103:7002
Pipeline批量操作
@Service
public class RedisPipelineService {
@Autowired
private RedisTemplate<String, String> redisTemplate;
// 批量查询（使用Pipeline）
public Map<Long, ProductDTO> batchGetProducts(List<Long> productIds) {
List<Object> results = redisTemplate.executePipelined(
new RedisCallback<Object>() {
@Override
public Object doInRedis(RedisConnection connection) {
productIds.forEach(id -> {
String key = "product:detail:" + id;
connection.get(key.getBytes());
});
return null;
}
}
);
// 解析结果
Map<Long, ProductDTO> productMap = new HashMap<>();
for (int i = 0; i < productIds.size(); i++) {
if (results.get(i) != null) {
ProductDTO product = JSON.parseObject(
(String) results.get(i), ProductDTO.class);
productMap.put(productIds.get(i), product);
}
}
return productMap;
}
// 批量写入（使用Pipeline）
public void batchSetProducts(Map<Long, ProductDTO> products) {
redisTemplate.executePipelined(new RedisCallback<Object>() {
@Override
public Object doInRedis(RedisConnection connection) {
products.forEach((id, product) -> {
String key = "product:detail:" + id;
String value = JSON.toJSONString(product);
int expire = 1800 + ThreadLocalRandom.current().nextInt(600);
connection.setEx(key.getBytes(), expire, value.getBytes());
});
return null;
}
});
}
}
Lua脚本原子操作
@Service
public class RedisLuaService {
@Autowired
private RedisTemplate<String, String> redisTemplate;
// Lua脚本：原子性扣减库存
private static final String DEDUCT_STOCK_SCRIPT =
"local stock = redis.call('GET', KEYS[1]) " +
"if not stock then " +
" return -1 " +
"end " +
"if tonumber(stock) >= tonumber(ARGV[1]) then " +
" redis.call('DECRBY', KEYS[1], ARGV[1]) " +
" return 1 " +
"else " +
" return 0 " +
"end";
public boolean deductStock(Long productId, Integer quantity) {
String key = "product:stock:" + productId;
DefaultRedisScript<Long> script = new DefaultRedisScript<>();
script.setScriptText(DEDUCT_STOCK_SCRIPT);
script.setResultType(Long.class);
Long result = redisTemplate.execute(
script,
Collections.singletonList(key),
quantity.toString()
);
return result != null && result == 1;
}
}
4.1.3 高可用配置
Redis Sentinel哨兵模式
# Redis Sentinel配置
# 文件：/etc/redis/sentinel.conf
port 26379
bind 0.0.0.0
protected-mode no
daemonize yes
# 监控主节点
sentinel monitor mymaster 10.0.1.101 6379 2
sentinel auth-pass mymaster YourPassword
# 故障转移配置
sentinel down-after-milliseconds mymaster 5000 # 5秒无响应判定下线
sentinel parallel-syncs mymaster 1 # 同时同步的从节点数
sentinel failover-timeout mymaster 180000 # 故障转移超时3分钟
# 通知脚本
sentinel notification-script mymaster /etc/redis/notify.sh
sentinel client-reconfig-script mymaster /etc/redis/reconfig.sh
# 日志配置
logfile "/var/log/redis/sentinel.log"
自动故障切换验证
#!/bin/bash
# 验证Sentinel自动故障转移
# 1. 查看当前主节点
redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster
# 输出：10.0.1.101 6379
# 2. 模拟主节点故障
redis-cli -h 10.0.1.101 -p 6379 -a YourPassword DEBUG sleep 30
# 3. 等待5-10秒，观察Sentinel日志
tail -f /var/log/redis/sentinel.log
# +sdown master mymaster 10.0.1.101 6379
# +odown master mymaster 10.0.1.101 6379
# +vote-for-leader ...
# +failover-end master mymaster 10.0.1.101 6379
# +switch-master mymaster 10.0.1.101 6379 10.0.1.102 6379
# 4. 确认新主节点
redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster
# 输出：10.0.1.102 6379（已切换）
4.2 注意事项
4.2.1 配置注意事项
⚠️ 警告：以下配置错误可能导致严重的生产事故
1. 缓存过期时间不要设置为固定值
// ❌ 错误示例：所有key相同过期时间
redisTemplate.opsForValue().set(key, value, 1800, TimeUnit.SECONDS);
// ✅ 正确示例：添加随机值
int expire = 1800 + ThreadLocalRandom.current().nextInt(600);
redisTemplate.opsForValue().set(key, value, expire, TimeUnit.SECONDS);
2. 不要在高峰期批量更新缓存
# ❌ 错误：凌晨2点高峰期批量更新
# ✅ 正确：选择凌晨4-5点低峰期，或者分批逐步更新
3. 不要使用keys命令扫描生产环境
# ❌ 危险命令：会阻塞Redis
redis-cli keys "product:*"
# ✅ 正确做法：使用SCAN命令
redis-cli --scan --pattern "product:*"
4. 不要在事务中执行耗时操作
// ❌ 错误：事务中查询Redis
@Transactional
public void updateOrder(Order order) {
orderMapper.updateById(order);
String cacheKey = "order:" + order.getId();
redisTemplate.opsForValue().get(cacheKey); // 可能超时
}
// ✅ 正确：事务外操作缓存
@Transactional
public void updateOrder(Order order) {
orderMapper.updateById(order);
}
// 事务提交后再操作缓存
redisTemplate.delete("order:" + order.getId());
4.2.2 常见错误
| 错误现象 |
原因分析 |
解决方案 |
| 缓存命中率突降至0 |
Redis服务宕机或网络不通 |
1. 检查Redis服务状态<br>2. 检查网络连通性<br>3. 启用多级缓存降级 |
| 大量慢查询堆积 |
缓存雪崩导致流量打到数据库 |
1. 紧急限流<br>2. 缓存预热<br>3. 启用熔断降级 |
| Redis内存溢出 |
未设置过期时间或maxmemory策略 |
1. 设置maxmemory<br>2. 配置淘汰策略<br>3. 清理无效key |
| 数据不一致 |
缓存更新策略错误，主从延迟 |
1. 使用延迟双删策略<br>2. 设置合理的缓存过期时间<br>3. 监控主从延迟 |
| 连接池耗尽 |
连接泄漏或配置过小 |
1. 检查代码是否正确释放连接<br>2. 扩大连接池配置<br>3. 使用连接池监控 |
4.2.3 兼容性问题
版本兼容
- Redis 6.x引入了ACL权限控制，需要配置用户权限
- Redis 7.x改进了集群性能，建议生产环境升级
- Lettuce 6.x与Spring Boot 2.7+兼容性最佳
平台兼容
组件依赖
- Redisson与Spring Data Redis可能存在冲突，选择其一使用
- Sentinel需要配置持久化路径，避免重启后规则丢失
Redis缓存雪崩故障复盘与解决方案（续）
五、故障排查和监控
5.1 故障排查
5.1.1 日志查看
Redis服务日志
# 1. Redis服务日志
tail -f /var/log/redis/redis.log
# 查看错误日志
grep "ERROR\|WARNING" /var/log/redis/redis.log | tail -50
# 2. Redis慢查询日志
redis-cli SLOWLOG GET 50
# 输出格式：
# 1) 1) (integer) 15 # 慢查询ID
# 2) (integer) 1710472620 # 时间戳
# 3) (integer) 15234 # 执行时间(微秒)
# 4) 1) "KEYS" # 命令
# 2) "product:*"
# 配置慢查询阈值
redis-cli CONFIG SET slowlog-log-slower-than 10000 # 10ms
redis-cli CONFIG SET slowlog-max-len 256
应用日志分析
# 3. 应用日志
tail -f /var/log/application/app.log | grep "Redis\|Cache"
# 查看缓存未命中日志
grep "Cache miss" /var/log/application/app.log | \
awk '{print $NF}' | sort | uniq -c | sort -rn | head -20
# 4. Sentinel日志
tail -f /var/log/redis/sentinel.log
# 查看故障转移记录
grep "+switch-master\|+failover" /var/log/redis/sentinel.log
5.1.2 常见问题排查
问题一：缓存命中率突然下降
# 诊断步骤
# 1. 检查Redis服务状态
redis-cli ping
redis-cli info server
# 2. 检查缓存统计信息
redis-cli info stats
# 重点关注：
# keyspace_hits:缓存命中次数
# keyspace_misses:缓存未命中次数
# 命中率 = hits / (hits + misses)
# 3. 检查内存使用
redis-cli info memory
# used_memory_human:已使用内存
# used_memory_peak_human:历史峰值
# mem_fragmentation_ratio:内存碎片率
# 4. 检查key数量变化
redis-cli DBSIZE
# 5. 检查是否有大量过期
redis-cli info keyspace
# db0:keys=100234,expires=95123,avg_ttl=1234567
解决方案：
- 如果Redis正常但命中率低，检查是否有批量过期
- 执行缓存预热脚本恢复热点数据
- 临时降低缓存过期时间，分散过期压力
- 启用多级缓存降级
问题二：Redis内存持续增长
# 诊断命令
# 1. 查看内存详情
redis-cli --bigkeys # 输出最大的key
# 2. 扫描大key
redis-cli --memkeys --memkeys-samples 10000
# 3. 分析内存占用
redis-cli memory doctor # Redis会给出内存使用建议
# 4. 查看未设置过期的key
redis-cli --scan --pattern "*" | while read key; do
ttl=$(redis-cli TTL "$key")
if [ "$ttl" -eq "-1" ]; then
echo "No expire: $key"
fi
done | head -100
解决方案：
# 1. 为无过期时间的key设置合理TTL
redis-cli --scan --pattern "temp:*" | \
xargs -I {} redis-cli EXPIRE {} 3600
# 2. 删除无用的大key（使用UNLINK异步删除，不阻塞）
redis-cli UNLINK large_key_name
# 3. 配置内存淘汰策略
redis-cli CONFIG SET maxmemory 8gb
redis-cli CONFIG SET maxmemory-policy allkeys-lru
问题三：Redis连接数异常增长
# 诊断命令
# 1. 查看当前连接数
redis-cli CLIENT LIST | wc -l
# 2. 查看连接详情
redis-cli CLIENT LIST
# 输出格式：
# id=12345 addr=10.0.1.50:34567 fd=8 age=123 idle=0 ...
# 3. 按IP统计连接数
redis-cli CLIENT LIST | \
awk '{print $2}' | cut -d'=' -f2 | cut -d':' -f1 | \
sort | uniq -c | sort -rn
# 4. 查看空闲连接
redis-cli CLIENT LIST | awk '$12 > 300' | wc -l
解决方案：
# 1. 检查应用是否存在连接泄漏
# 2. 优化连接池配置
# 3. 关闭空闲连接
# 关闭空闲超过5分钟的连接
redis-cli CLIENT LIST | \
awk '$12 > 300 {print $2}' | \
cut -d'=' -f2 | \
xargs -I {} redis-cli CLIENT KILL {}
5.1.3 调试模式
# 1. 开启Redis命令监控（生产慎用）
redis-cli MONITOR
# 输出所有执行的命令：
# 1710472620.123456 [0 10.0.1.50:34567] "GET" "product:detail:12345"
# 1710472620.234567 [0 10.0.1.51:45678] "SET" "user:session:abc" "..."
# 2. 实时查看Redis统计信息
watch -n 1 'redis-cli info stats | grep -E "instantaneous|keyspace"'
# 3. 使用redis-cli交互式调试
redis-cli --intrinsic-latency 100 # 测试Redis自身延迟
redis-cli --latency # 持续测试网络延迟
redis-cli --latency-history # 延迟历史分布
应用日志配置：
# application.yml
logging:
level:
io.lettuce.core: DEBUG # 开启Lettuce调试日志
# Sentinel调试
# redis-cli -p 26379 CONFIG SET loglevel debug
5.2 性能监控
5.2.1 关键指标监控
#!/bin/bash
# 实时监控脚本
# 文件：redis_monitor.sh
REDIS_HOST="10.0.1.101"
REDIS_PORT="6379"
REDIS_PASS="YourPassword"
while true; do
clear
echo "========== Redis Monitor $(date) =========="
# 1. QPS监控
echo "--- QPS Metrics ---"
redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS \
info stats | grep "instantaneous_ops_per_sec"
# 2. 命中率监控
echo "--- Hit Rate ---"
stats=$(redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS info stats)
hits=$(echo "$stats" | grep "keyspace_hits" | cut -d':' -f2 | tr -d '\r')
misses=$(echo "$stats" | grep "keyspace_misses" | cut -d':' -f2 | tr -d '\r')
total=$((hits + misses))
if [ $total -gt 0 ]; then
hit_rate=$(awk "BEGIN {printf \"%.2f\", ($hits/$total)*100}")
echo "Hit Rate: ${hit_rate}%"
fi
# 3. 内存监控
echo "--- Memory Usage ---"
redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS \
info memory | grep -E "used_memory_human|used_memory_peak_human|mem_fragmentation_ratio"
# 4. 连接数监控
echo "--- Connections ---"
redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS \
info clients | grep "connected_clients"
# 5. 慢查询监控
echo "--- Slow Queries (Last 10) ---"
redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS \
SLOWLOG GET 10 | grep -A 3 ")"
# 6. Key空间监控
echo "--- Keyspace ---"
redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASS \
info keyspace
sleep 5
done
5.2.2 Prometheus监控配置
# Prometheus监控规则
# 文件：prometheus/redis_rules.yml
groups:
- name: redis_alerts
interval: 30s
rules:
# 缓存命中率告警
- alert: RedisCacheHitRateLow
expr: |
(
rate(redis_keyspace_hits_total[5m]) /
(rate(redis_keyspace_hits_total[5m]) + rate(redis_keyspace_misses_total[5m]))
) < 0.8
for: 2m
labels:
severity: warning
service: redis
annotations:
summary: "Redis缓存命中率过低"
description: "Redis实例 {{ $labels.instance }} 缓存命中率为 {{ $value | humanizePercentage }}，低于80%"
# 内存使用率告警
- alert: RedisMemoryHigh
expr: redis_memory_used_bytes / redis_memory_max_bytes > 0.85
for: 5m
labels:
severity: warning
service: redis
annotations:
summary: "Redis内存使用率过高"
description: "Redis实例 {{ $labels.instance }} 内存使用率为 {{ $value | humanizePercentage }}"
# 连接数告警
- alert: RedisConnectionsHigh
expr: redis_connected_clients > 8000
for: 3m
labels:
severity: warning
service: redis
annotations:
summary: "Redis连接数过高"
description: "Redis实例 {{ $labels.instance }} 连接数为 {{ $value }}，超过阈值8000"
# QPS异常告警
- alert: RedisQPSSpike
expr: |
rate(redis_commands_processed_total[1m]) >
avg_over_time(rate(redis_commands_processed_total[1m])[10m:1m]) * 2
for: 2m
labels:
severity: critical
service: redis
annotations:
summary: "Redis QPS异常激增"
description: "Redis实例 {{ $labels.instance }} QPS为 {{ $value }}，超过平均值2倍"
# 主从延迟告警
- alert: RedisReplicationLag
expr: redis_replication_lag_seconds > 10
for: 3m
labels:
severity: warning
service: redis
annotations:
summary: "Redis主从复制延迟"
description: "Redis从节点 {{ $labels.instance }} 复制延迟 {{ $value }}秒"
# 慢查询告警
- alert: RedisSlowQueriesHigh
expr: rate(redis_slowlog_length[5m]) > 10
for: 5m
labels:
severity: warning
service: redis
annotations:
summary: "Redis慢查询过多"
description: "Redis实例 {{ $labels.instance }} 慢查询速率为 {{ $value }}/s"
5.2.3 Grafana仪表板配置
{
"dashboard": {
"title": "Redis监控大屏",
"panels": [
{
"title": "QPS",
"targets": [
{
"expr": "rate(redis_commands_processed_total[1m])",
"legendFormat": "{{ instance }}"
}
],
"type": "graph"
},
{
"title": "缓存命中率",
"targets": [
{
"expr": "rate(redis_keyspace_hits_total[5m]) / (rate(redis_keyspace_hits_total[5m]) + rate(redis_keyspace_misses_total[5m]))",
"legendFormat": "{{ instance }}"
}
],
"type": "gauge",
"thresholds": [
{"value": 0.8, "color": "red"},
{"value": 0.9, "color": "yellow"},
{"value": 0.95, "color": "green"}
]
},
{
"title": "内存使用",
"targets": [
{
"expr": "redis_memory_used_bytes",
"legendFormat": "Used - {{ instance }}"
},
{
"expr": "redis_memory_max_bytes",
"legendFormat": "Max - {{ instance }}"
}
],
"type": "graph"
},
{
"title": "连接数",
"targets": [
{
"expr": "redis_connected_clients",
"legendFormat": "{{ instance }}"
}
],
"type": "graph"
},
{
"title": "Top慢查询",
"targets": [
{
"expr": "topk(10, redis_slowlog_length)",
"legendFormat": "{{ instance }}"
}
],
"type": "table"
}
]
}
}
监控指标说明：
| 指标名称 |
正常范围 |
告警阈值 |
说明 |
| 缓存命中率 |
>95% |
<80% |
低于80%需要检查缓存策略和数据热度 |
| 内存使用率 |
60-80% |
>85% |
超过85%触发内存淘汰，可能影响性能 |
| QPS |
业务相关 |
突增2倍+ |
QPS突增可能是缓存雪崩或攻击 |
| 响应时间P99 |
<10ms |
>50ms |
P99超过50ms需要优化或扩容 |
| 连接数 |
<5000 |
>8000 |
连接数过高可能存在连接泄漏 |
| 慢查询速率 |
0/s |
>10/s |
慢查询过多需要优化命令或数据结构 |
| 主从延迟 |
<1s |
>10s |
延迟过大影响数据一致性 |
| 内存碎片率 |
1.0-1.5 |
>2.0 |
碎片率过高需要重启整理内存 |
5.3 备份与恢复
5.3.1 RDB备份策略
#!/bin/bash
# Redis RDB备份脚本
# 文件：redis_backup.sh
BACKUP_DIR="/data/redis-backup"
REDIS_CLI="redis-cli -h 10.0.1.101 -p 6379 -a YourPassword"
DATE=$(date +%Y%m%d_%H%M%S)
RETENTION_DAYS=7
# 创建备份目录
mkdir -p $BACKUP_DIR
# 触发RDB持久化
echo "Starting Redis backup at $(date)"
$REDIS_CLI BGSAVE
# 等待BGSAVE完成
while true; do
status=$($REDIS_CLI LASTSAVE)
sleep 5
new_status=$($REDIS_CLI LASTSAVE)
if [ "$status" != "$new_status" ]; then
echo "BGSAVE completed"
break
fi
done
# 复制RDB文件到备份目录
cp /data/redis-cluster/7000/dump.rdb $BACKUP_DIR/dump_${DATE}.rdb
# 压缩备份文件
gzip $BACKUP_DIR/dump_${DATE}.rdb
# 上传到远程存储（可选）
# aws s3 cp $BACKUP_DIR/dump_${DATE}.rdb.gz s3://mybucket/redis-backup/
# 清理过期备份
find $BACKUP_DIR -name "dump_*.rdb.gz" -mtime +$RETENTION_DAYS -delete
echo "Backup completed: dump_${DATE}.rdb.gz"
5.3.2 AOF备份策略
AOF持久化配置：
# AOF持久化配置
# redis.conf
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec # 每秒同步，性能和可靠性平衡
# AOF重写配置
auto-aof-rewrite-percentage 100 # AOF文件增长100%时触发重写
auto-aof-rewrite-min-size 64mb # AOF文件至少64MB才重写
# AOF加载配置
aof-load-truncated yes # 允许加载截断的AOF文件
# 混合持久化（Redis 4.0+）
aof-use-rdb-preamble yes # AOF重写时使用RDB格式，性能更好
AOF备份脚本：
#!/bin/bash
# AOF备份脚本
# 文件：aof_backup.sh
BACKUP_DIR="/data/redis-backup/aof"
REDIS_DIR="/data/redis-cluster/7000"
DATE=$(date +%Y%m%d_%H%M%S)
mkdir -p $BACKUP_DIR
# 触发AOF重写
redis-cli -a YourPassword BGREWRITEAOF
# 等待重写完成
sleep 10
# 复制AOF文件
cp $REDIS_DIR/appendonly.aof $BACKUP_DIR/appendonly_${DATE}.aof
gzip $BACKUP_DIR/appendonly_${DATE}.aof
echo "AOF backup completed: appendonly_${DATE}.aof.gz"
5.3.3 恢复流程
#!/bin/bash
# Redis数据恢复脚本
# 文件：redis_restore.sh
BACKUP_FILE=$1
REDIS_DIR="/data/redis-cluster/7000"
if [ -z "$BACKUP_FILE" ]; then
echo "Usage: $0 <backup_file.rdb.gz>"
exit 1
fi
echo "=== Redis数据恢复流程 ==="
# 1. 停止Redis服务
echo "Step 1: 停止Redis服务"
redis-cli -a YourPassword SHUTDOWN SAVE
systemctl stop redis-server
sleep 3
# 2. 备份当前数据
echo "Step 2: 备份当前数据"
if [ -f "$REDIS_DIR/dump.rdb" ]; then
cp $REDIS_DIR/dump.rdb $REDIS_DIR/dump.rdb.backup_$(date +%Y%m%d_%H%M%S)
fi
# 3. 解压并恢复备份文件
echo "Step 3: 恢复备份数据"
gunzip -c $BACKUP_FILE > $REDIS_DIR/dump.rdb
chown redis:redis $REDIS_DIR/dump.rdb
chmod 644 $REDIS_DIR/dump.rdb
# 4. 重启Redis服务
echo "Step 4: 启动Redis服务"
systemctl start redis-server
sleep 5
# 5. 验证数据完整性
echo "Step 5: 验证数据恢复"
redis-cli -a YourPassword PING
redis-cli -a YourPassword DBSIZE
redis-cli -a YourPassword INFO keyspace
echo "=== 恢复完成 ==="
恢复验证清单：
#!/bin/bash
# 验证脚本
# 文件：verify_restore.sh
REDIS_CLI="redis-cli -a YourPassword"
echo "开始验证数据恢复..."
# 1. 验证服务状态
echo "1. Redis服务状态"
$REDIS_CLI PING
# 2. 验证数据量
echo "2. Key总数"
$REDIS_CLI DBSIZE
# 3. 验证关键数据
echo "3. 验证关键业务数据"
$REDIS_CLI EXISTS "product:detail:12345"
$REDIS_CLI GET "system:config"
# 4. 验证集群状态（如果是集群模式）
echo "4. 集群状态"
$REDIS_CLI CLUSTER INFO
# 5. 验证主从同步
echo "5. 主从同步状态"
$REDIS_CLI INFO replication
# 6. 对比恢复前后数据量
echo "6. 数据量对比"
echo "恢复前Key总数: $(cat /tmp/key_count_before.txt)"
echo "恢复后Key总数: $($REDIS_CLI DBSIZE)"
echo "验证完成"
六、总结
6.1 事故复盘总结
时间轴回顾：
| 时间 |
事件 |
影响 |
| 02:07 |
运营批量更新10万商品，设置统一过期时间30分钟 |
埋下隐患 |
| 02:37 |
缓存集体失效，触发雪崩，系统全面告警 |
服务不可用 |
| 02:42 |
应急响应：限流、扩容、慢查询清理 |
止血措施 |
| 02:50 |
缓存预热，逐步恢复 |
服务恢复中 |
| 03:20 |
系统完全恢复 |
故障持续43分钟 |
直接损失：
- 影响订单：约15万单
- 经济损失：约200万元
- 用户投诉：3500+
- 品牌声誉受损
深层原因：
- 架构缺陷：单层缓存，无多级防护
- 监控盲区：缓存过期时间分布未监控
- 流程缺失：批量操作未经过灰度验证
- 应急不足：缺乏自动化熔断降级
6.2 技术要点回顾
Redis三大缓存问题
| 问题类型 |
解决方案 |
| 缓存雪崩<br>大量key同时失效 |
• 过期时间随机化<br>• 多级缓存架构<br>• Redis Cluster高可用 |
| 缓存穿透<br>查询不存在的数据 |
• 布隆过滤器<br>• 空值缓存<br>• 参数校验 |
| 缓存击穿<br>热点key失效 |
• 互斥锁<br>• 逻辑过期<br>• 热点数据永不过期 |
高可用架构
- Redis Cluster：3主3从，自动故障转移
- Sentinel哨兵：主从自动切换，最小化故障时间
- 多级缓存：本地缓存 + Redis + 数据库，层层防护
熔断降级
- Sentinel流控：QPS限流、慢调用熔断、异常比例熔断
- 系统自适应保护：CPU、Load、线程数自动限流
- 优雅降级：返回兜底数据，保证基本可用
监控告警
- 缓存命中率：<80%告警
- QPS突增：超过平均2倍告警
- 内存使用：>85%告警
- 主从延迟：>10s告警
6.3 改进措施和预防方案
已实施改进：
✅ 架构优化
- 部署本地缓存（Caffeine），命中率提升至99.2%
- 升级Redis Cluster至6主6从，容量和可用性翻倍
- 部署Sentinel流量防护，自动熔断降级
✅ 监控完善
- Prometheus全方位监控（QPS、命中率、延迟、内存）
- Grafana实时大屏，可视化关键指标
- 告警规则优化，分级告警（P0/P1/P2）
✅ 流程规范
- 制定《缓存操作规范》强制Code Review
- 批量操作必须灰度发布，分批执行
- 凌晨变更需要技术委员会审批
✅ 应急演练
- 每月一次缓存故障演练
- 自动化故障恢复脚本
- 应急响应时间从43分钟降至10分钟以内
6.4 进阶学习方向
1. Redis高级特性
- 研究Redis 7.0新特性（Function、Sharded Pub/Sub）
- 深入理解Redis数据结构（SDS、跳表、压缩列表）
- 掌握Redis Cluster扩容和缩容操作
2. 分布式缓存架构
- 研究大厂多级缓存架构（淘宝Tair、微信Redis）
- 学习一致性Hash和分片策略
- 实践缓存预热和缓存穿透防护
3. 可观测性建设
- 构建全链路监控体系（应用→缓存→数据库）
- 实现分布式追踪（Jaeger/SkyWalking）
- 建立SLI/SLO指标体系
6.5 参考资料
📚 官方文档
📖 推荐书籍
- 《Redis设计与实现》 - Redis内部实现原理详解
- 《Redis开发与运维》 - 生产环境实战经验
🌐 社区资源
- Redis中国用户组 - 中文社区和案例分享
- 阿里云Redis最佳实践 - 生产环境实战经验
附录
A. 命令速查表
Redis基础命令
# === 服务管理 ===
redis-cli PING # 测试连接
redis-cli INFO # 查看服务信息
redis-cli INFO stats # 查看统计信息
redis-cli INFO memory # 查看内存信息
redis-cli INFO replication # 查看主从复制信息
redis-cli DBSIZE # 查看key总数
redis-cli CLIENT LIST # 查看客户端连接
# === 集群管理 ===
redis-cli --cluster check <host:port> # 检查集群状态
redis-cli --cluster info <host:port> # 查看集群信息
redis-cli --cluster fix <host:port> # 修复集群
redis-cli --cluster reshard <host:port> # 重新分片
redis-cli CLUSTER NODES # 查看集群节点
redis-cli CLUSTER INFO # 查看集群状态
# === 性能分析 ===
redis-cli --latency # 测试延迟
redis-cli --latency-history # 延迟历史
redis-cli --bigkeys # 查找大key
redis-cli --hotkeys # 查找热key
redis-cli --stat # 实时统计
redis-cli SLOWLOG GET 100 # 查看慢查询
# === 数据操作 ===
redis-cli --scan --pattern "prefix:*" # 扫描key（不阻塞）
redis-cli TTL <key> # 查看过期时间
redis-cli EXPIRE <key> <seconds> # 设置过期时间
redis-cli PERSIST <key> # 移除过期时间
redis-cli TYPE <key> # 查看key类型
redis-cli OBJECT ENCODING <key> # 查看value编码
# === 持久化 ===
redis-cli SAVE # 同步保存（阻塞）
redis-cli BGSAVE # 后台保存（不阻塞）
redis-cli LASTSAVE # 最后保存时间
redis-cli BGREWRITEAOF # 后台重写AOF
# === 监控调试 ===
redis-cli MONITOR # 实时监控所有命令（生产慎用）
redis-cli DEBUG OBJECT <key> # 查看key详细信息
redis-cli MEMORY DOCTOR # 内存诊断建议
redis-cli MEMORY STATS # 内存详细统计
# === Sentinel ===
redis-cli -p 26379 SENTINEL masters # 查看所有主节点
redis-cli -p 26379 SENTINEL slaves mymaster # 查看从节点
redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster # 获取主节点地址
redis-cli -p 26379 SENTINEL failover mymaster # 手动故障转移
B. 配置参数详解
Redis核心配置参数：
# ====== 网络配置 ======
bind 0.0.0.0 # 绑定IP，0.0.0.0表示所有网卡
port 6379 # 监听端口
tcp-backlog 511 # TCP连接队列长度
timeout 300 # 客户端空闲超时（秒），0表示永不超时
tcp-keepalive 300 # TCP keepalive时间
# ====== 内存配置 ======
maxmemory 8gb # 最大内存限制
maxmemory-policy allkeys-lru # 内存淘汰策略
# noeviction: 不淘汰，写入报错（默认）
# allkeys-lru: LRU算法淘汰所有key
# volatile-lru: LRU算法淘汰设置了过期时间的key
# allkeys-lfu: LFU算法淘汰所有key
# volatile-lfu: LFU算法淘汰设置了过期时间的key
# allkeys-random: 随机淘汰所有key
# volatile-random: 随机淘汰设置了过期时间的key
# volatile-ttl: 淘汰即将过期的key
# ====== 持久化配置 ======
# RDB配置
save 900 1 # 900秒内至少1次修改则保存
save 300 10 # 300秒内至少10次修改则保存
save 60 10000 # 60秒内至少10000次修改则保存
stop-writes-on-bgsave-error yes # RDB失败停止写入
rdbcompression yes # RDB文件压缩
rdbchecksum yes # RDB文件校验
# AOF配置
appendonly yes # 开启AOF
appendfilename "appendonly.aof" # AOF文件名
appendfsync everysec # AOF同步策略
# always: 每次写入同步（慢但最安全）
# everysec: 每秒同步（推荐）
# no: 由操作系统决定（快但可能丢失数据）
auto-aof-rewrite-percentage 100 # AOF文件增长100%触发重写
auto-aof-rewrite-min-size 64mb # AOF文件最小64MB才重写
aof-use-rdb-preamble yes # 混合持久化（推荐）
# ====== 集群配置 ======
cluster-enabled yes # 开启集群模式
cluster-config-file nodes.conf # 集群配置文件
cluster-node-timeout 15000 # 节点超时时间（毫秒）
cluster-require-full-coverage no # 部分节点故障时是否继续服务
# ====== 安全配置 ======
requirepass YourStrongPassword # 密码认证
masterauth YourStrongPassword # 主从认证密码
rename-command FLUSHDB "" # 禁用危险命令
rename-command FLUSHALL "" # 禁用危险命令
rename-command CONFIG "CONFIG_SECRET_2024" # 重命名命令
# ====== 性能优化 ======
hz 10 # 后台任务执行频率（1-500）
dynamic-hz yes # 动态调整hz
slowlog-log-slower-than 10000 # 慢查询阈值（微秒）
slowlog-max-len 128 # 慢查询日志最大长度
maxclients 10000 # 最大客户端连接数
# ====== 高级配置 ======
lazyfree-lazy-eviction yes # 异步删除淘汰的key
lazyfree-lazy-expire yes # 异步删除过期的key
lazyfree-lazy-server-del yes # 异步删除服务器端key
replica-lazy-flush yes # 从节点异步清空数据
C. 术语表
| 术语 |
英文 |
解释 |
| 缓存雪崩 |
Cache Avalanche |
大量缓存在同一时间失效，导致请求直接打到数据库，引发数据库压力激增甚至宕机的现象 |
| 缓存穿透 |
Cache Penetration |
查询一个不存在的数据，缓存和数据库都没有，导致每次请求都要查询数据库的现象 |
| 缓存击穿 |
Cache Breakdown/Hotkey |
某个热点key在失效的瞬间，大量并发请求同时访问这个key，导致请求直接打到数据库的现象 |
| 布隆过滤器 |
Bloom Filter |
一种空间效率极高的概率型数据结构，用于判断一个元素是否在集合中，可能有误判但不会漏判 |
| 热点数据 |
Hot Data |
访问频率极高的数据，通常占总数据量的10-20%但承载80-90%的访问流量 |
| 冷数据 |
Cold Data |
访问频率很低的数据，长时间不被访问 |
| 多级缓存 |
Multi-Level Cache |
使用多层缓存架构（如本地缓存+分布式缓存+数据库），提高系统可用性和性能 |
| 缓存预热 |
Cache Warming |
系统启动时主动加载热点数据到缓存，避免启动初期的缓存未命中 |
| 缓存淘汰 |
Cache Eviction |
当缓存满时，根据策略删除部分数据为新数据腾出空间 |
| 主从复制 |
Master-Slave Replication |
主节点的数据自动复制到从节点，实现数据冗余和读写分离 |
| 哨兵模式 |
Sentinel Mode |
Redis高可用方案，通过哨兵节点监控主从节点，实现自动故障转移 |
| 集群模式 |
Cluster Mode |
Redis分布式方案，将数据分片存储在多个节点，提供横向扩展能力 |
| 分片 |
Sharding |
将数据按照一定规则分散存储到多个节点，实现负载均衡和容量扩展 |
| 槽位 |
Slot |
Redis Cluster中的数据分片单位，共16384个槽位 |
| 故障转移 |
Failover |
主节点故障时，自动将从节点提升为主节点的过程 |
| RDB |
Redis Database |
Redis快照持久化方式，定期保存数据集的全量快照 |
| AOF |
Append Only File |
Redis日志持久化方式，记录每次写操作，重启时重放恢复数据 |
| 混合持久化 |
Hybrid Persistence |
RDB和AOF混合使用，兼顾性能和数据安全性 |
| 慢查询 |
Slow Query |
执行时间超过阈值的命令，可能影响Redis性能 |
| 大key |
Big Key |
占用内存较大的key（如包含百万元素的集合），可能导致阻塞 |
| 热key |
Hot Key |
访问频率极高的key，可能成为性能瓶颈 |
| Pipeline |
Pipeline |
批量发送命令到Redis，减少网络往返次数，提高吞吐量 |
| Lua脚本 |
Lua Script |
在Redis服务端执行的原子性脚本，保证多命令的原子性 |
| 熔断 |
Circuit Breaker |
当服务故障率超过阈值时，暂停对该服务的调用，防止级联故障 |
| 降级 |
Degradation |
在系统压力过大时，关闭部分非核心功能，保证核心功能可用 |
| 限流 |
Rate Limiting |
限制单位时间内的请求数量，防止系统过载 |
| QPS |
Queries Per Second |
每秒查询数，衡量系统吞吐量的指标 |
| P99延迟 |
P99 Latency |
99%的请求响应时间，衡量系统性能的关键指标 |
| 命中率 |
Hit Rate |
缓存命中次数占总请求次数的比例，反映缓存效果 |
结语
本文通过一次真实的Redis缓存雪崩故障，系统性地讲解了缓存三大问题（雪崩、穿透、击穿）的原理、排查方法和解决方案。希望本文能够帮助读者：
✅ 理解缓存故障的本质原因和影响
✅ 掌握多级缓存架构设计方法
✅ 学会使用熔断降级保护系统
✅ 建立完善的监控告警体系
✅ 提升故障应急响应能力
记住：缓存是把双刃剑，用好了能大幅提升性能，用不好可能成为系统最大的隐患。只有深入理解缓存原理，建立完善的防护机制，才能在高并发场景下保证系统的稳定性和可用性。
发表于 昨天 02:32
|
查看: 7|
回复: 0
