03_1_Redis

Redis核心知识体系整理

一、Redis核心数据结构剖析
5种基础数据结构
String：动态字符串（SDS），预分配内存减少碎片，适用缓存、计数器（INCR）、分布式Session。
Hash：字段数少的场景（如用户属性），底层为压缩列表（ziplist）或哈希表（dict）。
List：双向链表或压缩列表，支持队列、栈、消息流（如微博时间线）。
Set：无序唯一集合，用于标签系统、共同好友（SINTER）。
ZSet：跳表（skiplist） + 哈希表，实现排行榜、延迟队列（按分数排序）。
高级数据结构
Bitmaps：位操作，用于签到统计、布隆过滤器底层实现。
HyperLogLog：基数统计（如UV），误差率0.81%，固定12KB内存。
GEO：地理位置（GEOADD、GEORADIUS），基于ZSet存储。
Stream：消息队列（支持消费者组、ACK机制）。

二、Redis在典型场景的应用实践
微博场景
热点Feed流：使用List或Stream存储用户时间线，分页查询（
LRANGE）。
点赞/转发计数：Hash结构存储post🔢likes，原子操作避免并发问题。
热搜排行榜：ZSet实现实时TopN（ZREVRANGE）。
微信场景
消息缓存：String存储会话消息，设置TTL自动清理。
附近的人：GEO模块计算用户距离（GEORADIUS）。
分布式锁：Redisson锁控制群发消息的并发。
电商场景
秒杀库存扣减：Lua脚本保证原子性（
DECR + 判断≥0）。
购物车：Hash结构存储
cart:user1，字段为商品ID和数量。
商品详情页缓存：String结构缓存HTML片段，解决数据库压力。

三、Redis持久化与安全机制
持久化机制
RDB：定时快照（SAVE/BGSAVE），二进制紧凑文件，恢复快但可能丢失数据。
AOF：追加日志（appendfsync everysec），数据更安全，支持重写（BGREWRITEAOF）压缩日志。
混合持久化（Redis 4.0+）：RDB + AOF，重启时先加载RDB再重放AOF。
安全机制
密码认证：requirepass配置项，客户端需AUTH。
防火墙/IP白名单：限制访问来源。
SSL/TLS（Redis 6.0+）：加密通信。

四、Redis高可用架构
主从复制
原理：全量同步（RDB快照） + 增量同步（复制缓冲区）。
配置：replicaof ，读写分离提升读性能。
哨兵（Sentinel）
功能：监控、自动故障转移、配置中心。
选举机制：Raft算法选主，多数派达成一致。
Cluster集群
数据分片：16384个哈希槽，
CRC16(key) % 16384分配槽位。
节点通信：Gossip协议维护拓扑状态。
扩容/缩容：
redis-cli --cluster reshard迁移槽位数据。

五、客户端与分布式锁实战
Jedis源码剖析
连接池：基于Apache Commons Pool管理连接，避免频繁TCP握手。
Pipeline：批量命令降低网络开销，非原子操作。
Redisson分布式锁
看门狗机制：后台线程续期锁（默认30秒，每10秒续期）。
可重入锁：Lua脚本实现hincrby计数，避免死锁。

六、缓存异常与性能优化
缓存穿透
问题：大量请求不存在的Key（如恶意攻击）。
方案：空值缓存 + 布隆过滤器拦截。
缓存雪崩
问题：大量Key同时失效，请求压垮数据库。
方案：随机过期时间 + 多级缓存（本地缓存+Redis）。
缓存击穿
问题：热点Key失效后高并发请求直达数据库。
方案：互斥锁（Redis锁） + 逻辑过期时间。
布隆过滤器实现
原理：多个哈希函数映射到Bitmaps，可能存在误判。
实现：SETBIT和GETBIT操作，Redisson提供封装API。

七、缓存设计与性能优化
键设计
短命名（如u:123）减少内存占用，冒号分隔层级。
内存优化
使用ziplist、int编码（小整数），控制Hash/List/ZSet的元素数量。
性能调优
禁用KEYS *，使用SCAN分页。
监控慢查询（slowlog get），优化大Key（拆分或压缩）。

总结
Redis的高性能与灵活性使其成为分布式系统核心组件。深入理解数据结构、持久化机制、集群原理及缓存设计模式，结合业务场景选择最佳实践，可显著提升系统稳定性与扩展性。

在大厂项目中，处理缓存雪崩的核心思路是分散风险、兜底容灾、动态调整。以下是具体的解决方案和最佳实践：
一、缓存雪崩的成因
缓存雪崩通常由以下场景引发：
大量缓存同时过期：例如缓存键设置相同过期时间，导致某一时刻集体失效。
缓存层整体宕机：如 Redis 集群故障，所有请求穿透到数据库。
热点数据突发流量：如秒杀活动导致缓存击穿，引发连锁反应。

二、预防性设计（核心手段）

1. 缓存过期时间分散化
   随机过期时间：在基础过期时间上增加随机值（如 基础时间 + 随机(0~300s)）。
   // 示例：设置缓存时添加随机过期时间
   int baseExpire = 3600; // 基础过期时间 1 小时
   int randomExpire = baseExpire + new Random().nextInt(300); // 随机增加 0~5 分钟
   redis.set(key, value, “EX”, randomExpire);

2. 多级缓存架构
   本地缓存 + 分布式缓存：优先读取本地缓存（如 Caffeine），降低对分布式缓存的依赖。
   // 多级缓存读取逻辑（伪代码）
   public Object getData(String key) {
   // 1. 读本地缓存
   Object data = localCache.get(key);
   if (data != null) return data;

   // 2. 读分布式缓存
   data = redis.get(key);
   if (data != null) {
   localCache.put(key, data); // 异步更新本地缓存
   return data;
   }

   // 3. 读数据库并回填
   data = queryDatabase(key);
   redis.set(key, data, randomExpire);
   localCache.put(key, data);
   return data;
   }

3. 热点数据永不过期
   逻辑过期：缓存不设置物理过期时间，但存储逻辑过期时间字段，异步更新。
   // 示例：缓存数据结构
   class CacheItem {
   Object data;
   long logicExpireTime; // 逻辑过期时间
   }

// 读取时检查逻辑过期时间
if (System.currentTimeMillis() > cacheItem.logicExpireTime) {
// 触发异步更新任务
asyncUpdateCache(key);
}

---

三、实时应对策略（兜底方案）

1. 熔断降级
   服务熔断：当数据库 QPS 超过阈值时，触发熔断直接返回默认值。
   // 使用 Hystrix 或 Sentinel 实现熔断
   @HystrixCommand(fallbackMethod = “fallbackData”)
   public Object getData(String key) { /* … */ }

public Object fallbackData(String key) {
return “默认值”; // 或抛出特定异常
}

2. 请求限流
   滑动窗口限流：限制单位时间内允许访问数据库的线程数。
   // 使用 Guava RateLimiter
   RateLimiter limiter = RateLimiter.create(100); // 每秒 100 个请求
   if (limiter.tryAcquire()) {
   queryDatabase(key);
   } else {
   throw new RateLimitException();
   }

3. 缓存预热
   定时任务预热：在缓存过期前异步刷新数据。
   // 示例：使用 Spring Scheduler
   @Scheduled(fixedRate = 30 * 60 * 1000) // 每 30 分钟执行
   public void preheatCache() {
   List hotKeys = getHotKeysFromLogs(); // 从日志分析热点 Key
   hotKeys.forEach(key -> {
   Object data = queryDatabase(key);
   redis.set(key, data, randomExpire);
   });
   }

---

四、灾后恢复（快速止损）

1. 快速扩容
   数据库自动扩缩容：基于云服务的弹性能力（如 AWS Aurora Auto Scaling）。
   缓存集群横向扩展：临时增加 Redis 节点，提升缓存容量。
2. 持久化缓存备份
   Redis RDB/AOF：利用持久化文件快速恢复缓存。
   冷备数据加载：从备份的缓存快照（如 S3）中恢复数据。

---

五、大厂真实案例

1. 某电商大促场景
   问题：秒杀活动导致缓存雪崩。
   解决方案：
   提前预热：活动开始前 1 小时加载商品库存到缓存。
   本地缓存兜底：在网关层缓存商品基本信息，防止 Redis 完全不可用。
   动态限流：根据数据库压力自动调整限流阈值。
2. 某社交平台热点事件
   问题：明星离婚事件导致缓存集群过载。
   解决方案：
   读写分离：将读请求路由到只读副本。
   客户端降级：APP 端自动屏蔽非核心功能（如点赞动画）。

---

六、总结：缓存雪崩处理层次
层级具体措施目标预防层分散过期时间、多级缓存、永不过期降低雪崩发生概率实时应对层熔断、限流、降级保护数据库不被击穿灾后恢复层快速扩容、持久化恢复最小化故障影响时间监控层实时报警、缓存命中率监控、慢查询分析提前发现潜在风险

七、补充：缓存雪崩 vs 缓存击穿 vs 缓存穿透
问题类型特征解决方案缓存雪崩大量缓存同时失效分散过期时间、多级缓存、熔断限流缓存击穿单个热点 Key 失效互斥锁、逻辑过期、永不过期缓存穿透查询不存在的数据（如恶意请求）布隆过滤器、空值缓存、参数校验
通过以上策略的组合使用，大厂项目能够有效应对缓存雪崩，确保系统的高可用性。实际场景中，通常需要结合监控告警和自动化运维工具（如 Prometheus + Grafana）实现全链路防护。