缓存漫谈

缓存是在提升系统响应时常用的一种技术，在我之前的blog中也提及过好几次这部分的技术，今天还是想从缓存涉及的一些方面再次的去谈谈，在系统缓存上通常采用的是有页面缓存、处理缓存和数据缓存这三种具体的类别，应该说这三种缓存在实现上还是稍有不同，尽管底层的缓存实现是一样的。
页面缓存
页面缓存是指对页面中的内容片断进行缓存的方案。比如页面中有一个部分是显示栏目中的内容的，那么就可以缓存这个部分，在进行第二次请求的时候就直接从缓存中取出这部分的内容(其实就是这部分的html了)，这种情况下，缓存的作用其实非常明显，在典型的action+service+dao这样的结构中，在采用页面缓存后就意味着不需要经过action、service、dao这些层次的处理了，而是直接就返回了，对于系统响应速度的提升来说是非常明显的。
页面缓存通常采用oscache来进行实现，oscache提供了一个jsp tag，可通过这个tag来包含需要缓存的内容部分，当然，缓存的这个内容部分需要有对服务器的请求或逻辑计算等的，可想而知，去缓存一段静态html是没有意义的。
其次需要定义缓存的这段内容的key，例如我们要去缓存页面中某个栏目的某页的内容，对于这段内容而言唯一的key就是栏目ID以及当前页数，这样就组成了这段缓存的key了，其实这个部分看起来好像是很简单，但有些时候会很麻烦，要仔细的想清楚这段内容的唯一的标识的key到底是什么，^_^，通常的做法其实可以从action中需要获取的参数或service接口的参数来决定....
页面缓存中还需要做的一个步骤就是通知缓存需要更新，页面缓存和其他缓存稍有不同，需要告诉它，这个时候不能再使用缓存中的内容了，需要从后台再重新获取来生成新的缓存内容，这个其实很简单，因为很难在后台发生变化的时候自己来更新缓存的内容，只能是去通知它，然后让它再次发起请求来生成新的内容放入缓存中。
页面的缓存的使用对于系统的响应速度确实会有很大的提升，在实现页面缓存时最麻烦的主要是缓存的key的定义以及缓存更新的通知，缓存key的定义这个自然框架是没法解决的，不过缓存更新的通知其实在框架中可以考虑一种通知模型的，^_^，就像事件通知那样........在实际的项目中，可以自己去实现一个这样的通知模型或者就是简单的采用单例方式来标识某个key是否需要更新。
页面缓存在实际的项目中使用非常的多。
处理缓存
处理缓存是指对于action、service、dao或者系统层次中的某方法进行缓存，说直接点，就是对某个类的某个方法的结果做缓存，这样在下次进行完全相同的请求的时候就可以直接取缓存了，这种响应速度的提升也是非常明显的。
处理缓存在现在的情况下其实采用任务的缓存工具包都可以实现，如oscache、ehcache、jbosscache等，但目前还没有处理缓存框架的出现，这个和处理缓存是否应该存在的意义也是有关系的，处理缓存框架要做到的其实就像拦截一样的方式，和oscache tag类似。
同样，处理缓存的麻烦也在于怎么样去定义这个key，很多情况下可以根据方法的输入作为key，方法的输出作为key的值，但也会有其他一些复杂的情况，这个时候定义key就会变得复杂些了。
处理缓存同样有通知更新缓存的情况，和页面缓存基本是一样的。
应该说，处理缓存和页面缓存非常的相似，从实现上来说基本是完全一致的，在使用上来讲处理缓存使用的好像不多。
数据缓存
数据缓存估计大家都很熟悉，就是对系统的数据进行缓存的方式，典型的就是Hibernate的一级、二级数据缓存。
数据缓存在实现上如果是用hibernate的话更多的是直接使用hibernate的一级、二级以及查询缓存，如果自己要实现的话可以去参考hibernate的实现机制。
数据缓存的key在一级、二级缓存中采用的都是数据的标识键的值的方式，查询缓存采用的是查询参数、查询语句的方式。
数据缓存的更新则是hibernate在进行存储时直接更新缓存的内容，而对于查询缓存则是采用全部直接清除的方式，这样在下次进行查询时自然会重新去查询，^_^，大家可能会想，为什么页面缓存和处理缓存不采用这样的方式来实现缓存的更新，稍微想想就知道了，在后台发生改变的时候其实是不知道需要移除哪些key的，所以hibernate为了避免这个麻烦，采用的就是当数据一旦发生改变的时候就清除全部的查询缓存，而不是只去清除相关的缓存，其实这里可以采用一种订阅式的模型，呵呵，当然，也增加了框架的复杂度。
数据缓存使用的应该是最多的，效果也是很明显的。

以上三种缓存是目前缓存实现时通常碰到的三种状况，里面按使用的多少来排序应该是：数据缓存、页面缓存和处理缓存；实现的难度上从难到易的顺序应该是：处理缓存、页面缓存、数据缓存；对于系统响应速度提升的效果来说从最好到好的顺序应该是：页面缓存、处理缓存、数据缓存。