文章目录前言1. 诡异线上现象内存悄咪咪疯狂膨胀2. 问题根源SET EXPIRE有原子性大坑2.1 并发时序到底怎么翻车的3. 怎么解决用原子单命令搞定写入加过期3.1 SpringRedisTemplate简单写法3.2 底层调用setEx原生命令写法4. 又一个大坑设置过期≠到点立刻删掉4.1 惰性删除你不问我就不删4.2 定期删除随机抽查碰运气4.3 可行的处理手段5. 日常开发一定要记住的避坑清单5.1 TTL单位千万别搞混5.2 DEL、RENAME会乱改过期时间5.3 持久化也藏小坑6. 最后唠两句P.S. 无意间发现了一个巨牛的人工智能教程非常通俗易懂对AI感兴趣的朋友强烈推荐去看看 传送门https://blog.csdn.net/HHX_01前言不知道兄弟们有没有遇见过这种离谱线上故障。代码明明给所有key都加上24小时过期时间结果Redis内存呼呼往上涨告警疯狂轰炸运维。我之前接手一个千万UV的推荐业务就踩了这个大坑折腾整整两天。1. 诡异线上现象内存悄咪咪疯狂膨胀业务场景很简单Redis存用户24小时行为记录key格式是user_behavior:{user_id}。按正常人脑瓜子理解到点自动过期清理内存应该稳稳当当不会暴涨。理想很丰满现实直接给你一记耳光。上线两周内存直接干到80%告警线。我当时内心不是都写过期时间了吗Redis这是闹哪一出摸鱼不干活拿redis‑cli --bigkeys排查好家伙一大堆本该消失的key活得好好的。执行TTL命令一看返回-1代表永不过期我当场人傻了。代码看着一点毛病没有publicvoidsaveUserBehavior(longuserId,Stringbehavior){Stringkeyuser_behavior:userId;redisTemplate.opsForValue().set(key,behavior);redisTemplate.expire(key,24,TimeUnit.HOURS);}测试环境怎么跑都复现不出来本地debug跑一万遍都正常。线上高并发才暴雷这种bug最折磨人就像家里偶尔出现的蟑螂你永远抓不到现行。2. 问题根源SET EXPIRE有原子性大坑2.1 并发时序到底怎么翻车的很多同学以为set写完紧接着expire这两步就是绑定在一起的。大错特错这是两条独立Redis指令中间完全可以插入别的请求。线程A执行set把key写进去线程B过来直接DEL删掉这个key线程A姗姗来迟执行expire给一个已经不存在的key设置过期expire对不存在的key不会报错就安安静静啥也不干。后续再set这个key过期时间直接没了变成永久常驻key。这就好比你点外卖下单之后设置一小时后取消结果外卖提前被别人拿走了你那个取消操作就彻底作废。测试环境并发低碰不上这个时序所以永远测不出来。等到线上流量冲上来bug直接批量生产僵尸key。3. 怎么解决用原子单命令搞定写入加过期3.1 SpringRedisTemplate简单写法publicvoidsaveUserBehavior(longuserId,Stringbehavior){Stringkeyuser_behavior:userId;//一条命令搞定set过期原子不被打断redisTemplate.opsForValue().set(key,behavior,24,TimeUnit.HOURS);}就这么小小的改动直接避免中间被别的命令插队。而且网络请求从两次往返变成一次千级QPS场景Redis负载直接降大概15%属于顺便捡来的性能提升。3.2 底层调用setEx原生命令写法BooleanresultredisTemplate.execute((RedisCallback)connection-{byte[]keyBytesredisTemplate.getKeySerializer().serialize(key);byte[]valueBytesredisTemplate.getValueSerializer().serialize(value);returnconnection.setEx(keyBytes,86400,valueBytes);});有些老项目封装比较奇葩可以直接调用底层setEx效果一模一样。4. 又一个大坑设置过期≠到点立刻删掉把原子问题修好之后本以为万事大吉。结果观察几天内存还在慢慢涨。我那时候心态都崩了还有完没完合着Redis过期不是到点准时一键大扫除4.1 惰性删除你不问我就不删惰性删除逻辑很摆烂只有你来查询这个key的时候才检查有没有过期过期就顺手删掉。要是这个key变成冷数据再也没人访问就算过期了它就死皮赖脸占内存不走。好比家里垃圾袋放角落你不去看它就永远不会自己消失。4.2 定期删除随机抽查碰运气Redis每10秒随机抽20个带过期的key把里面过期的清理掉。划重点是随机抽样不是遍历全部key。运气不好一批冷过期key连续好几轮没被抽中能在内存躺好几个小时。两个机制组合起来就会出现大量过期key苟在内存里的奇观。不要幻想Redis会准时定点批量清理全部过期数据。4.3 可行的处理手段第一种业务侧搞个小脚本定期扫描匹配前缀的key触发检查过期redis-cli--scan--patternuser_behavior:*|xargsredis-cli ttl执行ttl访问key就会触发惰性删除干掉已经过期的数据。线上不要用keys命令会堵死Redis务必用scan。第二种调整redis.conf配置适当提高清理积极性会多消耗一点CPU需要权衡hz 10 → hz 100 active-expire-effort 1 → active-expire-effort 10hz代表后台任务执行频率active‑expire‑effort控制过期清理投入的cpu比例。不要无脑拉满CPU会扛不住。5. 日常开发一定要记住的避坑清单5.1 TTL单位千万别搞混expire单位是秒pexpire才是毫秒。用Java客户端一定要显式写TimeUnit不要靠猜。见过同事把毫秒当成秒设置过期1000以为一千秒实际一秒就没了查bug查得怀疑人生。5.2 DEL、RENAME会乱改过期时间key删掉之后再重新set过期时间直接清空。rename重命名key会继承旧key过期时间如果目标key已经存在则直接丢掉原有过期时间。rename这个坑非常隐蔽大部分人写代码完全想不到重命名还会动TTL。5.3 持久化也藏小坑AOF会记录key过期之后的DEL删除指令。但是RDB快照过期还没删掉的key会直接被保存进RDB文件。重启恢复之后这批本该过期的key又复活了经典僵尸复活现场。6. 最后唠两句写业务的时候千万不要想当然。不要默认“我写了expire就万事大吉”。只要是两条分开执行的命令你脑子里就要多问一句中间请求被打断、被插入别的操作会发生什么很多线上bug测试环境完美复现不了只有高并发才会露马脚。兄弟们平时线上还踩过Redis哪些奇奇怪怪的坑评论区可以交流下。P.S. 无意间发现了一个巨牛的人工智能教程非常通俗易懂对AI感兴趣的朋友强烈推荐去看看传送门https://blog.csdn.net/HHX_01