用分布式缓存 Redis 给应用加速的实践笔记

一、数据库为什么需要一个「前台」
应用的读请求往往占八成以上，热门数据被反复查询时，请求全压到数据库上，响应越来越慢、连接数先被打满。分布式缓存服务 DCS（基于 Redis）就是数据库前面的「前台」：把热点数据放进内存，读请求先问缓存，命中就直接返回，毫秒级响应；未命中才回源数据库，并把结果回填缓存。一次合理的缓存改造，常常能把数据库读压力降一个数量级。

二、先想清楚缓存什么
不是所有数据都值得进缓存。我的筛选标准就三条：读多写少（商品详情、配置项、排行榜）、允许短时不一致（晚几秒看到新数据不致命）、单条数据不大。强一致场景如库存扣减、账户余额，不要简单套「先删缓存再写库」的模板，要么走数据库为准的校验，要么用分布式锁串行化。缓存是加速器，不是数据库的替代品——Redis 里的数据随时要能从数据库重建出来。

三、我的实操配置

1. 创建 DCS Redis 实例：测试环境单机版够用；生产选主备或集群版，内存按热点数据量加一倍余量估算，并开数据持久化。
2. 网络打通：实例放在与应用相同的 VPC，安全组只放行应用服务器网段的 6379 端口，绝不对公网开放。
3. 定过期策略：热点数据统一设 TTL（如商品详情 30 分钟）加随机抖动，避免同一时刻大批 key 集体过期。
4. 读写流程：读走「查缓存→未命中查库→回填缓存」；写走「先更新数据库→再删除缓存」，删除失败要进重试队列或订阅 binlog 异步补删。
5. 上线前压测一轮：看命中率（目标 95% 以上）和回源 QPS，命中率上不去多半是 key 设计或预热问题。

四、三大经典问题与解法
缓存穿透：查一个根本不存在的数据，每次都回源打库。解法是把空结果也缓存（短 TTL），或上布隆过滤器先拦一层。
缓存击穿：某个热点 key 过期的瞬间，大量请求同时回源。解法是回源时加互斥锁，只放一个请求去查库重建，其余等待；或者热点 key 逻辑过期、异步刷新。
缓存雪崩：大批 key 同时过期或缓存整体宕机，流量瞬间全压到数据库。解法是 TTL 加随机值、缓存做高可用集群、应用侧加限流降级兜底。

五、常见坑

1. 把 Redis 当消息队列或长期存储用，内存被大 key 和无 TTL 的 key 慢慢吃满，先被淘汰的是别人的热点数据。养成给每个 key 设 TTL 的习惯，并定期用大 key 分析工具巡检。
2. 缓存和数据库双写不一致偶尔出现就慌——先确认业务到底能容忍几秒不一致，多数读场景根本不需要强一致。
3. 只监控实例存活，不看命中率和内存碎片率，等命中率掉下来用户先感知到慢。

六、小结
Redis 缓存的门槛不在部署，而在策略：缓存什么、多久过期、不一致怎么办、缓存挂了怎么降级，这四个问题在上线前想清楚，再配合命中率与大 key 的日常监控，缓存才能稳定地给应用加速，而不是埋一颗偶尔爆炸的雷。