Redis高并发缓存架构常见问题与解决方案

一、 稳定性问题1. 缓存雪崩 (Cache Avalanche)现象大量的 key 在同一时间集中失效或者 Redis 实例宕机导致请求全部涌向数据库瞬间把数据库压垮。解决方案随机过期时间给 key 的 TTL 加上一个随机扰动值如 1~5 分钟避免集体失效。高可用架构部署 Redis Sentinel哨兵或 Redis Cluster集群避免单点故障。多级缓存在Nginx服务器内存- JVM本地内存 - Redis服务器内存 中临时缓存该热点数据。限流熔断降级数据库压力过大时直接返回默认值或错误提示。2. 缓存击穿 (Cache Breakdown)现象一个极其热点的 key比如大促活动的产品信息在失效的瞬间持续的高并发请求直接打到数据库。解决方案双重检查锁 (Double-Checked Locking)当大量并发请求同时发现缓存失效Cache Miss时不立即冲向数据库而是经历以下三个阶段第一重检查 (Pre-check)线程进入方法后先尝试读取缓存。如果命中直接返回。抢占分布式锁 (Locking)如果缓存为空线程尝试获取一个基于 Redis 的分布式锁如 SETNX。第二重检查 (Post-check)这是关键。拿到锁的线程不急着查数据库而是再次读取缓存。因为在它等待锁的过程中前一个抢到锁的线程可能已经完成了数据库查询并回写了缓存。3. 缓存穿透 (Cache Penetration)现象请求的数据在 Redis 和数据库中都不存在比如黑客攻击。这些请求每次都会绕过缓存直达数据库。解决方案布隆过滤器 (Bloom Filter)在缓存前加一层过滤。如果布隆过滤器判断数据不存在则直接返回。布隆过滤器是一种非常节省空间的概率性数据结构二进制数组用于判断一个元素是否存在于一个集合中。工作原理1.初始化一个长度为 m 的比特数组初始全为 0以及 k 个相互独立的哈希函数。2.插入元素对元素用 k 个哈希函数计算得到原始哈希值 再对数组长度 m 取模得到k 个位置将这些位置的比特位设为 1。3.查询元素同样计算 k 个位置如果所有位都是 1则回答“可能存在”只要有任意一位是 0则回答“一定不存在”。缓存空对象即使数据库没查到也把null缓存起来并设置一个较短的过期时间。二、 数据一致性4. 缓存数据库双写不一致现象数据库更新了但缓存还是旧值或者缓存更新了数据库却失败了。解决方案延迟双删先删缓存 - 更新数据库 - 间隔几百毫秒再删一次缓存清除可能产生的脏数据。第二次删除建议异步执行如通过消息队列避免阻塞主线程‌。监听 BinlogCanal中间件监听数据库变更异步通知 Redis 更新。这能保证最终一致性。分布式读写锁读多写少先更新数据库再删除缓存Cache-Aside Pattern以数据库为准缓存仅作为加速层写操作更新 DB 后立即失效缓存‌。