我之前在团队里带队做高并发项目的时候几乎所有接口性能瓶颈最后都卡在数据库上。那时候每天看着监控面板上陡峭的QPS曲线和时不时飘红的慢查询真的会睡不着觉。后来我们把Redis缓存系统地用起来从最简单的热点数据缓存到分布式锁、缓存穿透防护、一致性治理一步步踩坑填坑才算真正把Redis用明白。这篇文章就是一次个人项目经验的完整复盘把我这几年来在真实业务场景里用Redis做缓存的所有心得、代码、配置、排障过程都整理出来。无论你是刚接触Redis的新手还是已经被线上缓存问题折腾过几次的开发这篇文章都值得你静下心来读完一遍因为里面写的每一步都是有代价换来的。1. Redis为什么是最常见的缓存选型1.1 本地缓存与集中式缓存的取舍很多项目一开始做性能优化最容易想到的就是在应用内存里搞一个ConcurrentHashMap或者Caffeine当缓存。这个方案在单机场景下确实香——没有网络开销读取速度是纳秒级别的。但一旦你的服务部署了多个实例本地缓存就变成各玩各的A实例更新了缓存B实例还在用旧数据。我见过一个真实案例用户支付成功后状态一直不更新因为请求被负载均衡分发到了多个实例只有其中一个实例的本地缓存失效了。排查了半天最后发现是本地缓存没做分布式失效。这就是集中式缓存存在的意义。Redis作为集中式缓存所有实例共享同一份缓存数据天然避免了多实例数据不一致的问题。而且它基于内存存储单线程IO多路复用单节点QPS可以轻松突破10万这个性能对于绝大多数业务场景完全够用。1.2 Redis与Memcached的差异分析当年选型的时候我们也在Redis和Memcached之间纠结过。Memcached出道更早纯KV缓存内存管理非常高效多线程模型在大流量下表现也很好。但有几个硬伤不支持持久化重启全丢用于缓存还能接受想干点别的就不行了。数据结构单一只能存字符串业务上想存一个用户对象还得自己序列化成JSON做字段更新更是麻烦。不支持主从复制和集群的自动故障转移运维成本高。Redis能打的地方恰恰在于它有五种其实还有BitMap、HyperLogLog、Geo等丰富的数据结构支持RDB和AOF两种持久化方式原生支持主从复制、哨兵模式和Cluster集群模式。所以后来Redis成了社区事实上的标准很多中间件原生的缓存组件也都是基于Redis做的适配。1.3 Redis缓存的适用场景边界Redis缓存不是万能的我在实际项目里总结了几条判断标准读多写少的数据且读的频率远高于更新的频率才适合放缓存。数据不是唯一的准确来源允许在极端情况下短暂不一致比如几秒内。单个数据条目的访问次数足够高摊薄缓存维护成本。数据量可控不能大到内存放不下的程度除非上集群。反过来如果是强一致的金融类数据、写频繁且读写比例接近的数据、或者一次性访问后再也不碰的数据都不适合用缓存。这条边界要是不守好后面出现的问题会非常棘手。2. 核心数据类型与缓存场景的精准对应2.1 String类型缓存的应用String是Redis里最基础也最常用的类型底层是SDS动态字符串支持二进制安全。在缓存场景里它的典型用法包括用户会话Token存储SET token:9527 eyJhbGciOi... EX 7200配合过期时间实现会话自动失效。对象序列化存储把用户信息、商品详情、配置项序列化成JSON字符串存入读取时反序列化即可。计数器场景利用INCR、INCRBY做点赞数、访问数统计因为Redis单线程模型保证原子性并发下不会出错。分布式锁SET lock:order:9527 uuid NX EX 3这个后面详细讲。String类型需要注意的一个点单个value值过大会造成网络传输和内存分配的浪费我一般建议单条value控制在10KB以内超过这个值就要考虑拆分或者换用Hash结构。2.2 Hash类型在对象缓存中的优势这是我个人最喜欢的缓存数据结构。它存储的是一个对象字段的映射类似于key - field - value的三层结构。对比String序列化整个对象Hash的优点是可以只获取或更新对象的某个字段不用像String那样整存整取。修改某几个字段时不用反序列化整个对象再序列化回去省CPU省流量。更贴近业务实体的结构代码可读性强。举个例子缓存用户基础资料HSET user:9527 name 张三 age 24 city 杭州 HGET user:9527 name HINCRBY user:9527 age 1当用户只修改年龄时这个操作只更新一个字段其他字段不会动。如果是String存储整个JSON修改年龄需要把整个用户对象读出来、反序列化、改字段、再序列化、写回去性能和代码复杂度都差一些。2.3 List、Set、ZSet在特定场景的妙用这些结构我在实际业务里也踩出了经验List做消息队列、时间线列表。比如微信公众号的粉丝Timeline每个用户的关注列表用LPUSH插入新消息IDLRANGE分页读取LTRIM裁剪长度防止无限增长。注意List做队列时消费端用BRPOP阻塞读取可以实现可靠的消息传递比轮询效率高一个量级。Set做去重统计、标签系统、好友关系。比如SADD user:9527:tags 技术 生活求两个用户的共同好友用SINTER统计UV去重用SCARD。Set天然去重的特性让它在缓存场景自带防重能力。ZSet做排行榜、热榜、延时队列。分数作为排序依据比如ZADD rank:general 1000 user:9527排行榜展示用ZREVRANGE取前N名更新分数用ZINCRBY。延时队列的思路是把任务放入ZSetscore是执行时间戳轮询时用ZRANGEBYSCORE取出到期的任务执行。2.4 Bitmap与HyperLogLog的极简内存方案这两个结构在某些场景下能省掉90%以上的内存属于用好了会“上瘾”的那种。Bitmap做用户签到、在线状态、布隆过滤器。比如记录用户一年365天的签到SETBIT sign:9527 200 1查询某天是否签到GETBIT sign:9527 200统计全年签到天数用BITCOUNT sign:9527。一个用户一年只占365bit也就是45字节10万用户签到数据不到5MB这如果放数据库里是几百万行记录。HyperLogLog做海量UV统计误差率在0.81%左右。比如PFADD page:index:20240501 user:9527统计当天UV用PFCOUNT。我在做埋点访问统计时用的就是它每天几千万的访问记录最后只用了12KB内存就完成了UV去重统计这个数据量如果用Set存储至少得几百MB。3. 缓存读写架构与淘汰机制设计3.1 Cache Aside读写流程详解这是目前业界应用最广泛的缓存模式也是我项目里的基础架构。读请求流程应用先查询Redis缓存。如果命中直接返回数据。如果未命中查询MySQL数据库。数据库查询成功后将数据写入Redis设置过期时间。返回数据给前端。写请求流程先更新数据库。数据库更新成功后删除Redis中对应的缓存。下次读请求未命中缓存重新从数据库加载并回填。这个流程里的关键点是“先更新库再删缓存”而不是“先删缓存再更新库”。为什么因为如果先删缓存再更新库在并发场景下会出现一个空窗期另一个请求读到旧数据回填到缓存而数据库更新还没完成缓存就成了旧值缓存的过期时间也被拉长了。后面我会在第6章详细展开这个顺序问题的并发分析。3.2 TTL过期策略与惰性删除Redis的过期删除采用两种方式结合惰性删除和定期删除。惰性删除当客户端访问一个key时Redis会检查这个key是否设置了过期时间且已过期如果已过期则删除并返回nil。这种策略的缺点是过期的key如果一直不被访问就会一直占着内存。定期删除Redis每隔一段时间默认100ms随机抽取一批设置了过期时间的key进行检查发现过期就删除。因为不可能全表扫描所以用的是“随机抽取检查”的方式。两者的组合确保了大部分过期key能及时被清理内存不会被无限占用同时把性能损耗控制在了很小的范围内。我建议在实际项目中给缓存设置过期时间时一定要加上随机偏移防止大量key在同一时刻集中过期导致缓存雪崩。比如基准过期时间是1小时实际设置时可以加一个0到5分钟的随机值。3.3 LRU/LFU淘汰策略的选型思考当Redis内存达到配置上限maxmemory时需要通过淘汰策略来腾出空间。我见过太多项目默认不配置淘汰策略导致Redis内存打满后直接拒绝服务引发线上故障。这个坑一定要提前躲开。Redis提供的淘汰策略里最常用的有allkeys-lru从所有key中按最近最少使用原则淘汰。volatile-lru从设置了过期时间的key中按LRU淘汰。allkeys-lfu从所有key中按访问频率最少原则淘汰适用于存在热点和非热点差异明显的场景。noeviction默认策略内存满了不淘汰任何key写请求直接报错。我个人的经验是纯缓存场景用allkeys-lru就够了如果某些key访问频率极高且是核心热数据就用allkeys-lfu因为LRU在“批量偶发扫描”的场景下很容易让热key被淘汰LFU对访问频率的统计更平滑。配置方式maxmemory 4096mb maxmemory-policy allkeys-lru maxmemory-samples 10maxmemory-samples是LRU近似的采样数量默认5加大到10可以提升淘汰精度但会略微增加CPU消耗实践中这个值是性能和准确度之间不错的平衡点。3.4 热点Key与过期时间的联动设计热点Key的缓存失效处理要特别小心。如果某个key访问量极高当它过期的一瞬间会有大量请求同时打到数据库这就是缓存击穿。我在项目中用过两种方案第一种互斥锁方案当缓存未命中时不是所有请求都去查库而是先获取一个分布式锁例如SET lock:hot:9527 uuid NX EX 5拿到锁的请求查库并回填缓存其他请求等待短暂时间后重新查缓存。这种方案可以保证数据库不会被打爆但会让部分请求的响应时间变长。第二种逻辑过期方案缓存里存的数据带上一个逻辑过期时间字段比如“缓存真实有效期是30秒但Redis不设置过期时间业务自己判断逻辑是否过期”。当发现逻辑过期时立即返回旧数据同时启动一个异步线程去数据库刷新缓存。这种方案的优点是响应快不用等待锁缺点是实现复杂度高且极端情况下数据不够新。我最终采用的是“互斥锁热点探测”的组合热点key不设置物理过期时间而是通过一个独立的后台任务周期性刷新缓存这样既能保证数据不过期又能避免热点key失效时的击穿问题。冷门key还是用标准TTL方案简单有效。4. 缓存问题治理穿透、击穿、雪崩与布隆过滤器4.1 缓存穿透的成因与空值缓存方案缓存穿透是指查询一个数据库中不存在的数据因为这个数据本身不存在所以缓存里也不可能命中每次请求都会直接打到数据库。如果攻击者恶意构造大量不存在的ID发起请求数据库压力会瞬间飙升。我在实际项目中遇到过一次接口对外暴露了商品ID有人写脚本遍历ID范围请求大部分ID在数据库里都不存在每次请求都穿透到MySQL单库QPS直接被打到上千接口大量超时。解决方案有两个思路第一缓存空值。对于从数据库查询不存在的结果也往Redis里写一个空值缓存过期时间可以设置得短一些比如60秒这样后续请求在缓存窗口期内都会被拦截。伪代码如下data redis.get(product:9527) if data is None: product db.query(select * from product where id9527) if product is None: redis.set(product:9527, , ex60) return None redis.set(product:9527, json.dumps(product), ex3600) return product这里有个坑需要注意——如果用SET去覆盖已经存在的空值缓存会导致每次“不存在”的查询都延长空值缓存的生命周期因此更推荐用SET NX配合过期时间确保空值缓存一旦存在就只依赖于第一次写入时的过期时间。第二布隆过滤器。在缓存前面再加一层布隆过滤器把数据库里可能存在的ID提前加载到过滤器里。请求到达时先判断ID是否存在于过滤器中如果不在直接返回不存在根本不会进数据库查询。4.2 布隆过滤器的原理与实现细节布隆过滤器本质上是一个很长的二进制位数组和多个哈希函数。插入一个元素时用多个哈希函数计算位置把对应位全部置为1。查询一个元素是否存在时同样计算多个哈希位置只要发现任何一位是0就说明这个元素一定不存在如果全都是1则说明可能存在因为有哈希碰撞的存在。这个“存在可能误判不存在一定精准”的特性应用到缓存穿透防护里非常顺手把数据库中所有合法ID加载进布隆过滤器然后处理请求时先查过滤器不存在的直接拦掉。我当时用Redis内置的布隆过滤器模块RedisBloom实现BF.RESERVE product_filter 0.0001 100000000 BF.ADD product_filter 9527 BF.MEXISTS product_filter 9527 9528参数说明0.0001是期望的误判率100000000是预估的元素数量误判率越低、元素越多位数组占用空间就越大。自己估算一下一亿量级的元素误判率万分之一大概需要240MB左右的内存对于导致数据库崩溃的请求量来说这点内存完全值得。4.3 缓存击穿与互斥锁方案实战前面简单提到了热点key失效时的场景这里把完整方案写出来。缓存击穿的核心问题在于“某个热点key过期瞬间大量并发请求同时打到数据库”。我当时用的互斥锁方案代码长这样public String getProduct(String id) { String cacheKey product: id; String value redis.get(cacheKey); if (value ! null) { return value; } String lockKey lock: cacheKey; String lockValue UUID.randomUUID().toString(); boolean locked redis.set(lockKey, lockValue, NX, EX, 5); if (!locked) { // 拿不到锁说明其他线程正在重建缓存短暂等待后重试 Thread.sleep(50); return getProduct(id); } try { // 双重检查可能其他线程已重建完成 value redis.get(cacheKey); if (value ! null) { return value; } // 查数据库并回填 Product product db.queryById(id); if (product null) { redis.set(cacheKey, , 60); return null; } redis.set(cacheKey, JSON.toJSONString(product), 3600); return JSON.toJSONString(product); } finally { // 使用Lua脚本保证比较和删除的原子性 redis.eval(if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end, Collections.singletonList(lockKey), Collections.singletonList(lockValue)); } }注意几个细节锁的key需要设置过期时间防止持有锁的线程异常退出导致死锁删除锁之前要比较value保证只能由锁的持有者删除重试逻辑要控制好频率和次数不能无限递归。4.4 缓存雪崩的两层防御缓存雪崩是两种情况的统称一种是大量缓存key在同一时间段集中过期另一种是Redis节点整体不可用两种情况都会导致请求直接打到数据库造成瘫痪。针对集中过期问题解决方案前面提到过过期时间加随机偏移。你可以在设置TTL时使用随机值import random ttl 3600 random.randint(0, 300) # 基准1小时加0~5分钟随机值 redis.set(cache_key, value, exttl)针对Redis节点宕机的问题我的做法是分级保护第一级Redis自身要配置主从哨兵主节点宕机自动切换不能单点部署。这也是面试常被问到的“Redis高可用方案”。容量型场景还可以考虑Cluster集群数据分片多活。第二级应用侧做本地进程级缓存兜底比如使用Caffeine缓存最近1分钟的热门数据降低对Redis的依赖。当Redis不可用时本地缓存还能扛住一部分流量。第三级数据库连接池要配置合理限额不能无限放量进来。MyBatis或JDBC连接池压满时后续请求快速失败返回降级提示等待Redis恢复远比把所有请求堆积在数据库前导致数据源耗尽强。我常用的一个降级策略是数据库查询失败时返回旧缓存数据这个数据可能已经过期但业务容忍度内可用。5. 缓存一致性治理从理论到代码5.1 更新缓存还是删除缓存延迟双删策略关于缓存更新的经典题目是更新数据库后更新缓存还是删除缓存大多数场景下“删除缓存”比“更新缓存”更优因为缓存不必承担写操作写操作只发生在读miss回填时这让缓存始终只承载高频读请求也避免了并发写缓存时谁覆盖谁的问题。但“删除缓存”在极端并发下会有一个时间窗口问题。来分析这个时序线程A读缓存未命中。线程A查数据库拿到旧值value1。线程B更新数据库改成value2。线程B删除缓存。线程A把value1写回缓存。最终结果是缓存里是旧值value1而数据库已经是value2且因为缓存没有过期时间或过期时间很长这个旧值会在缓存里存活很久。延迟双删策略就是针对这个问题的经典解法在线程B删除缓存后等待一段时间比如500ms再次删除缓存。延迟的目的是确保线程A的写缓存操作已经完成并“过期”第二次删除就能把线程A写入的旧值清掉。伪代码public void updateProduct(Product product) { db.update(product); redis.del(product: product.getId()); // 延迟一段时间后再次删除 executor.schedule(() - redis.del(product: product.getId()), 500, TimeUnit.MILLISECONDS); }这个方案只是个补偿手段不是银弹延迟时间需要根据实际业务评估太短可能没等旧值写入、太长则窗口期过长。MyBatis缓存与Redis缓存同时存在时还要额外注意分布式应用节点里各自本地缓存的刷新时机。但配合合理的TTL这个方案已经能覆盖99%的业务场景了。5.2 基于Binlog的最终一致性方案对于数据一致性要求比较高的场景延迟双删还不够可靠。我后来在一个交易系统项目里切换到了基于Binlog订阅的最终一致性方案监听MySQL主库的Binlog变更事件通过Canal阿里开源把变更解析出来然后异步删除或更新对应的Redis缓存。这个方案把数据库和缓存的更新解耦大幅降低了应用代码里的缓存清理复杂度。整体架构是MySQL开启Binlog格式设置为ROW模式。Canal伪装成MySQL从库拉取Binlog。解析出更新操作的类型、表名、主键ID。根据表名和ID构造缓存key执行删除操作。如果删除失败放入重试队列由后台任务重试。这套方案的优点是无论应用有多少个实例只要数据库更新发生在主库Binlog都真实记录了变化不会因为代码遗漏而漏删缓存。我在项目里落地时监听几张核心表的INSERT和UPDATE事件数据延迟控制在毫秒级缓存最终一致性和实时性都能接受。5.3 一致性需求分级与架构决策如果每个业务模块都要求缓存数据和数据库强一致那业务就没法写了。我在实际架构里通常把数据按一致性需求分成三个等级强一致不允许任何不一致账户余额、交易状态、库存扣减。这些数据不走缓存直接查库或者使用Redis分布式锁保护写操作且每次写后删除缓存。最终一致允许几秒的不一致用户资料、商品信息、配置项。走缓存采用延迟双删或Binlog订阅更新。弱一致允许分钟级不一致搜索参数、推荐内容、非核心列表页。走缓存设置较短TTL即可过期后自然刷新。把业务按这个维度梳理一遍你会发现自己项目的缓存设计变得非常清晰哪些地方必须做补偿哪些不需要一目了然。5.4 缓存温启动与预热策略还有一点容易被人忽略缓存不是一启动就是满的。系统刚上线或Redis刚重启缓存里冷启动是空的如果不做处理第一批流量会全部打到数据库上很容易把数据库压垮。我的做法是在每个核心业务模块启动时增加一个缓存预热任务def warmup_cache(): hot_products db.query(select id from product order by sales desc limit 1000) pipeline redis.pipeline() for product in hot_products: key fproduct:{product.id} if not redis.exists(key): pipeline.set(key, json.dumps(product_info(product.id)), ex3600) pipeline.execute()预热任务在应用启动后异步执行把过去一段时间最热门的几百上千个数据提前载入缓存这样系统一上线就有一定的缓存命中率。后台还可以加一个定时任务每隔几分钟把新晋热点数据也刷新进去保持缓存命中曲线的平稳。6. Redis高可用、可观测性与集群落地6.1 主从复制与哨兵模式配置要点高可用是缓存的命根子Redis单节点挂了等于缓存全废。我负责的项目从单体Redis演进到主从哨兵解决了单点问题。主从配置的核心指令# 从节点执行 replicaof 192.168.1.10 6379主从复制过程分两步全量同步和增量同步。第一次连接时从节点发送PSYNC命令主节点执行BGSAVE生成RDB快照传给从节点后续的写命令通过复制缓冲区持续同步。这里需要注意如果主从之间的网络中断时间过长复制积压缓冲区被覆盖从节点会退化为全量同步对主节点的IO和带宽压力较大。因此不建议长时间容忍主从延迟。哨兵模式用来监控主节点的健康状态实现自动故障转移。配置Sentinel时我建议至少部署3个节点且为奇数这是因为客户端需要多数派quorum才能确认主节点客观下线并执行故障转移如果只有两个哨兵节点且其中一个宕机剩余节点不足多数派就无法完成自动切换。核心配置sentinel monitor mymaster 192.168.1.10 6379 2 sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 15000down-after-milliseconds是主观下线判定时间2是quorum数量表示至少两个哨兵节点同意才能触发切换。6.2 生产环境下的监控指标体系线上Redis不能装了就用必须盯着数据。我搭建监控系统时主要看这些指标命中率keyspace_hits / (keyspace_hits keyspace_misses)低于80%就要检查是否存在缓存穿透或过期集中问题。内存used_memory和maxmemory比值超过70%需要扩容或优化key大小。连接数connected_clients如果一直打满maxclients说明有连接泄漏或客户端连接池配置不合理。阻塞时间latest_fork_usec、sync_full全量同步频繁说明主从网络有问题。命令延迟通过redis-cli --latency观察P99延迟持续走高要排查慢命令和大key。我习惯把以上指标接入Prometheus Grafana使用redis_exporter采集设置告警规则命中率低于阈值、内存超过80%、连接数超过80%、主从复制断连超过5分钟都触发告警。这套体系帮我提前发现过几次隐患避免了线上故障。6.3 Cluster集群的数据分片逻辑单节点内存有上限一般128GB够用但成本不低而且单节点的写并发也有瓶颈。我后来在数据量上去后迁移到了Redis Cluster。Cluster采用槽slot分配机制总共16384个槽通过CRC16(key) % 16384计算key归属哪个节点。节点之间通过Gossip协议维护集群状态客户端使用MOVED重定向指令定位节点。搭建Cluster时注意几个点所有节点都需要开启cluster-enabled yes。至少3个主节点才能组成可用集群每个主节点建议配一个从节点保证高可用。应用端的客户端SDK需要支持Cluster模式比如Jedis、Lettuce、Redisson都有对应实现。我看到不少人在迁移时还在用单节点SDK导致只能访问一个节点的数据看起来是集群实际变成单节点在用白白浪费了扩展能力。不支持多key操作跨节点比如MGET不同key分布在不同节点会报错。解决方案是使用Hash Tag把相关key强制哈希到同一个槽位比如user:{9527}:profile和user:{9527}:orders冒号中的内容会被用来计算哈希这个特性可以在官方文档中找到支持列表。6.4 缓存治理平台与可视化工具的问题我开始做系统性的缓存治理后给自己团队的Redis运维定制了一套辅助平台其实在一开始用现成工具就行管理所有key和TTL规则、查看缓存命中情况、执行批量清理、设置黑白名单、发布配置公告。使用现成的可视化客户端时踩过不少坑这里把经验分享出来Redis Desktop Manager简称RDM新版叫Another Redis Desktop Manager的坑老版本RDM在大key扫描时有大量的内存占用容易假死。如果有几十万个key不要用RDM的KEYS *查询。直接改用SCAN命令配合正则匹配或者用命令行工具redis-cli --scan --pattern product:*。RDM会大量调用INFO、DBSIZE和一些数据库统计命令尤其是在连接建立时自动执行如果Redis开启了慢日志监控会发现大量来自监控客户端的慢查询记录。要避免这类噪声可以在Redis启动参数里配置慢日志阈值把来自工具的读操作排除到告警范围之外。新版有个功能支持按正则表达式批量删除但需要在操作前备份确认否则删错key没法恢复。我的建议是日常调试用可视化客户端没问题但线上变更和批量操作尽量用命令行执行并做好变更记录和确认流程。7. 实战排障一个缓存穿透引发的事故复盘7.1 事故现象与定位过程有一次线上报障某个活动页接口的平均响应时间从10ms飙升到3秒错误率持续上升当时我们第一时间怀疑是数据库扛不住了。查看数据库监控发现MySQL的QPS是平时的5倍慢查询也出现了很多仔细看了慢查询日志全是查询同一个商品ID的记录——而商品ID在数据库里压根不存在。通过日志平台翻请求参数发现一个用户反复请求某个特定ID且这个ID并不是有效商品。这个行为模式极像恶意遍历或内部工具的错误调用。进一步确认缓存监控keyspace_misses数值飙升keyspace_hits几乎为零。定位为典型的缓存穿透问题。7.2 修复过程与代码改造临时修复确认数据库确实没有这个ID后把这次事故定义为穿透攻击或异常调用。当时我先人工构造了对应ID的空值缓存五分钟内接口响应恢复。这里有个经验空值缓存的历史数据里填的是空字符串而不是null否则容易在反序列化时报错格式统一用最省事。长期修复第一步全量排查数据库核心表把“不存在ID”的查询加上统一拦截在应用入口增加一个Cache服务方法如果查库结果为空统一写空值缓存并带最多5分钟的TTL防止集中重复查库。第二步全量预热核心表的合法ID到布隆过滤器我用脚本从数据库分批扫描主键逐批BF.ADD同时维护一个定时任务定期同步新增ID。第三步接入限流和告警单IP单位时间内对同一个不存在ID的请求次数超过阈值触发告警。部署完成后再模拟之前的请求数据库监控平稳缓存miss没有异常上升问题彻底解决。这次事故的教训是缓存层不能只做“能存能取”必须提前把异常场景想全。7.3 缓存雪崩模拟与应急预案演练还有一次我们在压测环境模拟了缓存雪崩把所有key的过期时间统一设置为同一时刻压测QPS拉到峰值数据库的CPU使用率直接打满部分查询全部超时。现场验证了我们应急预案里的降级开关是有效的。降级策略分几层第一层配置中心开关“全部走缓存过期不查库”确保缓存失效时接口返回旧数据而不是穿透查库。第二层白名单控制仅仅让部分极大流量路径走降级正常情况下完全关闭降级避免性能损失压测中确认开关生效后我们记录了关闭降级的操作步骤以防人为遗忘。第三层数据库连接池满时快速失败通过一个独立的线程池来处理缓存回填任务防止正常请求被打爆。经过演练后我们在实际生产中能够做到的故障切换时间从原来的十几分钟压缩到3分钟以内。建议每个团队都对核心接口做一次类似的“缓存故障演练”过程很惊险但收益巨大。8. 高频面试题与底层原理补充虽说是项目总结但这些知识点和面试题高度重合我顺手把最常被问的几个底层原理讲透都是我在准备技术分享时梳理过的。8.1 Redis单线程模型为什么能扛高并发Redis的核心处理逻辑是单线程的所有命令的执行是按顺序排队进行不存在并发竞争和数据竞争的问题。那它凭什么能扛高并发答案是IO多路复用。Redis使用epoll机制把所有的socket连接都交给内核监听内核发现有连接可读或可写时通知Redis处理Redis在事件循环里逐个处理。这个机制的本质是用极小的线程切换开销处理海量连接而不是一个连接一个线程。这也解释了为什么Redis的单条命令要求足够快平均微秒级别。如果某条命令执行时间较长比如涉及KEYS *全量扫描或者HGETALL超大哈希其他所有命令都会被阻塞这就是为什么生产环境严禁使用KEYS命令。补充一个小细节从Redis 6.0开始网络IO模块改成了多线程处理但命令执行仍然是单线程。这个优化的目的是把socket读写和协议解析分摊到多线程核心命令处理依旧串行所以原子性还是被保住了这反而让许多依赖“单线程原子性”的用法在6.0版本后依然有效。8.2 Redis持久化RDB与AOF的选择策略缓存场景通常不太依赖持久化但Redis本身提供这个能力有些半缓存半存储的使用方式会用到。RDB按快照方式定时把内存的全量或增量数据序列化到磁盘文件恢复速度快适合做备份和灾难恢复。缺点是最后一次快照之后的数据可能丢失且生成快照时fork子进程如果数据量大、内存富余不足fork可能阻塞主进程。AOF追加写日志每条写命令都会记录到AOF文件安全性更高。AOF重写机制可以压缩文件大小但它的恢复速度比RDB慢而且文件通常更大。将AOF刷盘策略配置为everysec时最多丢失一秒数据这是一个比较均衡的折中方案。我的建议是纯缓存场景可以不用持久化或者仅开启RDB用于快速恢复半存储场景用AOF 每秒刷盘数据极其重要时用RDB AOF双开。双开会增加写入开销但在低写并发场景下影响很小却能换来很强的数据安全保障。8.3 Redis分布式锁与Redisson看门狗机制分布式锁是缓存场景的延伸应用当时在秒杀系统里写的锁方案后来升级成了Redisson。核心原理在前面实现里已经演示了SET key value NX EX保证原子性地在没有key时才设置并且自动过期。但有个隐患如果持有锁的线程执行时间超过锁的过期时间锁会自动释放其他线程就能拿到锁导致临界区被并发进入。Redisson的看门狗机制解决这个问题Redisson给锁续期的后台任务每隔一定时间三分之一的锁过期时间会检查当前锁是否还被持有如果持有则延长过期时间直到业务线程主动释放锁或判断锁已被抢占。需要注意看门狗只在获取锁时没有指定leaseTime时才会启动。如果手动指定了leaseTimeRedisson不会自动续期过期后锁照常释放。所以如果你的业务执行时间可能非常长要么不指定leaseTime委托看门狗续期要么自己实现续期逻辑千万别把过期时间设死。8.4 缓存分级Caffeine与Redis组合使用最后补充一下本地缓存和Redis的组合方案这是我在一个读多写少的用户信息接口里做的优化第一级Caffeine本地缓存配置最大容量和短过期时间例如容量1万条、过期30秒直接挡掉绝大部分读取请求零网络开销。第二级Redis分布式缓存过期时间5到10分钟。本地缓存未命中时再查Redis。第三级MySQL数据库兜底查询成功后回填Redis和本地缓存。这个分级的命中率能到99%左右极大地释放了Redis和数据库的压力。但要注意一致性本地缓存因为过期时间短数据延迟在几十秒内可接受如果有更新接口务必主动清理对应key在本地的缓存和Redis缓存可以用Spring Cache的CacheEvict注解或自己实现一个双删逻辑。9. 常见问题速查与避坑清单9.1 Redis缓存高频问题排查表我在维护和评审代码时整理了以下问题排查清单直接贴在这里方便查阅问题现象可能原因排查命令/方法解决方案缓存命中率极低缓存key设计不合理过期时间太短INFO stats查看keyspace_hits/misses调整key粒度、加长TTL、做预热Redis内存暴涨大key、无TTL的key、value过大redis-cli --bigkeys、MEMORY USAGE拆分大key、统一TTL、设置maxmemory-policy接口响应偶尔卡顿存在慢命令或大key阻塞SLOWLOG GET 10禁用KEYS等命令拆分大集合缓存和数据库不一致更新顺序不对、漏删缓存查日志、翻转DB与Redis的更新时间延迟双删、Binlog订阅所有请求打到数据库Redis宕机/雪崩/穿透查看Redis连接、慢查询、QPS曲线高可用集群、降级开关、空值缓存、布隆过滤器连接数打满客户端连接泄漏、连接池配置过小INFO clients、查看堆栈配置连接池上限、检查客户端关闭逻辑这张表是我内部周会分享的底稿几乎每一行都有对应的线上事故案例。建议你把它复制到自己团队的Wiki里遇到问题先查表不要每次都从零开始排查。9.2 实战避坑清单五个最常见的误操作第一个坑线上执行FLUSHALL。这是毁灭性操作Redis缓存全部清空所有请求瞬间打到数据库。我用这个操作做过一次演练效果非常吓人从此再也不敢直接在生产执行。如果确实要清理用SCAN配合DEL分批删并且提前评估流量冲击。第二个坑用KEYS *做模糊查询。这个命令会扫描全库并阻塞Redis几百万key的场景下服务基本就挂了。正确操作是SCAN cursor MATCH pattern COUNT count分段遍历。我见过有人写定时任务用KEYS user:*来做批量失效直接把Redis阻塞了好几秒。第三个坑缓存key没有统一命名规范。项目里如果有的用product:9527、有的用Product_9527、有的用productId:9527后续做预算、排查、禁用都极其痛苦。我在项目起步时定了几条规矩统一用小写字母加冒号分隔语义模块和业务ID如module:business:key不同业务线加前缀区分所有key必须有明确的TTL设置除了极少数永不过期的元数据。第四个坑缓存工具类封装过度复杂。我见过有人封装了非常强的缓存注解框架支持过期时间、条件缓存、异步刷新看起来很酷但调试问题时无从下手因为缓存行为散落在注解和底层框架里。建议老老实实用简单的CacheService工具类把逻辑显式写在业务代码里出了问题一手就能抓到。第五个坑忽略客户端连接池的合理配置。Jedis/Lettuce如果不配置连接池每个请求都新建连接再关闭Redis的连接数会异常升高TCP握手带来的CPU开销也很可观。我的建议是使用Lettuce的共享连接Spring Boot默认或者给Jedis配置池化核心参数maxTotal、maxIdle、minIdle、maxWaitMillis按预估QPS和平均响应时间计算并进行一次压测验证。9.3 缓存Redis运维小工具推荐redis-cli命令行工具最基础、最可靠。包括--stat实时监控、--bigkeys扫描大key、--latency检测延迟、--scan安全遍历。RedisInsight官方可视化工具功能比RDM更全支持内存分析、Slowlog查看、命令行交互界面也现代。redis_exporter Prometheus Grafana监控告警三件套适合生产环境。RDB tools一个基于Python的RDB文件解析工具当Redis只有RDB文件且想要离线分析内容、统计key数量时非常有用。写在最后的实操心得从接触Redis到现在我的体会是缓存不是把数据往Redis里一丢就完事它是一个需要设计、治理、运维的系统工程。很多人把缓存用成了“数据库的挡箭牌”出了问题只会加内存、加机器实际上很多问题的根源都在代码和架构设计层面。我到现在还记得第一次在线上遇到缓存穿透时的慌乱后来每次在代码评审里看到有人要访问不存在的数据却没有任何防护我都会不自觉地去翻布隆过滤器是否已经接好。踩过的坑多到我已经养成了条件反射但也正因为这些坑让我对Redis的每个特性都理解得比看十篇文档都深刻。如果让我给你的项目一个最直接的建议先把缓存监控做起来命中率、内存、连接数、慢命令这四个指标盯住很多问题还没到影响业务你就能提前感知到。缓存治理这条路监控和数据才是第一生产力。后面我打算再把Redis Cluster的扩缩容和性能调优单独整理一篇如果你也在实战中遇过类似问题欢迎在评论区聊聊你的处理方式。 Redis缓存实战全解析：从穿透治理到高可用架构
我之前在团队里带队做高并发项目的时候几乎所有接口性能瓶颈最后都卡在数据库上。那时候每天看着监控面板上陡峭的QPS曲线和时不时飘红的慢查询真的会睡不着觉。后来我们把Redis缓存系统地用起来从最简单的热点数据缓存到分布式锁、缓存穿透防护、一致性治理一步步踩坑填坑才算真正把Redis用明白。这篇文章就是一次个人项目经验的完整复盘把我这几年来在真实业务场景里用Redis做缓存的所有心得、代码、配置、排障过程都整理出来。无论你是刚接触Redis的新手还是已经被线上缓存问题折腾过几次的开发这篇文章都值得你静下心来读完一遍因为里面写的每一步都是有代价换来的。1. Redis为什么是最常见的缓存选型1.1 本地缓存与集中式缓存的取舍很多项目一开始做性能优化最容易想到的就是在应用内存里搞一个ConcurrentHashMap或者Caffeine当缓存。这个方案在单机场景下确实香——没有网络开销读取速度是纳秒级别的。但一旦你的服务部署了多个实例本地缓存就变成各玩各的A实例更新了缓存B实例还在用旧数据。我见过一个真实案例用户支付成功后状态一直不更新因为请求被负载均衡分发到了多个实例只有其中一个实例的本地缓存失效了。排查了半天最后发现是本地缓存没做分布式失效。这就是集中式缓存存在的意义。Redis作为集中式缓存所有实例共享同一份缓存数据天然避免了多实例数据不一致的问题。而且它基于内存存储单线程IO多路复用单节点QPS可以轻松突破10万这个性能对于绝大多数业务场景完全够用。1.2 Redis与Memcached的差异分析当年选型的时候我们也在Redis和Memcached之间纠结过。Memcached出道更早纯KV缓存内存管理非常高效多线程模型在大流量下表现也很好。但有几个硬伤不支持持久化重启全丢用于缓存还能接受想干点别的就不行了。数据结构单一只能存字符串业务上想存一个用户对象还得自己序列化成JSON做字段更新更是麻烦。不支持主从复制和集群的自动故障转移运维成本高。Redis能打的地方恰恰在于它有五种其实还有BitMap、HyperLogLog、Geo等丰富的数据结构支持RDB和AOF两种持久化方式原生支持主从复制、哨兵模式和Cluster集群模式。所以后来Redis成了社区事实上的标准很多中间件原生的缓存组件也都是基于Redis做的适配。1.3 Redis缓存的适用场景边界Redis缓存不是万能的我在实际项目里总结了几条判断标准读多写少的数据且读的频率远高于更新的频率才适合放缓存。数据不是唯一的准确来源允许在极端情况下短暂不一致比如几秒内。单个数据条目的访问次数足够高摊薄缓存维护成本。数据量可控不能大到内存放不下的程度除非上集群。反过来如果是强一致的金融类数据、写频繁且读写比例接近的数据、或者一次性访问后再也不碰的数据都不适合用缓存。这条边界要是不守好后面出现的问题会非常棘手。2. 核心数据类型与缓存场景的精准对应2.1 String类型缓存的应用String是Redis里最基础也最常用的类型底层是SDS动态字符串支持二进制安全。在缓存场景里它的典型用法包括用户会话Token存储SET token:9527 eyJhbGciOi... EX 7200配合过期时间实现会话自动失效。对象序列化存储把用户信息、商品详情、配置项序列化成JSON字符串存入读取时反序列化即可。计数器场景利用INCR、INCRBY做点赞数、访问数统计因为Redis单线程模型保证原子性并发下不会出错。分布式锁SET lock:order:9527 uuid NX EX 3这个后面详细讲。String类型需要注意的一个点单个value值过大会造成网络传输和内存分配的浪费我一般建议单条value控制在10KB以内超过这个值就要考虑拆分或者换用Hash结构。2.2 Hash类型在对象缓存中的优势这是我个人最喜欢的缓存数据结构。它存储的是一个对象字段的映射类似于key - field - value的三层结构。对比String序列化整个对象Hash的优点是可以只获取或更新对象的某个字段不用像String那样整存整取。修改某几个字段时不用反序列化整个对象再序列化回去省CPU省流量。更贴近业务实体的结构代码可读性强。举个例子缓存用户基础资料HSET user:9527 name 张三 age 24 city 杭州 HGET user:9527 name HINCRBY user:9527 age 1当用户只修改年龄时这个操作只更新一个字段其他字段不会动。如果是String存储整个JSON修改年龄需要把整个用户对象读出来、反序列化、改字段、再序列化、写回去性能和代码复杂度都差一些。2.3 List、Set、ZSet在特定场景的妙用这些结构我在实际业务里也踩出了经验List做消息队列、时间线列表。比如微信公众号的粉丝Timeline每个用户的关注列表用LPUSH插入新消息IDLRANGE分页读取LTRIM裁剪长度防止无限增长。注意List做队列时消费端用BRPOP阻塞读取可以实现可靠的消息传递比轮询效率高一个量级。Set做去重统计、标签系统、好友关系。比如SADD user:9527:tags 技术 生活求两个用户的共同好友用SINTER统计UV去重用SCARD。Set天然去重的特性让它在缓存场景自带防重能力。ZSet做排行榜、热榜、延时队列。分数作为排序依据比如ZADD rank:general 1000 user:9527排行榜展示用ZREVRANGE取前N名更新分数用ZINCRBY。延时队列的思路是把任务放入ZSetscore是执行时间戳轮询时用ZRANGEBYSCORE取出到期的任务执行。2.4 Bitmap与HyperLogLog的极简内存方案这两个结构在某些场景下能省掉90%以上的内存属于用好了会“上瘾”的那种。Bitmap做用户签到、在线状态、布隆过滤器。比如记录用户一年365天的签到SETBIT sign:9527 200 1查询某天是否签到GETBIT sign:9527 200统计全年签到天数用BITCOUNT sign:9527。一个用户一年只占365bit也就是45字节10万用户签到数据不到5MB这如果放数据库里是几百万行记录。HyperLogLog做海量UV统计误差率在0.81%左右。比如PFADD page:index:20240501 user:9527统计当天UV用PFCOUNT。我在做埋点访问统计时用的就是它每天几千万的访问记录最后只用了12KB内存就完成了UV去重统计这个数据量如果用Set存储至少得几百MB。3. 缓存读写架构与淘汰机制设计3.1 Cache Aside读写流程详解这是目前业界应用最广泛的缓存模式也是我项目里的基础架构。读请求流程应用先查询Redis缓存。如果命中直接返回数据。如果未命中查询MySQL数据库。数据库查询成功后将数据写入Redis设置过期时间。返回数据给前端。写请求流程先更新数据库。数据库更新成功后删除Redis中对应的缓存。下次读请求未命中缓存重新从数据库加载并回填。这个流程里的关键点是“先更新库再删缓存”而不是“先删缓存再更新库”。为什么因为如果先删缓存再更新库在并发场景下会出现一个空窗期另一个请求读到旧数据回填到缓存而数据库更新还没完成缓存就成了旧值缓存的过期时间也被拉长了。后面我会在第6章详细展开这个顺序问题的并发分析。3.2 TTL过期策略与惰性删除Redis的过期删除采用两种方式结合惰性删除和定期删除。惰性删除当客户端访问一个key时Redis会检查这个key是否设置了过期时间且已过期如果已过期则删除并返回nil。这种策略的缺点是过期的key如果一直不被访问就会一直占着内存。定期删除Redis每隔一段时间默认100ms随机抽取一批设置了过期时间的key进行检查发现过期就删除。因为不可能全表扫描所以用的是“随机抽取检查”的方式。两者的组合确保了大部分过期key能及时被清理内存不会被无限占用同时把性能损耗控制在了很小的范围内。我建议在实际项目中给缓存设置过期时间时一定要加上随机偏移防止大量key在同一时刻集中过期导致缓存雪崩。比如基准过期时间是1小时实际设置时可以加一个0到5分钟的随机值。3.3 LRU/LFU淘汰策略的选型思考当Redis内存达到配置上限maxmemory时需要通过淘汰策略来腾出空间。我见过太多项目默认不配置淘汰策略导致Redis内存打满后直接拒绝服务引发线上故障。这个坑一定要提前躲开。Redis提供的淘汰策略里最常用的有allkeys-lru从所有key中按最近最少使用原则淘汰。volatile-lru从设置了过期时间的key中按LRU淘汰。allkeys-lfu从所有key中按访问频率最少原则淘汰适用于存在热点和非热点差异明显的场景。noeviction默认策略内存满了不淘汰任何key写请求直接报错。我个人的经验是纯缓存场景用allkeys-lru就够了如果某些key访问频率极高且是核心热数据就用allkeys-lfu因为LRU在“批量偶发扫描”的场景下很容易让热key被淘汰LFU对访问频率的统计更平滑。配置方式maxmemory 4096mb maxmemory-policy allkeys-lru maxmemory-samples 10maxmemory-samples是LRU近似的采样数量默认5加大到10可以提升淘汰精度但会略微增加CPU消耗实践中这个值是性能和准确度之间不错的平衡点。3.4 热点Key与过期时间的联动设计热点Key的缓存失效处理要特别小心。如果某个key访问量极高当它过期的一瞬间会有大量请求同时打到数据库这就是缓存击穿。我在项目中用过两种方案第一种互斥锁方案当缓存未命中时不是所有请求都去查库而是先获取一个分布式锁例如SET lock:hot:9527 uuid NX EX 5拿到锁的请求查库并回填缓存其他请求等待短暂时间后重新查缓存。这种方案可以保证数据库不会被打爆但会让部分请求的响应时间变长。第二种逻辑过期方案缓存里存的数据带上一个逻辑过期时间字段比如“缓存真实有效期是30秒但Redis不设置过期时间业务自己判断逻辑是否过期”。当发现逻辑过期时立即返回旧数据同时启动一个异步线程去数据库刷新缓存。这种方案的优点是响应快不用等待锁缺点是实现复杂度高且极端情况下数据不够新。我最终采用的是“互斥锁热点探测”的组合热点key不设置物理过期时间而是通过一个独立的后台任务周期性刷新缓存这样既能保证数据不过期又能避免热点key失效时的击穿问题。冷门key还是用标准TTL方案简单有效。4. 缓存问题治理穿透、击穿、雪崩与布隆过滤器4.1 缓存穿透的成因与空值缓存方案缓存穿透是指查询一个数据库中不存在的数据因为这个数据本身不存在所以缓存里也不可能命中每次请求都会直接打到数据库。如果攻击者恶意构造大量不存在的ID发起请求数据库压力会瞬间飙升。我在实际项目中遇到过一次接口对外暴露了商品ID有人写脚本遍历ID范围请求大部分ID在数据库里都不存在每次请求都穿透到MySQL单库QPS直接被打到上千接口大量超时。解决方案有两个思路第一缓存空值。对于从数据库查询不存在的结果也往Redis里写一个空值缓存过期时间可以设置得短一些比如60秒这样后续请求在缓存窗口期内都会被拦截。伪代码如下data redis.get(product:9527) if data is None: product db.query(select * from product where id9527) if product is None: redis.set(product:9527, , ex60) return None redis.set(product:9527, json.dumps(product), ex3600) return product这里有个坑需要注意——如果用SET去覆盖已经存在的空值缓存会导致每次“不存在”的查询都延长空值缓存的生命周期因此更推荐用SET NX配合过期时间确保空值缓存一旦存在就只依赖于第一次写入时的过期时间。第二布隆过滤器。在缓存前面再加一层布隆过滤器把数据库里可能存在的ID提前加载到过滤器里。请求到达时先判断ID是否存在于过滤器中如果不在直接返回不存在根本不会进数据库查询。4.2 布隆过滤器的原理与实现细节布隆过滤器本质上是一个很长的二进制位数组和多个哈希函数。插入一个元素时用多个哈希函数计算位置把对应位全部置为1。查询一个元素是否存在时同样计算多个哈希位置只要发现任何一位是0就说明这个元素一定不存在如果全都是1则说明可能存在因为有哈希碰撞的存在。这个“存在可能误判不存在一定精准”的特性应用到缓存穿透防护里非常顺手把数据库中所有合法ID加载进布隆过滤器然后处理请求时先查过滤器不存在的直接拦掉。我当时用Redis内置的布隆过滤器模块RedisBloom实现BF.RESERVE product_filter 0.0001 100000000 BF.ADD product_filter 9527 BF.MEXISTS product_filter 9527 9528参数说明0.0001是期望的误判率100000000是预估的元素数量误判率越低、元素越多位数组占用空间就越大。自己估算一下一亿量级的元素误判率万分之一大概需要240MB左右的内存对于导致数据库崩溃的请求量来说这点内存完全值得。4.3 缓存击穿与互斥锁方案实战前面简单提到了热点key失效时的场景这里把完整方案写出来。缓存击穿的核心问题在于“某个热点key过期瞬间大量并发请求同时打到数据库”。我当时用的互斥锁方案代码长这样public String getProduct(String id) { String cacheKey product: id; String value redis.get(cacheKey); if (value ! null) { return value; } String lockKey lock: cacheKey; String lockValue UUID.randomUUID().toString(); boolean locked redis.set(lockKey, lockValue, NX, EX, 5); if (!locked) { // 拿不到锁说明其他线程正在重建缓存短暂等待后重试 Thread.sleep(50); return getProduct(id); } try { // 双重检查可能其他线程已重建完成 value redis.get(cacheKey); if (value ! null) { return value; } // 查数据库并回填 Product product db.queryById(id); if (product null) { redis.set(cacheKey, , 60); return null; } redis.set(cacheKey, JSON.toJSONString(product), 3600); return JSON.toJSONString(product); } finally { // 使用Lua脚本保证比较和删除的原子性 redis.eval(if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end, Collections.singletonList(lockKey), Collections.singletonList(lockValue)); } }注意几个细节锁的key需要设置过期时间防止持有锁的线程异常退出导致死锁删除锁之前要比较value保证只能由锁的持有者删除重试逻辑要控制好频率和次数不能无限递归。4.4 缓存雪崩的两层防御缓存雪崩是两种情况的统称一种是大量缓存key在同一时间段集中过期另一种是Redis节点整体不可用两种情况都会导致请求直接打到数据库造成瘫痪。针对集中过期问题解决方案前面提到过过期时间加随机偏移。你可以在设置TTL时使用随机值import random ttl 3600 random.randint(0, 300) # 基准1小时加0~5分钟随机值 redis.set(cache_key, value, exttl)针对Redis节点宕机的问题我的做法是分级保护第一级Redis自身要配置主从哨兵主节点宕机自动切换不能单点部署。这也是面试常被问到的“Redis高可用方案”。容量型场景还可以考虑Cluster集群数据分片多活。第二级应用侧做本地进程级缓存兜底比如使用Caffeine缓存最近1分钟的热门数据降低对Redis的依赖。当Redis不可用时本地缓存还能扛住一部分流量。第三级数据库连接池要配置合理限额不能无限放量进来。MyBatis或JDBC连接池压满时后续请求快速失败返回降级提示等待Redis恢复远比把所有请求堆积在数据库前导致数据源耗尽强。我常用的一个降级策略是数据库查询失败时返回旧缓存数据这个数据可能已经过期但业务容忍度内可用。5. 缓存一致性治理从理论到代码5.1 更新缓存还是删除缓存延迟双删策略关于缓存更新的经典题目是更新数据库后更新缓存还是删除缓存大多数场景下“删除缓存”比“更新缓存”更优因为缓存不必承担写操作写操作只发生在读miss回填时这让缓存始终只承载高频读请求也避免了并发写缓存时谁覆盖谁的问题。但“删除缓存”在极端并发下会有一个时间窗口问题。来分析这个时序线程A读缓存未命中。线程A查数据库拿到旧值value1。线程B更新数据库改成value2。线程B删除缓存。线程A把value1写回缓存。最终结果是缓存里是旧值value1而数据库已经是value2且因为缓存没有过期时间或过期时间很长这个旧值会在缓存里存活很久。延迟双删策略就是针对这个问题的经典解法在线程B删除缓存后等待一段时间比如500ms再次删除缓存。延迟的目的是确保线程A的写缓存操作已经完成并“过期”第二次删除就能把线程A写入的旧值清掉。伪代码public void updateProduct(Product product) { db.update(product); redis.del(product: product.getId()); // 延迟一段时间后再次删除 executor.schedule(() - redis.del(product: product.getId()), 500, TimeUnit.MILLISECONDS); }这个方案只是个补偿手段不是银弹延迟时间需要根据实际业务评估太短可能没等旧值写入、太长则窗口期过长。MyBatis缓存与Redis缓存同时存在时还要额外注意分布式应用节点里各自本地缓存的刷新时机。但配合合理的TTL这个方案已经能覆盖99%的业务场景了。5.2 基于Binlog的最终一致性方案对于数据一致性要求比较高的场景延迟双删还不够可靠。我后来在一个交易系统项目里切换到了基于Binlog订阅的最终一致性方案监听MySQL主库的Binlog变更事件通过Canal阿里开源把变更解析出来然后异步删除或更新对应的Redis缓存。这个方案把数据库和缓存的更新解耦大幅降低了应用代码里的缓存清理复杂度。整体架构是MySQL开启Binlog格式设置为ROW模式。Canal伪装成MySQL从库拉取Binlog。解析出更新操作的类型、表名、主键ID。根据表名和ID构造缓存key执行删除操作。如果删除失败放入重试队列由后台任务重试。这套方案的优点是无论应用有多少个实例只要数据库更新发生在主库Binlog都真实记录了变化不会因为代码遗漏而漏删缓存。我在项目里落地时监听几张核心表的INSERT和UPDATE事件数据延迟控制在毫秒级缓存最终一致性和实时性都能接受。5.3 一致性需求分级与架构决策如果每个业务模块都要求缓存数据和数据库强一致那业务就没法写了。我在实际架构里通常把数据按一致性需求分成三个等级强一致不允许任何不一致账户余额、交易状态、库存扣减。这些数据不走缓存直接查库或者使用Redis分布式锁保护写操作且每次写后删除缓存。最终一致允许几秒的不一致用户资料、商品信息、配置项。走缓存采用延迟双删或Binlog订阅更新。弱一致允许分钟级不一致搜索参数、推荐内容、非核心列表页。走缓存设置较短TTL即可过期后自然刷新。把业务按这个维度梳理一遍你会发现自己项目的缓存设计变得非常清晰哪些地方必须做补偿哪些不需要一目了然。5.4 缓存温启动与预热策略还有一点容易被人忽略缓存不是一启动就是满的。系统刚上线或Redis刚重启缓存里冷启动是空的如果不做处理第一批流量会全部打到数据库上很容易把数据库压垮。我的做法是在每个核心业务模块启动时增加一个缓存预热任务def warmup_cache(): hot_products db.query(select id from product order by sales desc limit 1000) pipeline redis.pipeline() for product in hot_products: key fproduct:{product.id} if not redis.exists(key): pipeline.set(key, json.dumps(product_info(product.id)), ex3600) pipeline.execute()预热任务在应用启动后异步执行把过去一段时间最热门的几百上千个数据提前载入缓存这样系统一上线就有一定的缓存命中率。后台还可以加一个定时任务每隔几分钟把新晋热点数据也刷新进去保持缓存命中曲线的平稳。6. Redis高可用、可观测性与集群落地6.1 主从复制与哨兵模式配置要点高可用是缓存的命根子Redis单节点挂了等于缓存全废。我负责的项目从单体Redis演进到主从哨兵解决了单点问题。主从配置的核心指令# 从节点执行 replicaof 192.168.1.10 6379主从复制过程分两步全量同步和增量同步。第一次连接时从节点发送PSYNC命令主节点执行BGSAVE生成RDB快照传给从节点后续的写命令通过复制缓冲区持续同步。这里需要注意如果主从之间的网络中断时间过长复制积压缓冲区被覆盖从节点会退化为全量同步对主节点的IO和带宽压力较大。因此不建议长时间容忍主从延迟。哨兵模式用来监控主节点的健康状态实现自动故障转移。配置Sentinel时我建议至少部署3个节点且为奇数这是因为客户端需要多数派quorum才能确认主节点客观下线并执行故障转移如果只有两个哨兵节点且其中一个宕机剩余节点不足多数派就无法完成自动切换。核心配置sentinel monitor mymaster 192.168.1.10 6379 2 sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 15000down-after-milliseconds是主观下线判定时间2是quorum数量表示至少两个哨兵节点同意才能触发切换。6.2 生产环境下的监控指标体系线上Redis不能装了就用必须盯着数据。我搭建监控系统时主要看这些指标命中率keyspace_hits / (keyspace_hits keyspace_misses)低于80%就要检查是否存在缓存穿透或过期集中问题。内存used_memory和maxmemory比值超过70%需要扩容或优化key大小。连接数connected_clients如果一直打满maxclients说明有连接泄漏或客户端连接池配置不合理。阻塞时间latest_fork_usec、sync_full全量同步频繁说明主从网络有问题。命令延迟通过redis-cli --latency观察P99延迟持续走高要排查慢命令和大key。我习惯把以上指标接入Prometheus Grafana使用redis_exporter采集设置告警规则命中率低于阈值、内存超过80%、连接数超过80%、主从复制断连超过5分钟都触发告警。这套体系帮我提前发现过几次隐患避免了线上故障。6.3 Cluster集群的数据分片逻辑单节点内存有上限一般128GB够用但成本不低而且单节点的写并发也有瓶颈。我后来在数据量上去后迁移到了Redis Cluster。Cluster采用槽slot分配机制总共16384个槽通过CRC16(key) % 16384计算key归属哪个节点。节点之间通过Gossip协议维护集群状态客户端使用MOVED重定向指令定位节点。搭建Cluster时注意几个点所有节点都需要开启cluster-enabled yes。至少3个主节点才能组成可用集群每个主节点建议配一个从节点保证高可用。应用端的客户端SDK需要支持Cluster模式比如Jedis、Lettuce、Redisson都有对应实现。我看到不少人在迁移时还在用单节点SDK导致只能访问一个节点的数据看起来是集群实际变成单节点在用白白浪费了扩展能力。不支持多key操作跨节点比如MGET不同key分布在不同节点会报错。解决方案是使用Hash Tag把相关key强制哈希到同一个槽位比如user:{9527}:profile和user:{9527}:orders冒号中的内容会被用来计算哈希这个特性可以在官方文档中找到支持列表。6.4 缓存治理平台与可视化工具的问题我开始做系统性的缓存治理后给自己团队的Redis运维定制了一套辅助平台其实在一开始用现成工具就行管理所有key和TTL规则、查看缓存命中情况、执行批量清理、设置黑白名单、发布配置公告。使用现成的可视化客户端时踩过不少坑这里把经验分享出来Redis Desktop Manager简称RDM新版叫Another Redis Desktop Manager的坑老版本RDM在大key扫描时有大量的内存占用容易假死。如果有几十万个key不要用RDM的KEYS *查询。直接改用SCAN命令配合正则匹配或者用命令行工具redis-cli --scan --pattern product:*。RDM会大量调用INFO、DBSIZE和一些数据库统计命令尤其是在连接建立时自动执行如果Redis开启了慢日志监控会发现大量来自监控客户端的慢查询记录。要避免这类噪声可以在Redis启动参数里配置慢日志阈值把来自工具的读操作排除到告警范围之外。新版有个功能支持按正则表达式批量删除但需要在操作前备份确认否则删错key没法恢复。我的建议是日常调试用可视化客户端没问题但线上变更和批量操作尽量用命令行执行并做好变更记录和确认流程。7. 实战排障一个缓存穿透引发的事故复盘7.1 事故现象与定位过程有一次线上报障某个活动页接口的平均响应时间从10ms飙升到3秒错误率持续上升当时我们第一时间怀疑是数据库扛不住了。查看数据库监控发现MySQL的QPS是平时的5倍慢查询也出现了很多仔细看了慢查询日志全是查询同一个商品ID的记录——而商品ID在数据库里压根不存在。通过日志平台翻请求参数发现一个用户反复请求某个特定ID且这个ID并不是有效商品。这个行为模式极像恶意遍历或内部工具的错误调用。进一步确认缓存监控keyspace_misses数值飙升keyspace_hits几乎为零。定位为典型的缓存穿透问题。7.2 修复过程与代码改造临时修复确认数据库确实没有这个ID后把这次事故定义为穿透攻击或异常调用。当时我先人工构造了对应ID的空值缓存五分钟内接口响应恢复。这里有个经验空值缓存的历史数据里填的是空字符串而不是null否则容易在反序列化时报错格式统一用最省事。长期修复第一步全量排查数据库核心表把“不存在ID”的查询加上统一拦截在应用入口增加一个Cache服务方法如果查库结果为空统一写空值缓存并带最多5分钟的TTL防止集中重复查库。第二步全量预热核心表的合法ID到布隆过滤器我用脚本从数据库分批扫描主键逐批BF.ADD同时维护一个定时任务定期同步新增ID。第三步接入限流和告警单IP单位时间内对同一个不存在ID的请求次数超过阈值触发告警。部署完成后再模拟之前的请求数据库监控平稳缓存miss没有异常上升问题彻底解决。这次事故的教训是缓存层不能只做“能存能取”必须提前把异常场景想全。7.3 缓存雪崩模拟与应急预案演练还有一次我们在压测环境模拟了缓存雪崩把所有key的过期时间统一设置为同一时刻压测QPS拉到峰值数据库的CPU使用率直接打满部分查询全部超时。现场验证了我们应急预案里的降级开关是有效的。降级策略分几层第一层配置中心开关“全部走缓存过期不查库”确保缓存失效时接口返回旧数据而不是穿透查库。第二层白名单控制仅仅让部分极大流量路径走降级正常情况下完全关闭降级避免性能损失压测中确认开关生效后我们记录了关闭降级的操作步骤以防人为遗忘。第三层数据库连接池满时快速失败通过一个独立的线程池来处理缓存回填任务防止正常请求被打爆。经过演练后我们在实际生产中能够做到的故障切换时间从原来的十几分钟压缩到3分钟以内。建议每个团队都对核心接口做一次类似的“缓存故障演练”过程很惊险但收益巨大。8. 高频面试题与底层原理补充虽说是项目总结但这些知识点和面试题高度重合我顺手把最常被问的几个底层原理讲透都是我在准备技术分享时梳理过的。8.1 Redis单线程模型为什么能扛高并发Redis的核心处理逻辑是单线程的所有命令的执行是按顺序排队进行不存在并发竞争和数据竞争的问题。那它凭什么能扛高并发答案是IO多路复用。Redis使用epoll机制把所有的socket连接都交给内核监听内核发现有连接可读或可写时通知Redis处理Redis在事件循环里逐个处理。这个机制的本质是用极小的线程切换开销处理海量连接而不是一个连接一个线程。这也解释了为什么Redis的单条命令要求足够快平均微秒级别。如果某条命令执行时间较长比如涉及KEYS *全量扫描或者HGETALL超大哈希其他所有命令都会被阻塞这就是为什么生产环境严禁使用KEYS命令。补充一个小细节从Redis 6.0开始网络IO模块改成了多线程处理但命令执行仍然是单线程。这个优化的目的是把socket读写和协议解析分摊到多线程核心命令处理依旧串行所以原子性还是被保住了这反而让许多依赖“单线程原子性”的用法在6.0版本后依然有效。8.2 Redis持久化RDB与AOF的选择策略缓存场景通常不太依赖持久化但Redis本身提供这个能力有些半缓存半存储的使用方式会用到。RDB按快照方式定时把内存的全量或增量数据序列化到磁盘文件恢复速度快适合做备份和灾难恢复。缺点是最后一次快照之后的数据可能丢失且生成快照时fork子进程如果数据量大、内存富余不足fork可能阻塞主进程。AOF追加写日志每条写命令都会记录到AOF文件安全性更高。AOF重写机制可以压缩文件大小但它的恢复速度比RDB慢而且文件通常更大。将AOF刷盘策略配置为everysec时最多丢失一秒数据这是一个比较均衡的折中方案。我的建议是纯缓存场景可以不用持久化或者仅开启RDB用于快速恢复半存储场景用AOF 每秒刷盘数据极其重要时用RDB AOF双开。双开会增加写入开销但在低写并发场景下影响很小却能换来很强的数据安全保障。8.3 Redis分布式锁与Redisson看门狗机制分布式锁是缓存场景的延伸应用当时在秒杀系统里写的锁方案后来升级成了Redisson。核心原理在前面实现里已经演示了SET key value NX EX保证原子性地在没有key时才设置并且自动过期。但有个隐患如果持有锁的线程执行时间超过锁的过期时间锁会自动释放其他线程就能拿到锁导致临界区被并发进入。Redisson的看门狗机制解决这个问题Redisson给锁续期的后台任务每隔一定时间三分之一的锁过期时间会检查当前锁是否还被持有如果持有则延长过期时间直到业务线程主动释放锁或判断锁已被抢占。需要注意看门狗只在获取锁时没有指定leaseTime时才会启动。如果手动指定了leaseTimeRedisson不会自动续期过期后锁照常释放。所以如果你的业务执行时间可能非常长要么不指定leaseTime委托看门狗续期要么自己实现续期逻辑千万别把过期时间设死。8.4 缓存分级Caffeine与Redis组合使用最后补充一下本地缓存和Redis的组合方案这是我在一个读多写少的用户信息接口里做的优化第一级Caffeine本地缓存配置最大容量和短过期时间例如容量1万条、过期30秒直接挡掉绝大部分读取请求零网络开销。第二级Redis分布式缓存过期时间5到10分钟。本地缓存未命中时再查Redis。第三级MySQL数据库兜底查询成功后回填Redis和本地缓存。这个分级的命中率能到99%左右极大地释放了Redis和数据库的压力。但要注意一致性本地缓存因为过期时间短数据延迟在几十秒内可接受如果有更新接口务必主动清理对应key在本地的缓存和Redis缓存可以用Spring Cache的CacheEvict注解或自己实现一个双删逻辑。9. 常见问题速查与避坑清单9.1 Redis缓存高频问题排查表我在维护和评审代码时整理了以下问题排查清单直接贴在这里方便查阅问题现象可能原因排查命令/方法解决方案缓存命中率极低缓存key设计不合理过期时间太短INFO stats查看keyspace_hits/misses调整key粒度、加长TTL、做预热Redis内存暴涨大key、无TTL的key、value过大redis-cli --bigkeys、MEMORY USAGE拆分大key、统一TTL、设置maxmemory-policy接口响应偶尔卡顿存在慢命令或大key阻塞SLOWLOG GET 10禁用KEYS等命令拆分大集合缓存和数据库不一致更新顺序不对、漏删缓存查日志、翻转DB与Redis的更新时间延迟双删、Binlog订阅所有请求打到数据库Redis宕机/雪崩/穿透查看Redis连接、慢查询、QPS曲线高可用集群、降级开关、空值缓存、布隆过滤器连接数打满客户端连接泄漏、连接池配置过小INFO clients、查看堆栈配置连接池上限、检查客户端关闭逻辑这张表是我内部周会分享的底稿几乎每一行都有对应的线上事故案例。建议你把它复制到自己团队的Wiki里遇到问题先查表不要每次都从零开始排查。9.2 实战避坑清单五个最常见的误操作第一个坑线上执行FLUSHALL。这是毁灭性操作Redis缓存全部清空所有请求瞬间打到数据库。我用这个操作做过一次演练效果非常吓人从此再也不敢直接在生产执行。如果确实要清理用SCAN配合DEL分批删并且提前评估流量冲击。第二个坑用KEYS *做模糊查询。这个命令会扫描全库并阻塞Redis几百万key的场景下服务基本就挂了。正确操作是SCAN cursor MATCH pattern COUNT count分段遍历。我见过有人写定时任务用KEYS user:*来做批量失效直接把Redis阻塞了好几秒。第三个坑缓存key没有统一命名规范。项目里如果有的用product:9527、有的用Product_9527、有的用productId:9527后续做预算、排查、禁用都极其痛苦。我在项目起步时定了几条规矩统一用小写字母加冒号分隔语义模块和业务ID如module:business:key不同业务线加前缀区分所有key必须有明确的TTL设置除了极少数永不过期的元数据。第四个坑缓存工具类封装过度复杂。我见过有人封装了非常强的缓存注解框架支持过期时间、条件缓存、异步刷新看起来很酷但调试问题时无从下手因为缓存行为散落在注解和底层框架里。建议老老实实用简单的CacheService工具类把逻辑显式写在业务代码里出了问题一手就能抓到。第五个坑忽略客户端连接池的合理配置。Jedis/Lettuce如果不配置连接池每个请求都新建连接再关闭Redis的连接数会异常升高TCP握手带来的CPU开销也很可观。我的建议是使用Lettuce的共享连接Spring Boot默认或者给Jedis配置池化核心参数maxTotal、maxIdle、minIdle、maxWaitMillis按预估QPS和平均响应时间计算并进行一次压测验证。9.3 缓存Redis运维小工具推荐redis-cli命令行工具最基础、最可靠。包括--stat实时监控、--bigkeys扫描大key、--latency检测延迟、--scan安全遍历。RedisInsight官方可视化工具功能比RDM更全支持内存分析、Slowlog查看、命令行交互界面也现代。redis_exporter Prometheus Grafana监控告警三件套适合生产环境。RDB tools一个基于Python的RDB文件解析工具当Redis只有RDB文件且想要离线分析内容、统计key数量时非常有用。写在最后的实操心得从接触Redis到现在我的体会是缓存不是把数据往Redis里一丢就完事它是一个需要设计、治理、运维的系统工程。很多人把缓存用成了“数据库的挡箭牌”出了问题只会加内存、加机器实际上很多问题的根源都在代码和架构设计层面。我到现在还记得第一次在线上遇到缓存穿透时的慌乱后来每次在代码评审里看到有人要访问不存在的数据却没有任何防护我都会不自觉地去翻布隆过滤器是否已经接好。踩过的坑多到我已经养成了条件反射但也正因为这些坑让我对Redis的每个特性都理解得比看十篇文档都深刻。如果让我给你的项目一个最直接的建议先把缓存监控做起来命中率、内存、连接数、慢命令这四个指标盯住很多问题还没到影响业务你就能提前感知到。缓存治理这条路监控和数据才是第一生产力。后面我打算再把Redis Cluster的扩缩容和性能调优单独整理一篇如果你也在实战中遇过类似问题欢迎在评论区聊聊你的处理方式。