老生常谈--缓存使用

缓存，我想大家都不陌生，做互联网的，应该都使用过，或者起码都知道怎么使用它。每每说到网站架构、性能优化等这些每个公司必经的过程的时候，缓存一定会出现，也算是老生常谈了。既然是老生常谈，我今天又拿出来谈，一我不是老生，二我也谈不出花儿，如果是抱着这个目的来的，各位该改Bug的都还是回去改Bug吧。本文呢，不谈高大上，不谈炫酷拽，主要是列举出几个缓存使用不得当的实际场景，供大家思考，这里指的缓存也特指服务器后端通常使用的分布式缓存，如：MC，Redis，本地缓存、页面缓存等不包括在内。这些场景只是我们在使用缓存不当上的凤毛麟角，问题虽小，不过还是具有一定代表性。

       一切不以解决实际问题的优化，都是扯淡。

       一切为了解决实际问题进行的优化，而优化出了更糟糕的新问题，建议还是扯淡去吧。

       缓存就是这么个东西，有人说它就是个万能的膏药，哪儿痛贴哪儿，事实上也是如此，大家经常听到的话也是说，加缓存啊，放缓存啊，而且加了缓存也确实能够缓解DB的压力，缩短用户响应时间。好，那么但是来了，我想大家也一定遇到过这样一个场景，QA或者产品过来问，这个是什么问题啊，开发脑子里第一反应，或者说出来的都是，会不会是缓存问题？先不说到底是不是缓存导致，起码证明缓存是很容易，且经常出问题的，究其原因无非是使用不当，或者滥用。所以，后来我总结这东西，本来奔着哪儿痛贴哪儿去的，一不小心，搞成贴哪儿哪儿痛了。

       

       说穿了就是缓存刷新的问题，通常的主动刷新和被动刷新等缓存策略不做过多讨论，只列出出现问题的场景，供大家思考。

       场景一：我们通常都是用MVC的模式来进行互联网应用开发，缓存是可以加在MVC的每个层次上的，但是如果我们对于同一个数据，进行了多层次的缓存.....再复杂一点的场景，两个系统，一个负责接口提供(在Service)，一个负责接口调用，然后接口调用方 在其MVC 的C中也还有调用，如果这三方都做了缓存，那么问题来了。。。。。

       场景二：对象拆分缓存。一个很好的策略，开始是为了解决一个问题场景：对于一个大对象，我们有可能使用频率最高的只是他所有属性中的个别几个属性，比如：ID、Name 等字段，还有一些是使用特别少，但是又比较消耗存储资源的属性，如果把整个对象缓存起来，那么，这些消耗资源的属性必定会被无辜的从分布式缓存中加载出来好多次，消耗不少的网络资源。解决办法就是对象拆分缓存，减小缓存粒度，按照字段进行缓存。场景复杂化，如果一个表中的ID字段，在多个表中都有冗余，这多个表数据也都做了缓存，那么问题又来了。。。。。。

       先来这俩吧，我相信很多人都看到了里面的问题，因为问题很明显，但我也相信是不是很多人也遇到过，这是我们现在系统中遍布各个角落的问题，也是很头疼的问题，就像一只蚊子，打不死，但时不时过来叫唤两声骚扰你。这两个场景虽然比较简单，问题比较小，但是却反映了，在使用缓存中，粒度把控，层次把控过程中遇到的问题，再进一步总结，问题就是如何保证在粒度足够小，层次多(先抛开多层次缓存的必要性) 的场景下，还能保证缓存数据的唯一性，即，相同数据，内存中只放一份，有人可能会喷说，谁说内存只能放一份，当然，根据业务的划分，各业务系统之间的独立性，公用数据各自另外缓存未尝不可，只要缓存刷新能控制好，或者本身产品对于数据的失效容忍度比较大，各自权衡。

        回过头来看上面两个场景，场景一重点说多层级缓存的必要性，这里再加工特指一下，特指同一数据，在多个架构层次上进行缓存。前面说过，缓存的作用可以有很多，常用的，一个减缓DB压力，一个加快给用户的响应，因为我们只说服务端的缓存，那我们主要目的就是为了减缓DB压力。对于这种优化，通常我们都将缓存架在离DB最近的层次上，比如架在持久层之上，接口层之下，既然已经在持久层之上做了缓存，别的层级再做缓存意义就不大，因为本身持久层接口粒度已经足够小，能满足大多的上层业务数据封装需求。对于场景二，小粒度的缓存，不会有内存资源的浪费，灵活性也更高，但如果使用不当带来的问题也是明显的，所以这就要求在使用的时候可以根据实际情况来制定一个规范，比如，对于多个表关联的ID字段，只缓存被关联表的ID字段，其他用于冗余的都可不进行缓存。

       细节决定成败，虽没那么严重，但对于互联网的系统来说，对于开发人员来说，如果细节处理不好，带来的麻烦也是让人很头疼的，不过好在万变不离其宗，再复杂的业务场景，通过总结分析，其实都可以归到几个大问题类别上来，有时候经验和教训，远比那些技术理论要来的更深刻，更直接一些~