概述
项目组目前开发的基于OEA框架的GIX4项目,本次功能已经完成得差不多了,本次迭代的目标主要是提升产品的性能。由于GIX4是C/S结构的应用程序,所以决定实现缓存模块来提升高繁数据访问的缓存。
本篇文章主要介绍了OEA框架中的缓存模块设计与一般的缓存有什么不同,如何在OEA框架中实现缓存模块。分为以下几个小节:
- 一般缓存介绍
- OEA缓存目标
- 概要设计
- 通用缓存框架的详细设计
- OEA中集成Cache的详细设计
- 小结
一般缓存介绍
网上介绍缓存的文章比较多,在这里我就挑点重点说一下。
缓存是信息系统软件硬件设计中常用的设计方法:从底层硬件的CPU结构中的多级缓存,到软件中操作系统中内存管理的设计,再到应用软件中的高繁数据的缓存设计;在代码设计方面,小到一个冗余变量的设计,大到分布式缓存的设计;都可以见到缓存设计的身影。
缓存设计的目的是临时存储需要大量时间进行计算的结果,是一种空间换时间的思想。
缓存设计中的最重要的变化点是:更新策略(过期策略)。常见的更新策略有:实时检测、心跳检测、缓存依赖检测、绝对时间过期、滑动时间过期等。当然,在应用程序设计中,一个通用的缓存框架,缓存的具体位置也是一个常用的变化点,如:内存、文件、数据库、网络、云。在具体设计中,需要注意这两个变化点。
OEA缓存目标
以下列举了OEA缓存模块中目前需要支持的一些目标:
- 支持DDD领域模型设计。
OEA框架是基于领域驱动的特定领域的产品线架构框架。它是面向领域模型的,而领域模型是DDD中所描述的富领域模型、聚合对象,缓存框架需要支持这样的实体设计方式。目前,有两类实体最需要使用缓存:高繁使用的聚合根对象、一般的“外键”引用对象。 - 对类库开发者透明。
OEA框架的所有设计围绕实体类进行,开发者最多接触的就是实体类的开发。在实体类及其存储机制的开发过程中,完全不需要考虑缓存机制,而是应该在实体类开发完毕后,在应用程序初始化代码处,使用简单的API定义哪些类需要缓存、如何缓存,OEA框架完成所有的缓存的管理。 - 尽量高的命中率。
这一点是缓存设计的一般性目标。 - 及时的数据正确性。
OEA对数据正确性的要求比较高,也就是说,从缓存中获取的数据,必须和数据库中的数据完全保持一致。 - 精确的数据失效范围控制。
精确的失效范围控制,可以令更少的数据失效,所以获取的数据更少,网络传输的数据也就更少。 - 长期硬盘缓存。
由于支持精确的数据失效范围控制,所以可以把大量数据缓存在客户端硬盘上,常期不失效。这样,客户端在关闭并再次打开后,上次的缓存还能继续使用。 - “尽量”获取。
缓存的数据不能影响应用程序的原有正确性,不管硬盘上的数据怎么样,缓存模块只是“尽量”地工作,不会影响调用者逻辑。 - 服务端/客户端都可以使用。
- 可在运行时关闭。
概要设计
整个缓存模块分为两大部分实现:通用缓存框架、OEA集成缓存框架。
通用缓存框架目标:
图1 通用缓存框架目标
通用缓存框架没有太多特点,预留两个变化点即可:存储位置、更新策略。此处可引入一些成熟缓存框架快速实现。
OEA集成缓存目标
图2 OEA中需要的Cache目标
OEA集成缓存框架是本次开发的重点,需要兼容原来的实体加载模式,并对实体类开发者透明,更重要的是,满足图中的这些场景。(不熟悉OEA的读者,看了上图可能会比较晕。:) )
通用缓存框架详细设计
由以上目标可知,Cache暂时支持两个扩展点:存储位置和更新策略。如下图:
图3 缓存框架的结构图
图中,用抽象的CacheProvider类来进行存储方式的扩展,用缓存配置类Policy中的ChangeChecker来实现显式的更新检测,并预留此为更新策略扩展点。由于ChangeChecker可能需要保存到数据库中,所以使用了Memoto模式来实现状态的存储。
我们先来看看目前的CacheProvider:
图4 通用缓存框架中内置的CacheProvider
内部实现了四个CacheProvider:
- SQLCompactProvider:由于在客户端需要一定的本地缓存,所以这个缓存提供器主要是实现SQLCompact来进行存储。
- MemcachedProvider:可能会需要使用分布式缓存进行存储。
- MemoryCacheProvider:这是集成了.NET4.0中System.Runtime.Caching.ObjectCache类的实现。由于MemoryCache不支持Region,所以这里添加了RegionCache类来对MemoryCache进行了一层代理,令其支持分区的缓存。
- TwoLevelProvider:这是一个使用装饰模式实现的二级缓存。例如,我们可以在客户端使用Memory+SqlCompact来进行二级缓存。
OEA集成Cache详细设计
不熟悉OEA的读者,可以直接跳过本节。
在OEA进行Cache集成时,比较复杂的是版本号更新策略的实现。具体内容如下图:
图5 基于数据范围的版本号的更新策略
给数据进行了范围的划分后,我们只需要对需要的范围内的数据进行进项检测就行了。数据范围越大,则数据过期的可能越大,但是检测的次数较少;范围越小,则可能因为检测的次数过多而造成网络访问次数过多,同样不利,所以对于这里面的使用,需要根据使用场景进行权衡。具体的类设计,接下来会给出。
整个集成的结构,如下图如示:
整个结构中,以EntityCache为中心,分为以下几个部分:
- VersionChecker,实现范围版本号更新策略,类图如下:
- CacheDefinition包含了CacheScope来进行数据范围的定义。客户程序使用ICacheDeifinitionInitializer进行缓存范围定义。这样,框架内部就能使用定义的数据范围来进行缓存过期控制。
- EntityCache作为集成点,调用通用框架中的Cache、VersionChecker和CacheDefinition进行缓存方案的组装。
- EntityRepository中的数据获取方法直接使用EntityCache来尝试先从缓存中获取数据。
结尾
这样设计的缓存,目前在系统中已经使用了一段时间了,中间出现过几个小问题,不过总体情况还是比较满意的,性能提升较大。
另外,现在看来,在范围数据的过期设计这一块,较为复杂,不易理解,应该在以后的设计中进行优化。
最后
以上就是单纯向日葵为你收集整理的OEA中的缓存模块设计的全部内容,希望文章能够帮你解决OEA中的缓存模块设计所遇到的程序开发问题。
如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。
发表评论 取消回复