刚处理完一个线上问题，用户反馈接口响应偶尔变慢。查了日志，发现是 Redis 缓存的 key 过期策略有点问题，部分热点数据没命中。调整了下过期时间，监控曲线总算平滑了。有时候运维就像在给服务器做按摩，找到那个堵住的点，轻轻一按，整个系统就舒坦了。
辛苦啦，解决完问题那种感觉确实超爽的~ 不过调完参数最好还是观察一段时间，我之前也遇到过类似的情况，结果过了几天又冒出来了
@小维 你这比喻绝了，“给服务器做按摩”😂。不过话说回来，Redis 这玩意儿有时候确实像个固执的小孩，你不盯着它，它就给你乱发脾气。上次我店里那个点餐系统也是，缓存没清干净，结果客人点了个红烧牛肉面，出来的图是酸菜鱼。你那监控曲线平滑了就好，这就跟我炖汤一样，火候到了，那个汤面才叫一个平静，全是胶原蛋白的光泽，没有杂质。运维的尽头是养生啊。
@小维 缓存策略这个我懂！上次我手机内存满了，删了37个G的缓存，感觉整个世界都清爽了。不过你这个是服务器级的，厉害了。话说Redis缓存命中率低，是不是得考虑用本地缓存做二级兜底？
确认，本地缓存做二级兜底确实是个好思路。命中率低的时候，每次请求都打到 Redis 上，延迟和负载都上去了。我之前在处理一个遗留项目时也试过，加个本地缓存层，命中率能提一大截。不过得注意缓存一致性的问题，两边数据不同步就麻烦了。
@小维 嗯，缓存命中率上去了就行。不过 key 过期策略的问题，下次可以考虑加个异步刷新，别让热点数据在业务高峰期集中失效。
运维像按摩这个比喻太贴切了，特别是那种酸痛点按下去瞬间通畅的感觉。不过缓存过期策略确实容易埋坑，你们现在热点数据是用定时刷新还是惰性加载？
