架构真经 | 那些年，我们踩过的缓存坑

野性酷女 2022-06-10 13:20 216阅读 0赞

在码农的世界里，一直以来都有一个信仰：只要使用了缓存，性能就会翻倍；用上缓存的应用就像是打通任督二脉的武林高手，内力生生不息。但是今天我想跟各位猿类朋友聊一聊自己在使用缓存时遇到的那些坑，这里主要讲对象缓存应用部分，想了解全面的推荐阅读《[架构][Link 1]真经》。

# 正文 #

## 案例一 ##

前几天突然发现 [Redis][] 监控显示某 [redis][Redis] 实例内存使用量突破了 14G 大关，当时我就震惊了，这是要翻车的节奏啊！通过 info 指令查看，发现 key 的量并不是太高，所以怀疑有个别业务 value 的 size 比较大，为了保证生产不受影响，从生产上导出 rdb 文件进行分析。通过

rdb -c memory redis_dump.rdb —bytes 1024 -f memory.csv 
     
      
       1
      
     
      
       1

将大于1024 字节的 key 导出。然后进行排序：

sort -t, -k4nr memory.csv |head -n 20
     
      
       1
      
     
      
       1

终于找到了罪魁祸首。如下图：

![1][]

紧急删除该 key 临时解决了问题，经复盘发现，此问题是开发时缓存使用不当，所有信息都不过期，数据只能越增越大。

总结：缓存中放置的应该是热数据，同时缓存策略也存在问题，应该针对每条记录设置不同的 key ，而不是都放在一个 key 下。

## 案例二 ##

某历史项目最近总是报警（系统负载升高，响应变慢，应用频繁 GC），只能频繁重启应用。分析 Dump 文件，发现创建的对象非常多，但没有明显的占用大户。于是继续分析占用内存较大的对象，发现都是 [hibernate][] 的代理对象；接下来去看 Hibernate 的配置，发现开启了二级缓存，同时 Ehcache 中没有控制缓存对象的个数，导致应用启动一段时间后，随着缓存对象的增多，很快会导致 GC 了。于是我们紧急上线，关闭了部分对象的缓存，问题得到了初步缓解。

总结：当使用本地缓存（如 Ehcache）时，一定要严格控制缓存对象的个数及生命周期。由于 JVM 的特性，过多的缓存对象会极大的影响 JVM 性能。

## 案例三 ##

某个正常运行的应用突然报警线程数高，之后很快就内存溢出。查看日志发现无法连接 Memcached，继而查看 Memcached 配置，发现连接数过高，拒绝连接。而应用连接 Memcached 的超时时间较长，导致请求线程不断堆积，最后应用内存溢出。临时解决方案是先增加 Memcached 的连接数，之后应用修改连接超时时间。

总结：当我们在使用远程缓存（如 Redis、Memcached）时，一定要对超时时间进行控制，一般来讲缓存的总体响应时间不能高于 50ms ，否则缓存会成为应用的负担，而不是帮手。

## 案例四 ##

某项目关键业务忽然报警业务波动，查看应用日志发现访问 Redis 异常，查看 Redis 发现做了主备切换；这次超时时间设置没问题，但没有针对缓存不可用做降级处理，导致业务流程中断。

总结：使用缓存时，一定要有降级处理；尤其是关键业务环节。

## 案例五 ##

某项目使用缓存后，开发[测试][Link 2]没问题，上生产后，服务却不可用。查看日志发现是该应用的缓存 key 与其他应用缓存的 key 冲突，导致错误。

总结：缓存使用时，一定要有隔离的设计。比如 Redis 可以选择不同的 DB，或者 Ehcache 定义不同的 Cache 名。如果这些都不方便实施，至少也要有 key 的命名规范，否则天知道会发生什么。

## 案例六 ##

某项目使用 Redis 缓存临时数据，上线后出现错误数据，但由于没有开发管理功能，导致发生问题时，看不到数据，也无法管理，使得应急时间较长。

总结：当使用缓存后，一定提供相应的管理手段。否则发生事故时，只能两眼一抹黑。

## 案例七 ##

某应用在访问时经常时快时慢，同时 DB 负载也忽高忽低；分析代码发现项目中缓存设置了一个固定的失效时间，当缓存失效时，会造成一段时间内访问 DB 的请求非常集中。

总结：简单方案就是将缓存失效时间分散开，比如我们可以将失效时间设置为一个区间内的随机值，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

## 案例八 ##

某计费项目发现计算结果有误差，分析日志时发现：系统修改规则后，较长时间仍在使用旧规则。查看 Ehcache 配置文件发现过期时间很长，导致规则更新后，很长时间不生效，部分订单计算费用出现误差。

总结：使用本地缓存又需要数据一致性时，可以考虑用 Zookeeper 之类的协调服务，实现一个更高效的缓存更新机制。

## 案例九 ##

这是一个缓存穿透的案例，某模块设计使用了缓存，但发现[数据库][Link 3]负载并没有大幅下降。分析代码发现，缓存逻辑如下：数据库存在纪录则放到缓存中，不存在则下次仍然会访问数据库；导致不存在的订单频繁查询时，缓存没有效果。

总结：缓存穿透是一个常见问题，我们需要把 null 也作为一种缓存结果，否则此类情况等于缓存是失效的。

## 结尾 ##

以上这些案例都是我们亲身经历的血的教训，在研发过程也是很容易忽略的点。诚然使用缓存是提高应用性能的有效手段，但没有深入的分析与设计就很容易造成灾难性的影响。我思故我在，我们猿类最大的优点就是思考能力，希望这些小案例能引起大家更深层次的思考。另外，软件设计思想来源于生活，比如看看 CPU 的设计，有一级缓存、二级缓存，估计有很多小伙伴也在做缓存设计时这样做了。生活中处处有设计，只要用心总能观察到。

转载声明：本文转自[微信][Link 4]公众账号「泡面办公室」，[架构真经 | 那些年，我们踩过的缓存坑][Link 5]。

[Link 1]: http://lib.csdn.net/base/architecture
[Redis]: http://lib.csdn.net/base/redis
[1]: /images/20220610/3c523bfa8c544e3d91b9b1f0f0a07161.png
[hibernate]: http://lib.csdn.net/base/javaee
[Link 2]: http://lib.csdn.net/base/softwaretest
[Link 3]: http://lib.csdn.net/base/mysql
[Link 4]: http://lib.csdn.net/base/wechat
[Link 5]: http://mp.weixin.qq.com/s?__biz=MzIyNDM1NjMyMw==&mid=2247484359&idx=1&sn=5cad4f0278ac8e95823884573ebf653c&chksm=e811714bdf66f85d8d036652e0285af27f71e3505d8225ba29bde86df3ab1e634664798e62dd&mpshare=1&scene=23&srcid=0504it0LygGG8BVc8qqBxjQp#rd