后端缓存技术学习：Redis实战案例解析
前言：当高并发遇上数据库瓶颈
最近在开发一个电商促销系统时，我们遇到了明显的性能瓶颈。当万人秒杀活动开始时，MySQL数据库几乎被压垮，响应时间从平时的毫秒级直接飙升到秒级。DBA团队急得团团转，运维同学疯狂扩容也解决不了根本问题。此时，我意识到是时候系统性地引入缓存层了。
Redis初体验：从安装到"Hello World"
**安装环节**对于新人来说总是一个挑战。在CentOS环境下，直接`yum install redis`可能会遇到版本过低的问题。我选择下载最新稳定版源码编译安装：
```bash
wget http://download.redis.io/releases/redis-6.2.6.tar.gz
tar xzf redis-6.2.6.tar.gz
cd redis-6.2.6
make && make install
```
启动Redis服务后，激动人心的一刻到来了------第一个Redis命令：
```redis
127.0.0.1:6379> SET welcome "Hello Redis!"
OK
127.0.0.1:6379> GET welcome
"Hello Redis!"
```
这个小实验让我感受到了Redis的超高性能，即使在本地虚拟机环境下，QPS也能轻松破万。
实战案例一：商品详情页缓存设计
**原始方案问题**：我们的商品详情页每次请求都要查询5张关联表，包括SKU基本信息、库存、价格、评价统计等。通过NewRelic监控发现，这一个页面的数据库查询就占了整体响应时间的70%。
**解决方案**：采用了多级缓存策略
-
**第一层**：本地缓存（Caffeine）存储变化频率低的静态数据
-
**第二层**：Redis缓存完整商品聚合数据
-
**防雪崩机制**：对热点商品采用互斥锁防止缓存击穿
代码实现核心片段：
```java
public ProductDetail getProductDetail(Long skuId) {
// 先查本地缓存
ProductDetail detail = localCache.get(skuId);
if(detail != null) return detail;
// 构建Redis的key
String redisKey = "product:" + skuId;
// 查询Redis
String json = redisTemplate.opsForValue().get(redisKey);
if(json != null) {
detail = JSON.parseObject(json, ProductDetail.class);
localCache.put(skuId, detail);
return detail;
}
// 缓存不存在，获取分布式锁
RLock lock = redissonClient.getLock("lock:product:" + skuId);
try {
lock.lock();
// 再次检查缓存（Double Check）
json = redisTemplate.opsForValue().get(redisKey);
if(json != null) return JSON.parseObject(json, ProductDetail.class);
// 查询数据库
detail = productService.queryFromDB(skuId);
// 写入Redis，设置30分钟过期
redisTemplate.opsForValue().set(
redisKey,
JSON.toJSONString(detail),
30,
TimeUnit.MINUTES
);
return detail;
} finally {
lock.unlock();
}
}
```
**效果验证**：TP99响应时间从1200ms降低到25ms，数据库QPS下降80%。
实战案例二：秒杀系统中的库存扣减
秒杀场景最核心的问题就是**超卖**。我们最初的版本直接用MySQL行锁实现：
```sql
UPDATE stock SET count = count - 1 WHERE sku_id = ? AND count > 0
```
在高并发下，这个方案导致大量请求阻塞，最终拖垮整个数据库。
**Redis优化方案**：
-
提前将秒杀商品库存加载到Redis
-
使用Redis的DECR原子命令扣减库存
-
配合Lua脚本保证操作的原子性
库存初始化：
```redis
SET seckill:stock:1001 500
```
扣减逻辑Lua脚本：
```lua
local stock = tonumber(redis.call('GET', KEYS[1]))
if stock > 0 then
return redis.call('DECR', KEYS[1])
else
return -1
end
```
Java调用示例：
```java
Long result = redisTemplate.execute(
new DefaultRedisScript<>(luaScript, Long.class),
Collections.singletonList("seckill:stock:" + skuId)
);
if(result >= 0) {
// 扣减成功，创建订单
} else {
// 库存不足
}
```
**额外优化点**：
-
使用Redis集群分散热点Key压力
-
引入本地库存缓存减少Redis访问
-
异步记录真实扣减日志
最终效果：支撑了每秒2万次的库存校验请求，无任何超卖情况。
踩坑经验：Redis不是银弹
虽然Redis表现惊艳，但在实践过程中也踩了不少坑：
- **缓存一致性问题**：某次商品价格变更后，缓存未及时失效，导致用户看到旧价格
- 解决方案：采用订阅binlog的缓存失效机制
- **大Key问题**：有个业务把10MB的JSON存入Redis，导致集群内存不均
- 解决方案：拆分为多个子Key
- **持久化阻塞**：在save配置不当时，BGSAVE导致服务短暂不可用
- 解决方案：调整为AOF模式并合理配置rewrite策略
总结：缓存设计的黄金法则
通过这几个月的Redis实战，我总结了几个重要原则：
-
**缓存应该作为加速手段而非唯一真理源**
-
**始终考虑缓存失效的应对方案**
-
**监控必须到位**（命中率、响应时间、内存使用）
-
**Key命名规范要统一**（推荐`业务:子业务:ID`的格式）
-
**适当使用数据结构**（别把Redis当纯KV用，合理使用Hash、ZSet等）
缓存技术的世界博大精深，我们一起继续探索前进。你在使用Redis时遇到过哪些有趣的问题？欢迎评论区分享交流！