缓存使用案例分析

现象：
Redis单个key超过10G

原因：
使用了Redis的Hash结构，不支持针对Hash中的key设置超时

总结：
Redis的Hash结构，不支持对Hash中的key设置超时时间。如果需要对Hash的key设置超时时间，放入单独的Redis key中

---

现象：
某历史项目系统负载升高，响应变慢，应用频繁 GC

原因：
Hibernate 中开启了二级缓存，同时 Ehcache 中没有控制缓存对象的个数，缓存对象增多，导致频繁GC

总结：
使用本地缓存（如 Ehcache ）时，一定要严格控制缓存对象的个数及生命周期。

---

现象：
某个正常运行的应用突然报警线程数高，之后很快就内存溢出

原因：
由于memcached连接数达到最大限制，应用无法连接memcached，并且超时时间设置不合理，导致线程堆积

总结：
使用远程缓存（如 Redis、Memcached ）时，一定要对超时时间进行控制

---

现象：
某项目忽然报警业务波动

原因：
Redis进行主备切换，导致应用连接redis异常，应用没有对缓存不可用做降级处理导致业务中断

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

---

现象：
某项目使用缓存后，开发测试没问题，上生产后，服务却不可用

原因：
该应用的缓存 key 与其他应用缓存的 key 冲突，导致错误

总结：
缓存使用时，一定要有隔离的设计。物理隔离（不同的缓存实例），逻辑隔离（缓存key使用不同的前缀）

---

现象：
某项目使用 Redis 缓存临时数据，上线后出现错误数据，难于定位问题

原因：
由于没有开发管理功能，导致发生问题时，看不到数据，也无法管理

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

---

现象：
某项目发现计算结果有误差

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

总结：
使用本地缓存又需要数据一致性时，需要有一个实时的缓存更新机制

---

现象：
某应用在访问时经常时快时慢，同时 DB 负载也忽高忽低

原因：
项目中缓存设置了一个固定的失效时间，当缓存失效时，会造成一段时间内访问 DB 的请求非常集中

总结：
使用缓存要避免常见的缓存穿透、缓存雪崩、缓存并发的问题。

---

现象：
某模块设计使用了缓存，但发现数据库负载并没有大幅下降

原因：
缓存逻辑如下：数据库存在纪录则放到缓存中，不存在则下次仍然会访问数据库；导致不存在的订单频繁查询时，缓存没有效果，导致缓存穿透。

总结：
使用缓存要避免常见的缓存穿透、缓存雪崩、缓存并发的问题。

---

以上为使用缓存时需要大家注意的地方，希望能对大家有所帮助。