Ehcache页面缓存的使用

关于缓存的话题,在坛子里已经有很多讨论,简单的来说,如果一个应用中80% 的时间内都在访问20% 的数据,那么,这时候就应该使用缓存了。这个和长尾理论正好相悖,其实也不是相悖,只是不同的理论使用的场景不同。在80/20 原则生效的地方,我们都应该考虑是否可以使用缓存。但即使是这样,缓存也有不同的用法,举个例子,一个网站的首页估计是被访问的次数最多的,我们可以考虑给首页做一个页面缓存,而如果在某个页面上,比如说javaeye 的java 版区只有前几个页面是访问最频繁的,(假设javaeye 是使用hibernate ,当然这只是假设,我们都知道javaeye 是使用ror 开发的)那么我们就可以考虑给java 版区的record 做二级缓存了,因为二级缓存中是按照对象的id 来保存的,所以应该来说这前面几页使用的对象会一直存在于缓存之中(如何使用hibernate 的二级缓存坛子上也有介绍)。由此可见不同的页面的缓存策略有可能有天壤之别。

本文的目的就是上面所讲的两种情况之一,页面缓存。毫无疑问,几乎所有的网站的首页都是访问率最高的,而首页上的数据来源又是非常广泛的,大多数来自不同的对象,而且有可能来自不同的db ,所以给首页做缓存是一个不错的主意,那么主页的缓存策略是什么样子的呢,我认为应该是某个固定时间之内不变的,比如说2 分钟更新一次。那么这个缓存应该做在什么地方呢,让我们来看一下,假设您的应用的结构是page-filter-action-service-dao-db ,这个过程中的- 的地方都是可以做缓存的地方,根据页面缓存的特征,应该把页面缓存做到尽量靠近客户的地方,就是在page 和filter 之间,这样的优点就是第一个用户请求之后,页面被缓存,第二个用户再来请求的时候,走到filter 这个请求就结束了,无需再走后面的action-service-dao-db 。带来的好处是服务器压力的减低和客户段页面响应速度的加快。

 

那么我们来看一下如何使用ehcache 做到这一点。

 

在使用ehcache 的页面缓存之前,我们必须要了解ehcache 的几个概念,

1 timeToIdleSeconds ,多长时间不访问该缓存,那么ehcache 就会清除该缓存。

2 timeToLiveSeconds ,缓存的存活时间,从开始创建的时间算起。

 

看到这里,我们知道,首页的页面缓存的存活时间,我们定的是2 分钟,那么也就是说我们的timeToLiveSeconds 应该设置为120 ,同时我们的timeToIdleSeconds 最好也设置为2 分钟,或者小于2 分钟。我们来看一下下面这个配置,这个配置片段应该放到ehcache.xml 中:

 

< cache name = "SimplePageCachingFilter"

           maxElementsInMemory = "10"

           maxElementsOnDisk = "10"

           eternal = "false"

            overflowToDisk = "true"

           diskSpoolBufferSizeMB = "20"

           timeToIdleSeconds = "10"

           timeToLiveSeconds = "10"

           memoryStoreEvictionPolicy = "LFU"

            />

 

SimplePageCachingFilter 是缓存的名字,maxElementsInMemory 表示内存中SimplePageCachingFilter 缓存中元素的最大数量为10 ,maxElementsOnDisk 是指持久化该缓存的元素到硬盘上的最大数量也为10 (),eternal=false 意味着该缓存会死亡。overflowToDisk=true 意思是表示当缓存中元素的数量超过限制时,就把这些元素持久化到硬盘,如果overflowToDisk 是false ,那么maxElementsOnDisk 的设置就没有什么意义了。memoryStoreEvictionPolicy=LFU 是指按照缓存的hit 值来清除,也就是说缓存满了之后,新的对象需要缓存时,将会将缓存中hit 值最小的对象清除出缓存,给新的对象腾出地方来了(文章最后有ehcache 中自带的3 种缓存清空策略的介绍)。

 

接着我们来看一下SimplePageCachingFilter 的配置,

< filter >

        < filter-name > indexCacheFilter filter-name >

        < filter-class >

            net.sf.ehcache.constructs.web.filter.SimplePageCachingFilter

        filter-class >

filter >

 

    < filter-mapping >

        < filter-name > indexCacheFilter filter-name >

        < url-pattern > *index.action url-pattern >

filter-mapping >

就只需要这么多步骤,我们就可以给某个页面做一个缓存的,把上面这段配置放到你的web.xml 中,那么当你打开首页的时候,你会发现,2 分钟才会有一堆sql 语句出现在控制台上。当然你也可以调成5 分钟,总之一切都在控制中。

 

好了,缓存整个页面看上去是非常的简单,甚至都不需要写一行代码,只需要几行配置就行了,够简单吧,虽然看上去简单,但是事实上内部实现却不简单哦,有兴趣的话,大家可以看看SimplePageCachingFilter 继承体系的源代码。

 

上面的配置针对的情况是缓存首页的全部,如果你只想缓存首页的部分内容时,你需要使用SimplePageFragmentCachingFilter 这个filter 。我们看一下如下片断:

 

< filter >

        < filter-name > indexCacheFilter filter-name >

        < filter-class >

            net.sf.ehcache.constructs.web.filter.SimplePageFragmentCachingFilter

        filter-class >

filter >

 

    < filter-mapping >

        < filter-name > indexCacheFilter filter-name >

        < url-pattern > */index_right.jsp url-pattern >

filter-mapping >

 

这个jsp 需要被jsp:include 到其他页面,这样就做到的局部页面的缓存。这一点貌似没有oscache 的tag 好用。

 

事实上在cachefilter 中还有一个特性,就是gzip ,也就是说缓存中的元素是被压缩过的,如果客户浏览器支持压缩的话,filter 会直接返回压缩过的流,这样节省了带宽,把解压的工作交给了客户浏览器,如果客户的浏览器不支持gzip ,那么filter 会把缓存的元素拿出来解压后再返回给客户浏览器(大多数爬虫是不支持gzip 的,所以filter 也会解压后再返回流),这样做的优点是节省带宽,缺点就是增加了客户浏览器的负担(但是我觉得对当代的计算机而言,这个负担微乎其微)。

 

好了,如果你的页面正好也需要用到页面缓存,不防可以考虑一下ehcache ,因为它实在是非常简单,而且易用。

 

总结:ehcache 是一个非常轻量级的缓存实现,而且从1.2 之后就支持了集群,目前的最新版本是1.3 ,而且是hibernate 默认的缓存provider 。虽然本文是介绍的是ehcache 对页面缓存的支持,但是ehcache 的功能远不止如此,当然要使用好缓存,对JEE 中缓存的原理,使用范围,适用场景等等都需要有比较深刻的理解,这样才能用好缓存,用对缓存。

 

最后复习一下ehcache 中缓存的3 种清空策略:

1 FIFO ,first in first out ,这个是大家最熟的,先进先出,不多讲了

2 LFU , Less Frequently Used ,就是上面例子中使用的策略,直白一点就是讲一直以来最少被使用的。如上面所讲,缓存的元素有一个hit 属性,hit 值最小的将会被清出缓存。

2 LRU ,Least Recently Used ,最近最少使用的,缓存的元素有一个时间戳,当缓存容量满了,而又需要腾出地方来缓存新的元素的时候,那么现有缓存元素中时间戳离当前时间最远的元素将被清出缓存。

标题基于SpringBoot+Vue的学生交流互助平台研究AI更换标题第1章引言介绍学生交流互助平台的研究背景、意义、现状、方法与创新点。1.1研究背景与意义分析学生交流互助平台在当前教育环境下的需求及其重要性。1.2国内外研究现状综述国内外在学生交流互助平台方面的研究进展与实践应用。1.3研究方法与创新点概述本研究采用的方法论、技术路线及预期的创新成果。第2章相关理论阐述SpringBoot与Vue框架的理论基础及在学生交流互助平台中的应用。2.1SpringBoot框架概述介绍SpringBoot框架的核心思想、特点及优势。2.2Vue框架概述阐述Vue框架的基本原理、组件化开发思想及与前端的交互机制。2.3SpringBoot与Vue的整合应用探讨SpringBoot与Vue在学生交流互助平台中的整合方式及优势。第3章平台需求分析深入分析学生交流互助平台的功能需求、非功能需求及用户体验要求。3.1功能需求分析详细阐述平台的各项功能需求,如用户管理、信息交流、互助学习等。3.2非功能需求分析对平台的性能、安全性、可扩展性等非功能需求进行分析。3.3用户体验要求从用户角度出发,提出平台在易用性、美观性等方面的要求。第4章平台设计与实现具体描述学生交流互助平台的架构设计、功能实现及前后端交互细节。4.1平台架构设计给出平台的整体架构设计,包括前后端分离、微服务架构等思想的应用。4.2功能模块实现详细阐述各个功能模块的实现过程,如用户登录注册、信息发布与查看、在线交流等。4.3前后端交互细节介绍前后端数据交互的方式、接口设计及数据传输过程中的安全问题。第5章平台测试与优化对平台进行全面的测试,发现并解决潜在问题,同时进行优化以提高性能。5.1测试环境与方案介绍测试环境的搭建及所采用的测试方案,包括单元测试、集成测试等。5.2测试结果分析对测试结果进行详细分析,找出问题的根源并
内容概要:本文详细介绍了一个基于灰狼优化算法(GWO)优化的卷积双向长短期记忆神经网络(CNN-BiLSTM)融合注意力机制的多变量多步时间序列预测项目。该项目旨在解决传统时序预测方法难以捕捉非线性、复杂时序依赖关系的问题,通过融合CNN的空间特征提取、BiLSTM的时序建模能力及注意力机制的动态权重调节能力,实现对多变量多步时间序列的精准预测。项目不仅涵盖了数据预处理、模型构建与训练、性能评估,还包括了GUI界面的设计与实现。此外,文章还讨论了模型的部署、应用领域及其未来改进方向。 适合人群:具备一定编程基础,特别是对深度学习、时间序列预测及优化算法有一定了解的研发人员和数据科学家。 使用场景及目标:①用于智能电网负荷预测、金融市场多资产价格预测、环境气象多参数预报、智能制造设备状态监测与预测维护、交通流量预测与智慧交通管理、医疗健康多指标预测等领域;②提升多变量多步时间序列预测精度,优化资源调度和风险管控;③实现自动化超参数优化,降低人工调参成本,提高模型训练效率;④增强模型对复杂时序数据特征的学习能力,促进智能决策支持应用。 阅读建议:此资源不仅提供了详细的代码实现和模型架构解析,还深入探讨了模型优化和实际应用中的挑战与解决方案。因此,在学习过程中,建议结合理论与实践,逐步理解各个模块的功能和实现细节,并尝试在自己的项目中应用这些技术和方法。同时,注意数据预处理的重要性,合理设置模型参数与网络结构,控制多步预测误差传播,防范过拟合,规划计算资源与训练时间,关注模型的可解释性和透明度,以及持续更新与迭代模型,以适应数据分布的变化。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值