使用缓存的误区.docxVIP

如果说要对一个站点或者应用程序经常优化，可以说缓存的使用是最快也是效果最明显的方式。一般而言，我们会把一些常用的，或者需要花费大量的资源或时间而产生的数据缓存起来，使得后续的使用更加快速。　如果真要细说缓存的好处，还真是不少，但是在实际的应用中，很多时候使用缓存的时候，总是那么的不尽人意。换句话说，假设本来采用缓存，可以使得性能提升为100（这里的数字只是一个计量符号而已，只是为了给大家一个“量”的体会），但是很多时候，提升的效果只有80,70，或者更少，甚至还会导致性能严重的下降，这个现象在使用分布式缓存的时候尤为突出。　在本篇文章中，我们将为大家讲述导致以上问题的9大症结，并且给出相对应的解决方案。文章以.NET为例子进行代码的演示，对于来及其他技术平台的朋友也是有参考价值的，只要替换相对应的代码就行了！　为了使得后文的阐述更加的方便，也使得文章更为的完整，我们首先来看看缓存的两种形式：本地内存缓存，分布式缓存。　首先对于本地内存缓存，就是把数据缓存在本机的内存中，如下图1所示：　从上图中可以很清楚的看出：应用程序把数据缓存在本机的内存，需要的时候直接去本机内存进行获取。对于.NET的应用而言，在获取缓存中的数据的时候，是通过对象的引用去内存中查找数据对象的，也就说，如果我们通过引用获取了数据对象之后，我们直接修改这个对象，其实我们真正的是在修改处于内存中的那个缓存对象。　对于分布式的缓存，此时因为缓存的数据是放在缓存服务器中的，或者说，此时应用程序需要跨进程的去访问分布式缓存服务器，如图2：　不管缓存服务器在哪里，因为涉及到了跨进程，甚至是跨域访问缓存数据，那么缓存数据在发送到缓存服务器之前就要先被序列化，当要用缓存数据的时候，应用程序服务器接收到了序列化的数据之后，会将之反序列化。序列化与反序列化的过程是非常消耗CPU的操作，很多问题就出现在这上面。　另外，如果我们把获取到的数据，在应用程序中进行了修改，此时缓存服务器中的原先的数据是没有修改的，除非我们再次将数据保存到缓存服务器。请注意：这一点和之前的本地内存缓存是不一样的。　对于缓存中的每一份数据，为了后文的讲述方面，我们称之为“缓存项“。　普及完了这两个概念之后，我们就进入今天的主题：使用缓存常见的9大误区：太过于依赖.NET默认的序列化机制缓存大对象使用缓存机制在线程间进行数据的共享认为调用缓存API之后，数据会被立刻缓存起来缓存大量的数据集合，而读取其中一部分缓存大量具有图结构的对象导致内存浪费缓存应用程序的配置信息使用很多不同的键指向相同的缓存项没有及时的更新或者删除再缓存中已经过期或者失效的数据　下面，我们就每一点来具体的看看！　太过于依赖.NET默认的序列化机制　当我们在应用中使用跨进程的缓存机制，例如分布式缓存memcached或者微软的AppFabric，此时数据被缓存在应用程序之外的进程中。每次，当我们要把一些数据缓存起来的时候，缓存的API就会把数据首先序列化为字节的形式，然后把这些字节发送给缓存服务器去保存。同理，当我们在应用中要再次使用缓存的数据的时候，缓存服务器就会将缓存的字节发送给应用程序，而缓存的客户端类库接受到这些字节之后就要进行反序列化的操作了，将之转换为我们需要的数据对象。　另外还有三点需要注意的就是：这个序列化与反序列化的机制都是发生在应用程序服务器上的，而缓存服务器只是负责保存而已。.NET中的默认使用的序列化机制不是最优的，因为它要使用反射机制，而反射机制是是非常耗CPU的，特别是当我们缓存了比较复杂的数据对象的时候。　基于这个问题，我们要自己选择一个比较好的序列化方法来尽可能的减少对CPU的使用。常用的方法就是让对象自己来实现ISerializable接口。　首先我们来看看默认的序列化机制是怎么样的。如图3：　然后，我们自己来实现ISerializable接口，如下图4所示：　我们自己实现的方式与.NET默认的序列化机制的最大区别在于：没有使用反射。自己实现的这种方式速度可以是默认机制的上百倍。　可能有人认为没有什么，不就是一个小小的序列化而已，有必要小题大做么？　在开发一个高性能应用（例如网站）而言，从架构，到代码的编写，以及后面的部署，每一个地方都需要优化。一个小问题，例如这个序列化的问题，初看起来不是问题，如果我们站点应用的访问量是百万，千万，甚至更高级别的，而这些访问需要去获取一些公共的缓存的数据，这个之前所谓的小问题就不小了！　下面，我们来看第二个误区。　缓存大对象　有时候，我们想要把一些大对象缓存起来，因为产生一次大对象的代价很大，我们需要产生一次，尽可能的多次使用，从而提升响应。　提到大对象，这里就很有必要对其进行一个比较深入的介绍了。在.NET中，所谓的大对象，就是指的其占用的内存大于了85K的对象，下面通