近期线上的redis业务集群因为不明原因的数据写入会偶发的出现内存使用过高的问题，针对这个现象特意在业务侧代码针对redis的写操作增加了切面拦截监控，监控各类redis的数据写入。事情的初衷本来是为了定位偶发的数据写入，但是意外的收获是竟然发现了线上存在大量不合理缓存数据的写入。
根据常识，redis的缓存从直观的理解上来说应该属于读多写少的场景，如果线上出现大量持续的缓存写入，那么大概率是缓存没有命中，这里的原因可能是redis的key设计不一致或缓存本身在短时间内就不会被再次访问。而凑巧的是我们的项目中居然同时存在上述两种场景的问题，让人觉得苦笑不得。
首先针对缓存设计和使用是需要针对业务场景去设计，有些业务场景决定了在缓存有效时间内基本上不会发生二次访问，那么这种场景就没必要使用缓存占用内存资源。
其次在选择本地缓存和远程缓存的选择上，综合考虑缓存的数据量+单次请求访问缓存的次数，优先考虑使用本地缓存代替远程缓存，频繁访问远程缓存的网络开销成本也是非常大的。
最后在优化性能的时候，综合考量业务侧和技术侧的优化，从业务团队的经验来说业务侧的优化带来的效果远远大于技术侧的优化，不要太过于执着技术优化。
近期在不断的踩坑和爬坑中越来越意识到我们往往忽略日常基础的东西，过于追求所谓的高大上技术了。
网友评论