OEA中的缓存模块设计

一般缓存介绍

    网上介绍缓存的文章比较多，在这里我就挑点重点说一下。

    缓存是信息系统软件硬件设计中常用的设计方法：从底层硬件的CPU结构中的多级缓存，到软件中操作系统中内存管理的设计，再到应用软件中的高繁数据的缓存设计；在代码设计方面，小到一个冗余变量的设计，大到分布式缓存的设计；都可以见到缓存设计的身影。

    缓存设计的目的是临时存储需要大量时间进行计算的结果，是一种空间换时间的思想。

    缓存设计中的最重要的变化点是：更新策略（过期策略）。常见的更新策略有：实时检测、心跳检测、缓存依赖检测、绝对时间过期、滑动时间过期等。当然，在应用程序设计中，一个通用的缓存框架，缓存的具体位置也是一个常用的变化点，如：内存、文件、数据库、网络、云。在具体设计中，需要注意这两个变化点。

OEA缓存目标

    以下列举了OEA缓存模块中目前需要支持的一些目标：

1. 支持DDD领域模型设计。
   OEA框架是基于领域驱动的特定领域的产品线架构框架。它是面向领域模型的，而领域模型是DDD中所描述的富领域模型、聚合对象，缓存框架需要支持这样的实体设计方式。目前，有两类实体最需要使用缓存：高繁使用的聚合根对象、一般的“外键”引用对象。
2. 对类库开发者透明。
   OEA框架的所有设计围绕实体类进行，开发者最多接触的就是实体类的开发。在实体类及其存储机制的开发过程中，完全不需要考虑缓存机制，而是应该在实体类开发完毕后，在应用程序初始化代码处，使用简单的API定义哪些类需要缓存、如何缓存，OEA框架完成所有的缓存的管理。
3. 尽量高的命中率。
   这一点是缓存设计的一般性目标。
4. 及时的数据正确性。
   OEA对数据正确性的要求比较高，也就是说，从缓存中获取的数据，必须和数据库中的数据完全保持一致。
5. 精确的数据失效范围控制。
   精确的失效范围控制，可以令更少的数据失效，所以获取的数据更少，网络传输的数据也就更少。
6. 长期硬盘缓存。
   由于支持精确的数据失效范围控制，所以可以把大量数据缓存在客户端硬盘上，常期不失效。这样，客户端在关闭并再次打开后，上次的缓存还能继续使用。
7. “尽量”获取。
   缓存的数据不能影响应用程序的原有正确性，不管硬盘上的数据怎么样，缓存模块只是“尽量”地工作，不会影响调用者逻辑。
8. 服务端/客户端都可以使用。
9. 可在运行时关闭。

概要设计

    整个缓存模块分为两大部分实现：通用缓存框架、OEA集成缓存框架。

通用缓存框架目标：

图1 通用缓存框架目标

    通用缓存框架没有太多特点，预留两个变化点即可：存储位置、更新策略。此处可引入一些成熟缓存框架快速实现。

OEA集成缓存目标

图2 OEA中需要的Cache目标

    OEA集成缓存框架是本次开发的重点，需要兼容原来的实体加载模式，并对实体类开发者透明，更重要的是，满足图中的这些场景。（不熟悉OEA的读者，看了上图可能会比较晕。:)   ）

通用缓存框架详细设计

    由以上目标可知，Cache暂时支持两个扩展点：存储位置和更新策略。如下图：

图3 缓存框架的结构图

图中，用抽象的CacheProvider类来进行存储方式的扩展，用缓存配置类Policy中的ChangeChecker来实现显式的更新检测，并预留此为更新策略扩展点。由于ChangeChecker可能需要保存到数据库中，所以使用了Memoto模式来实现状态的存储。

    我们先来看看目前的CacheProvider：

图4 通用缓存框架中内置的CacheProvider

内部实现了四个CacheProvider：

1. SQLCompactProvider：由于在客户端需要一定的本地缓存，所以这个缓存提供器主要是实现SQLCompact来进行存储。
2. MemcachedProvider：可能会需要使用分布式缓存进行存储。
3. MemoryCacheProvider：这是集成了.NET4.0中System.Runtime.Caching.ObjectCache类的实现。由于MemoryCache不支持Region，所以这里添加了RegionCache类来对MemoryCache进行了一层代理，令其支持分区的缓存。
4. TwoLevelProvider：这是一个使用装饰模式实现的二级缓存。例如，我们可以在客户端使用Memory+SqlCompact来进行二级缓存。

OEA集成Cache详细设计

    不熟悉OEA的读者，可以直接跳过本节。

    在OEA进行Cache集成时，比较复杂的是版本号更新策略的实现。具体内容如下图：

图5 基于数据范围的版本号的更新策略

给数据进行了范围的划分后，我们只需要对需要的范围内的数据进行进项检测就行了。数据范围越大，则数据过期的可能越大，但是检测的次数较少；范围越小，则可能因为检测的次数过多而造成网络访问次数过多，同样不利，所以对于这里面的使用，需要根据使用场景进行权衡。具体的类设计，接下来会给出。

    整个集成的结构，如下图如示：

整个结构中，以EntityCache为中心，分为以下几个部分：

1. VersionChecker，实现范围版本号更新策略，类图如下：
    
2. CacheDefinition包含了CacheScope来进行数据范围的定义。客户程序使用ICacheDeifinitionInitializer进行缓存范围定义。这样，框架内部就能使用定义的数据范围来进行缓存过期控制。
3. EntityCache作为集成点，调用通用框架中的Cache、VersionChecker和CacheDefinition进行缓存方案的组装。
4. EntityRepository中的数据获取方法直接使用EntityCache来尝试先从缓存中获取数据。

结尾

    这样设计的缓存，目前在系统中已经使用了一段时间了，中间出现过几个小问题，不过总体情况还是比较满意的，性能提升较大。

    另外，现在看来，在范围数据的过期设计这一块，较为复杂，不易理解，应该在以后的设计中进行优化。

本文转自BloodyAngel博客园博客，原文链接：http://www.cnblogs.com/zgynhqf/archive/2010/11/29/1891105.html，如需转载请自行联系原作者