大型业务系统而言，缓存是减低系统压力，提高性能最直接也是最有效的方法之一。系统缓存一般分为几个层次，一姑且称其为元数据吧，即直接从数据库检索出来的数据；二是业务数据，即经过业务处理后的带有业务逻辑的数据。三是客户端的缓存（针对C/S架构而言）。下面主要针对元数据缓存的设计提出自己的浅见，希望大家指正。
缓存的设计需要解决的有两个主要问题，一是效率，缓存本身就是为了提高性能，不要因为缓存的原因反而减低了性能；二是数据的实时性，对于缓存数据的实时性，各种缓存设计都有自己的策略，比如设置过期时间、定时刷新等。具体采用哪种策略和具体的业务不无关系。下面先看一下设计思路：
首先，如果解决效率问题呢？ 我想到的是SQL SERVER的缓存，它的缓存原理是把SQL语句作为缓存条件来缓存结果。这样设计的好处是可以在执行之前就把结果返回，用空间换时间，所以对于大型的数据库，如果可以提供足够的内存作为缓存，对于提高数据库的性能是非常有帮助的，当然这必须是基于64bit的操作系统和使用64bit的SQL SERVER，或者在32bit的情况下开启AWE，启用大内存。按照这种思路，我选择使用Hashtable作为缓存的容器，可以充分利用它本身的高效查询性能，使用DataSet作为数据存储容器。那如何对数据进行缓存组织呢？如下图：
我们以表命为缓存组的KEY，Hashtable作为缓存具体数据的内容。然后以查询的过滤条件（包括要查询的字段、过滤条件、限制条件等等）作为数据的Key，后面直接对应它的查询结果。这样只要告诉我查询哪一张表，使用什么过滤条件，我就可以马上定位到具体的查询结果，如果没有结果就直接返回null。这样我们可以使用简单的方法达到高效获取缓存数据的目的，当然这中间会遇到不少的问题，比如锁的问题，这会在下一篇中专门介绍关于锁的内容。
可能大家会有疑问，为什么要使用两层Hashtabe来处理，直接使用一层不是更快吗？这里主要是为实时更新作准备的。假设我们缓存中的某张表发生变化了（或者说被更新了），那我们可以知道更新的是缓存中的那些数据吗？ 当然如果要详细分析更新的记录，然后到缓存中全部遍历有关该数据的缓存全部清空也是可以做到，关键的问题在于这样做的代价是否过高了呢？我个人认为这样的处理是得不偿失。所以我的处理方式是，该表一旦发生变化，就直接删除关于这张表的所有缓存项。这也就是我为什么把缓存设计为两层的原因，我只要找到变化的表，直接删除整个组就可以，省时省力。（待续……）
浙公网安备 33010602011771号