使用JCS在Web门户应用中实现对象缓存

使用JCS在Web门户应用中实现对象缓存(1)
使用JCS在Web门户应用中实现对象缓存
在我最近的web门户应用开发工作中，我们需要在Servlet容器（Tomcat）的内存中存储一些查找数据（例如：比率更新数据、状态和产品列表），这样我们不需要在每次访问数据的时候进行数据库查找。

同时，我们也需要定期地刷新存储在内存中的数据以保证其新鲜和准确。

我们也需要一种机制在不同的时间间隔对存储在内存中的不同类型的数据进行刷新。

例如，比率更新数据需要每天刷新一次，而查找类型的数据则可以在内存中保留很长一段时间。

对象缓存是最方便地达到上述所有目的的完美解决方案。

对象缓存
最恰当的对象缓存的定义可以在Object Caching Service for Java (OCS4J)的功能规范文档中找到，它是这样定义的：
服务器必须将信息和可执行对象分为三种基本类别管理：永远不会改变的对象，每次请求都会发生改变的对象，以及在两者之间的对象。

Java对前两种对象的处理提供了很好的支持，但是对第三种类别的支持非常有限。

如果对象永远不改变，我们在服务器初始化的时候创建静态对象。

如果对每个请求对象都是不同的，我们每次都创建新的对象。

对于介于两者之间的对象或信息，它们的状态可能会发生变化，但是又需要提供跨越请求、跨越用户或跨越进程的共享，就要采用“对象缓存服务”了。

基本上，对象缓存就是通过在使用对象后不立即释放，而是存储在内存中并被后来的客户端请求重用，避免重新获得对象的昂贵成本。

当数据第一次从数据源被检索出来后，在名为cache的内存缓冲中临时存放。

同样的数据再次被访问的时候，对象从缓存中取出来，而不是从数据源重新获取。

最后，被缓存的数据在不再需要的时候从内存中释放出来。

从Web应用的观点来看，什么时候指定的对象可以从内存中释放出来取决于定义一个对象变成无效的合理的间隔时间。

缓存的益处
对象缓存最主要的益处就是对应用性能的重大提升。

在一个多层应用中，与其他工作比较，数据访问是一种代价非常高的操作。

通过将频繁被访问的数据By keeping the frequently accessed data around并在第一次使用后不释放，我们可以避免重新获取与释放对象的开销和时间。

这将会大规模提升web应用的性能，因为我们不用在每次获取数据的时候访问数据库了。

可伸缩性是使用对象缓存带来的另一个好处。

因为被缓存的数据可以跨越多个session和web应用访问，对象缓存可以成为可伸缩性Web应用设计的一个重要部分。

采用对象缓存，就像对象池一样，可以帮助避免获取与释放对象的开销。

缓存的不利因素
在web应用中使用对象缓存可以带来很多益处，但是缓存对象同时也会带来一些不利的因素。

∙同步复杂性:复杂性的增长依赖于数据的种类，因为需要保证被缓存数据与数据源中原始数据的一致性。

要不然，被缓存的数据就会与实际数据不一致，将会导致应用中的数据错误。

∙Durability:当服务器崩溃的时候，被缓存数据的修改回丢失。

可以采用同步缓存避免该问题。

∙内存大小:如果有大量没有用处的数据存放在缓存中，并且这些数据没有在正常的时间间隔内被释放，JVM内存大小就会变得无法接受的庞大。

缓存实例
任何不经常变化的、需要花费很长时间从数据源获取的数据都是缓存的最佳选择。

这包括了几乎所有的静态数据、代码和描述列表，以及带有分页功能的查找结果 (搜索结果可以从数据源一次获取出来并存放在缓存中，等待用户在结果页面上点击页数链接时显示)。

中间件技术如EJB和CORBA允许在客户端与服务器之间的远程对象传输。

像这种类型的访问，也被称为粗粒度数据访问,用于降低昂贵的远程方法调用开销。

如果这些数据传输对象 (也被称为值对象)变化不是非常频繁，它们可以被存储在缓存中。

这样可以在每次客户端需要值对象时减少servlet容器访问应用服务器的次数。

那么哪些类型的数据不宜被缓存呢？这里是一些不推荐使用缓存的数据类别：
∙可以被网站上其他用户访问的安全信息。

∙用户描述信息。

∙私人信息，包括社会保险号码或信用卡明细信息。

∙经常变化的，并且不准确或不及时会引发问题的业务信息。

不应该被其它用户访问的特定于Session的数据。

使用JCS在Web门户应用中实现对象缓存(2)
缓存架构
有很多种对象缓存架构（包括开放源代码的和商业的实现）在servlet容器和应用服务器中提供了分布式缓存。

下面列出了一些现在可以使用的缓存框架：
开放源代码项目
∙来自于Jakarta的Java Caching System (JCS) (属于Turbine项目的一部分)
∙OSCache
∙Commons Collections (另一个Jakarta项目)
∙JCache API ()
商业项目
∙SpiritCache (来自于 SpiritSoft).
∙Coherence (Tangosol)
∙Javlin (eXcelon)
∙Object Caching Service for Java (Oracle)
如果你还有兴趣了解更多的缓存实现，本文最后的资源一节提供了所有这些框架的URL。

我在最初开始我对能满足我们所有的缓存需求的框架进行研究的时候，我先看到了Commons Collections和 Java Caching System API。

我在最开始评估的主要标准就是容易使用、容易扩展，以及软件的成本。

这两个框架都是开放源代码的，并且都来自于Apache Jakarta项目。

Commons Collections
Commons Collections API以一个Java类的形式提供了对象缓存算法，名称为LRUMap。

如果你对缓存只有基本的需求，并且不是真正需要很多的扩展和缓存配置功能，那么Commons Collections可能是一个不坏的选择，但不是作为一个企业级缓存系统的正确选择。

如果你选择Common Collections来实现对象缓存，你将会手工定义/配置所有的缓存参数，如：最大缓存对象的数量，一个缓存对象的最长生命周期，刷新缓存或检查对象新鲜的中断时间等。

Java Caching System
Java Caching System (JCS)， Jakarta Turbine项目的一部分，与Commons Collections相比更有成熟、更具扩展性。

通过为频繁访问的对象维护动态对象池的方法，它提供了提升整个系统性能的灵活、可配置的解决方案。

就像在它的网站上提到的，JCS已经超越了简单地在内存中缓存对象的范围。

它为一个企业级的缓存系统提供了许多必需的重要功能：
∙内存管理
∙Disk overflow (和重整)
∙元素分组
∙快速嵌套地移除
∙数据期限管理
∙可扩展的框架
∙完全可配置的运行时参数
∙远程同步
∙远程存储恢复
∙通过HTTP、TCP或者UDP协议实现可选的横向分布元素。

JCS提供了无故障点的框架，允许完全的session失败转移（在集群环境中），包括支持最多到256个服务器的session数据分布。

它也提供了配置一个或多个数据存储选项的灵活性，例如：内存缓存、磁盘缓存，或者在远程机器上的缓存。

所有这些包括在JCS中的优秀功能让它成为满足我们的web门户项目的一个优秀的对象缓存产品选择
使用JCS构造Web门户缓存框架
缓存框架的目标
在我开始设计对象缓存框架之前，我首先列出了在新的框架中需要达到的目标。

以下就是目标的列表：
∙在web门户应用中快速访问频繁使用的数据。

∙将缓存中类型类似的对象进行组合。

∙提供可配置的缓存管理，以便我可以通过描述方式而不是编码方式修改参数。

∙提供可靠的和可扩展的框架，以便我将来可以转换到其它第三方的缓存API。

∙可以生成统计数据来监测缓存的效率，以及使用数据缓存后应用性能的提升效果。

安装和配置
在web应用中安装和配置JCS是非常简单的事情。

从Jakarta Turbine网站下载压缩文件，解压缩文件到临时目录，并拷贝JSC.jar文件（jcs-1.0-dev.jar）到servlet容器的通用目录（在我的web应用中使用的servlet容器是Tomcat，通用目录在windows下就是%TOMCAT_HOME%\common\lib，在再Unix类型的系统下就是$TOMCAT_HOME/common/lib）。

你可能还需要
commons-collections.jar, commons-lang.jar,和commons-logging.jar这些文件存在于web应用的类路径下以便使用JCS。

对象缓存框架的主要原理在图1和图2的UML图中展示出来了
图1
图2
使用JCS在Web门户应用中实现对象缓存(3)
框架的主要原理
缓存属性
我们将所有的缓存参数配置在名为f的属性文件中。

这些参数包括缓存信息如：内存中存储的对象的最大数量，缓存时间（过了时间之后缓存的数据九自动从内存中释放），中断时间（elapsed time since last access time），内存缓存名称（例如：缓存算法如LRU或MRU）等。

在当前版本的JCS中，缓存属性文件是纯文本格式的。

SpiritCache framework，一种来自SpiritSoft的Jcache API商业实现，支持XML格式的缓存配置。

确认该属性文件存放在类路径中。

注意：如果你需要使用其它不同的文件来存放缓存属性的话，JCS也提供了方法来指定一个配置文件的名称。

请参考JCS的Javadocs学习如何从其它非缺省的属性文件中读取缓存配置信息。

下面列出来的是web应用使用缓存功能需要了解的一些Java类。

这些类存放在本文的示例代码的common.caching包中。

这些类的Javadocs也包括在源代码压缩包中。

（图2中的类图显示了这些Java类的关系）
ICacheManager
这是客户应用实现所有缓存有关操作（如：存储、访问以及释放缓存中的数据）的主接口（契约）。

客户程序可以是JSP、Struts Action类，或者就是一个POJO 对象。

创建该接口用于对客户端隐藏所有缓存的实现细节，这样当我们将来需要切换另一种的第三方缓存API的时候无需对客户端代码做任何调整。

BaseCacheManager
这是web门户缓存框架的主类。

是对ICacheManager接口的最基本实现。

创建BaseCacheManager用于在一个类中集中所有缓存相关的方法。

它被设计为单例模式保证在servlet容器的JVM中有且仅有一个ICacheManager的实例被创建。

在多web服务器/servlet容器实例共同处理web请求的集群环境中，每个JVM将会创建独立的ICacheManager实例。

如果将来你要转换到不同的
缓存API，这是唯一需要为新的缓存API修改的类。

如果你切换到JCache-兼容的缓存实现，对缓存管理器的修改将会是很小的。

ICacheLoader
该接口用于在web客户端实现真正的数据访问逻辑。

所有需要使用缓存机制的客户端应用必须实现该接口。

它包括仅有的一个方法叫做
loadCacheObject()，有两个输入参数：一个String参数制定缓存区域名称，一个对象参数制定缓存键值。

这样，缓存管理器将知道在缓存的对象超过指定的“生存时间”的时候，使用哪个客户端程序（运行loadCacheObject方法）来重载缓存中的对象。

ICacheKey
ICacheKey接口创建的目的是为了隐藏特定的创建缓存键值的细节。

有时候缓存的键值不是一个简单的字符串。

它可能像多个对象组合起来一样复杂，从数据源获取这些值需要多个查找方法而不是单一的方法。

在这种情况下，ICacheKey 接口可以被用来定义创建缓存键值的所有复杂的逻辑。

这样，缓存键值创建逻辑将会被定义为独立的类。

我编写了一个简单的类TestCacheKey实现了该接口并实现了getCacheKey()方法来演示使用该接口的方法。

CacheRegion s
一个缓存区域被定义为一个组织起来的命名空间用于容纳一组缓存对象集合。

你需要在配置文件中定义缓存区域来实现在一块单独的内存空间中存储数据，管理缓存数据的有效期限。

如果需要的话，对有相似特征的对象（例如：生存时间和业务用途）应该被缓存在相同的缓存区域中，让它们可以在相同的时间失效。

我定义了分离的缓存区域来存储静态数据和小变动数据。

为了避免同步操作带来的效率影响，我对每个缓存区域使用了单独的Cache(JCS)实例。

CacheElementInfo
该类用于封装所有的缓存统计信息（例如：命中数、不中数、命中比例等），用来监测在web应用中所有缓存对象的效率。

编译,构建,和单元测试
我用Ant创建了一个构建脚本来编译我的对象缓存框架的所有代码。

Ant的构建脚本build.xml,放在WEB-INF\classes目录下。

我还编写了Junit测试客户端来测试使用web门户缓存框架的不同缓存场景。

测试脚本CachingTestCase,放在WEB-INF\classes\common\caching\test目录下。

解压缩示例代码到一个新的web应用目录，如果要验证Junit测试脚本，从命令行运行以下命令：
切换当前目录到%TOMCAT_HOME%/webapps/web-app-name/WEB-INF/classes（在Unix测试环境中，目录应该是
$TOMCAT_HOME/webapps/web-app-name/WEB-INF/classes）。

运行以下命令：
∙ant pile编译缓存框架中所有的Java类。

∙ant common.runjunit用于运行Junit测试脚本。

测试脚本使用Log4J API来显示所有的输出信息。

考虑何时使用对象缓存的指导方针
当你决定要在你的web应用中缓存一些特定类别的数据的时候，请参照这些指导方针。

缓存的应用应该经过谨慎地考虑，只有当其它方法，如：数据访问等，已经无法再进一步改进的时候才需要使用缓存。

缓存将会带来复杂性，让维护工作变得更加复杂。

因此，必须统筹考虑性能和缓存带来的复杂性的平衡关系。

当考虑使用缓存的时候，需要考虑对象的预定执行时间和刷新率或者叫做对象的生存时间。

缓存不能容纳所有我们想要存储的数据，因此缓存使用的内存及时得到释放，即可以通过定义合理的生存时间实现，也可以在数据不再需要的时候显式地释放被缓存的对象。

可以指定缓存算法如最近被访问算法（LRU）或者最少被使用算法（LFU）以便缓存基于访问频率来释放对象。

Jack Shirazi的著作 Java 性能调整提供了一个关于缓存主题的非常有趣的讨论，讨论了什么类型的数据应该被缓存，以及何时使用缓存的建议。

注意缓存框架并没有处理在web应用中需要被缓存的对象的创建（例如：从数据源检索数据的数据访问逻辑并没有在缓存类中编写）。

这要依赖于客户程序来定义真正的数据访问逻辑。

像Java数据对象等技术通常用于在企业级web应用中
封装数据访问逻辑。

参考O'Reilly的 Java 数据对象来学习更多的关于如何将数据访问层与业务逻辑层分离的知识。

结论
本文提供了对使用Jakarta的Java缓存系统（JCS）来为web门户应用开发对象缓存框架的概要介绍。

该框架非常稳定并可以被重用于其它任何web应用，甚至可以用于客户/服务器模式的Java应用程序。

本文详细介绍了web门户缓存框架的工作原理，并提供了Junit测试脚本来对不同场景的缓存框架进行测试。

JCS was built as a system close to JCACHE Java Temporary Caching API (JSR-107), a description of the caching system used in Oracle 9i and other popular caching frameworks.该规范可能会在将来的JDK发行版本中作为一种Java扩展框架。

我的其中一个目的就是让web门户缓存框架与JCS保持松散耦合。

这样的话，如果我将来需要转换到另一种框架（例如Jcache），我可以在对web门户应用客户程序代码不做大的调整的情况下完成切换。

我现在通过记录缓存监测信息的日志（使用Log4J API）如：命中数、不中数、命中率来衡量缓存的效率。

可能将来有其它参数需要被监测来衡量缓存的效率。

同样的，用来测量使用或不使用缓存对数据访问的反馈时间，应该使用一些负载测试工具如：Grinder或者Jmeter来测试其伸缩性和性能效果。

在机群环境下保持缓存同步将是一个挑战，因为每个servlet容器将会在自己的JVM中拥有一个缓存管理器实例。

解决该问题的方法就是创建消息驱动Bean （MDB）在需要刷新数据的时候通知所有的缓存管理器。

通常的对象查找方法，如：简单的Hashtable、JNDI甚至是EJB，提供了在内存中存放对象并通过键值查找对象的方法。

但是任何一种方法都没有提供当对象不需要的时候从内存中移出的机制，或者当访问对象迟于对象存放期限的时候自动创建对象的机制。

HttpSession对象 (in the servlet package)也允许对象被缓存，但是它没有共享、失效、单一对象存放期满、自动装载或者spooling 这些缓存框架需要具备的基础机制。

虽然将缓存功能集成到web应用中需要额外的设计和开发工作，但我认为缓存带来的利益大于额外付出的工作。

我已经看到在我实现了缓存框架之后，我的web 应用的性能有很大的提高，特别是在访问静态数据和查找结果方面。

该web应用
模块目前处于测试阶段。

在不久的将来，我会提供一些性能方面的测试数据（包括使用与不使用缓存的情况）来比较缓存如何帮助设计更快、更具伸缩性的web 应用。