第一条可以使用 jeuery autocomplete实现
第二条下拉框中直接绑定数据
<select name="xxx"> <c:forEach items="${list}" var="item"> <option value="${itemxxx}">${itemxxx}</option> </c:forEach></select>
在ehcachexml文件中配置查询缓存参数,ehcachexml文件配置如下:
<ehcache>
<!-- diskStore元素,配置一个目录,这个目录用来存放数据,
也就是说,如果EhCache需要把数据写入磁盘,将会写到这个目录下 -->
<diskStore path="javaiotmpdir"/>
<defaultCache
maxElementsInMemory="10000"
eternal="false"
overflowToDisk="true"
timeToIdleSeconds="120"
timeToLiveSeconds="120"
diskPersistent="false"
diskExpiryThreadIntervalSeconds="120"/>
<cache name="ehcacheName"
maxElementsInMemory="3000"
eternal="false"
timeToIdleSeconds="3600"
timeToLiveSeconds="36000"
overflowToDisk="true"
/>
</ehcache>
2 spring的配置
第一步:给指定方法配置缓存/src/main/resources/applicationContext-resourcesxml
<ehcache:proxy id="userGroupServiceProxy" refId="userGroupService" ><ehcache:caching cacheName="cash15Min" methodName="selectuserGroupWithDetailByMemberId" />
<ehcache:caching cacheName="cash15Min" methodName="selectuserGroupWithDetailByGroupId" />
<ehcache:caching cacheName="cash15Min" methodName="selectuserGroupById" />
</ehcache:proxy>
配置参数的含义如下:
id:唯一标识符
refId:需要配置缓存的service或者controller
cacheName:缓存名称
methodName:需要缓存的方法,这个方法必须是shoppingHomeService中的方法
第二步:在控制器中注入依赖的缓存userGroupServiceProxy /src/main/webapp/WEB-INF/dispatcher-servletxml
<bean id="PFController" class="comjavamallcontrollerPFController"><property name="userService" ref="userService"></property>
<property name="userGroupService" ref="userGroupServiceProxy"></property>
</bean>
同时需要在实体类中注入依赖,提供setter方法,
private userGroupService userGroupService;public void setuserGroupService(userGroupService userGroupService) {
thisuserGroupService = userGroupService;
}
1 缓存击穿
缓存击穿是指一个请求要访问的数据,缓存中没有,但数据库中有的情况。这种情况一般都是缓存过期了。
但是这时由于并发访问这个缓存的用户特别多,这是一个热点 key,这么多用户的请求同时过来,在缓存里面没有取到数据,所以又同时去访问数据库取数据,引起数据库流量激增,压力瞬间增大,直接崩溃给你看。
所以一个数据有缓存,每次请求都从缓存中快速的返回了数据,但是某个时间点缓存失效了,某个请求在缓存中没有请求到数据,这时候我们就说这个请求就"击穿"了缓存。
针对这个场景,对应的解决方案一般来说有三种。
借助Redis setNX命令设置一个标志位就行。设置成功的放行,设置失败的就轮询等待。就是在更新缓存时加把锁
后台开一个定时任务,专门主动更新过期数据
比如程序中设置 why 这个热点 key 的时候,同时设置了过期时间为 10 分钟,那后台程序在第 8 分钟的时候,会去数据库查询数据并重新放到缓存中,同时再次设置缓存为 10 分钟。
其实上面的后台续命思想的最终体现是也是永不过期。
只是后台续命的思想,会主动更新缓存,适用于缓存会变的场景。会出现缓存不一致的情况,取决于你的业务场景能接受多长时间的缓存不一致。
2 缓存穿透
缓存穿透是指一个请求要访问的数据,缓存和数据库中都没有,而用户短时间、高密度的发起这样的请求,每次都打到数据库服务上,给数据库造成了压力。一般来说这样的请求属于恶意请求。
解决方案有两种:
就是在数据库即使没有查询到数据,我们也把这次请求当做 key 缓存起来,value 可以是 NULL。下次同样请求就会命中这个 NULL,缓存层就处理了这个请求,不会对数据库产生压力。这样实现起来简单,开发成本很低。
3 缓存雪崩
缓存雪崩是指缓存中大多数的数据在同一时间到达过期时间,而查询数据量巨大,这时候,又是缓存中没有,数据库中有的情况了。
防止雪崩的方案简单来说就是错峰过期。
在设置 key 过期时间的时候,在加上一个短的随机过期时间,这样就能避免大量缓存在同一时间过期,引起的缓存雪崩。
如果发了雪崩,我们可以有服务降级、熔断、限流手段来拒绝一些请求,保证服务的正常。但是,这些对用户体验是有一定影响的。
4 Redis 高可用架构
Redis 高可用架构,大家基本上都能想到主从、哨兵、集群这三种模式。
哨兵模式:
它主要执行三种类型的任务:
哨兵其实也是一个分布式系统,我们可以运行多个哨兵。
然后这些哨兵之间需要相互通气,交流信息,通过投票来决定是否执行自动故障迁移,以及选择哪个从服务器作为新的主服务器。
哨兵之间采用的协议是 gossip,是一种去中心化的协议,达成的是最终一致性。
选举规则:
我们都知道 MySQL 的 Table Cache 是表定义的缓存,江湖上流传着各种对这个参数的调优方法。
table cache 的作用,就是节约读取表结构文件的开销。对于table cache 是否命中,其实table cache 是针对于线程的,每个线程有自己的缓存,只缓存本线程的表结构定义。不过我们发现,strace 中没有关于表结构文件的 open *** 作(只有 stat *** 作,定位表结构文件是否存在),也就是说 table cache 不命中,不一定需要读取表结构文件。这种感觉好像是:在不命中 table cache 时,命中了另外一个表结构缓存。
运维建议:
我们读一下 MySQL 的文档,关于 table_open_cache 的建议值公式:建议值 = 最大并发数 join 语句涉及的表的最大个数。
通过实验我们容易理解:table_cache 是针对于线程的,所以需要最大并发数个缓存。另外,一个语句 join 涉及的表,需要同时在缓存中存在。所以最小的缓存大小,等于语句 join 涉及的表的最大个数。将这两个数相乘,就得到了 MySQL 的建议值公式。
缓冲存储器是一种高速且临时地存储数据的设备,它用于提升计算机系统的性能。其主要作用是通过缓存在高速缓冲存储器中的数据,减少CPU或其他核心器件访问慢速存储器(例如硬盘或闪存)的次数,提高内存访问速度和系统整体性能。
在现代计算机中,许多系统都配置了缓冲存储器。缓冲存储器应用的情境和领域非常广泛,涉及到许多应用场景和领域,具体包括但不限于以下几种情况:
计算密集型应用:缓冲可用于一些计算密集型算法,例如图像处理、视频编辑等。这些应用通常需要大量的数据来进行计算,缓存可以提升读写速度,降低整个应用的响应时间。
数据库:在数据库系统中,缓存常用于减少系统访问硬盘的次数。通过将常用的数据存储在缓存中,可以大大减少系统读写硬盘的频率,提升系统的性能和响应速度。
网络应用:缓存在Web服务器、CDN等网络应用中具有重要的作用。对于一些静态资源,如、CSS和JavaScript文件等,这些文件可以预先缓存到本地,缩短了请求时间,降低了带宽无效消耗。
总之,缓冲存储器可以为一些需要快速访问大量数据的应用提供帮助。但注意,在某些超低延迟的领域,如高频交易等,缓存有时可能会导致一些普遍的问题,如缓存命中率低、快取污染、数据不一致等等。
无论大型或小型应用,灵活的缓存可以说不仅大大减轻了服务器的压力,而且因为更快速的用户体验而方便了用户。
Android的apk可以说是作为小型应用,其中99%的应用并不是需要实时更新的,而且诟病于蜗牛般的移动网速,与服务器的数据交互是能少则少,这样用户体验才更好,这也是我们有时舍弃webview而采用json传输数据的原因之一。
采用缓存,可以进一步大大缓解数据交互的压力,特此,我们简略列举一下缓存管理的适用环境:
1 提供网络服务的应用
2 数据更新不需要实时更新,但是哪怕是3-5分钟的延迟也是可以采用缓存机制。
3 缓存的过期时间是可以接受的(不会因为缓存带来的好处,导致某些数据因为更新不及时而影响产品的形象等)
带来的好处:
1 服务器的压力大大减小
2 客户端的响应速度大大变快(用户体验)
3 客户端的数据加载出错情况大大较少,大大提高了应有的稳定性(用户体验)
4 一定程度上可以支持离线浏览(或者说为离线浏览提供了技术支持)
一、缓存管理的方法
这里的缓存管理的原理很简:通过时间的设置来判断是否读取缓存还是重新下载。
里面会有一些细节的处理,后面会详细阐述。
基于这个原理,目前鄙人见过的两种比较常见的缓存管理方法是:数据库法和文件法。
二、数据库法缓存管理
这种方法是在下载完数据文件后,把文件的相关信息如url,路经,下载时间,过期时间等存放到数据库,下次下载的时候根据url先从数据库中查询,如果查询到当前时间并未过期,就根据路径读取本地文件,从而实现缓存的效果。
从实现上我们可以看到这种方法可以灵活存放文件的属性,进而提供了很大的扩展性,可以为其它的功能提供一定的支持;
从 *** 作上需要创建数据库,每次查询数据库,如果过期还需要更新数据库,清理缓存的时候还需要删除数据库数据,稍显麻烦,而数据库 *** 作不当又容易出现一系列的性能,ANR问题,实现的时候要谨慎,具体作的话,但也只是增加一个工具类或方法的事情。
还有一个问题,缓存的数据库是存放在/data/data/<package>/databases/目录下,是占用内存空间的,如果缓存累计,容易浪费内存,需要及时清理缓存。
当然这种方法从目前一些应用的实用上看,我没有发现什么问题。
本文我侧重强调第二种方法,第一种方法的实现,就此掠过。
三、文件法缓存管理
这种方法,使用FilelastModified()方法得到文件的最后修改时间,与当前时间判断是否过期,从而实现缓存效果。
实现上只能使用这一个属性,没有为其它的功能提供技术支持的可能。
*** 作上倒是简单,比较时间即可。本身处理也不容易带来其它问题,代价低廉。
四、文件法缓存管理的两点说明
1 不同类型的文件的缓存时间不一样。
笼统的说,不变文件的缓存时间是永久,变化文件的缓存时间是最大忍受不变时间。
说白点,文件内容是不变的,直到清理,我们是可以永远读取缓存的。
配置文件内容是可能更新的,需要设置一个可接受的缓存时间。
2 不同环境下的缓存时间标准不一样。
无网络环境下,我们只能读取缓存文件,哪怕缓存早就过期。
WiFi网络环境下,缓存时间可以设置短一点,一是网速较快,而是流量不要钱。
移动数据流量环境下,缓存时间可以设置长一点,节省流量,就是节省金钱,而且用户体验也更好。
举个例子吧,最近本人在做的一个应用在wifi环境下的缓存时间设置为5分钟,移动数据流量下的缓存时间设置为1小时。
这个时间根据自己的实际情况来设置:数据的更新频率,数据的重要性等。
五、何时刷新
开发者一方面希望尽量读取缓存,用户一方面希望实时刷新,但是成都网站制作响应速度越快越好,流量消耗越少越好,是一个矛盾。
其实何时刷新我也不知道,这里我提供两点建议:
1 数据的最长多长时间不变,对应用无大的影响。
比如,你的数据更新时间为1天,则缓存时间设置为4~8小时比较合适,一天他总会看到更新,如果你觉得你是资讯类应用,再减少,2~4小时,如果你觉得数据比较重要或者比较受欢迎,用户会经常把玩,再减少,1~2小时,依次类推。
为了保险起见,你可能需要毫无理由的再次缩减一下。
2 提供刷新按钮。
上面说的保险起见不一定保险,最保险的方法使在相关界面提供一个刷新按钮,为缓存,为加载失败提供一次重新来过的机会,有了这个刷新按钮,我们的心也才真的放下来。
以上就是关于数据库缓存。全部的内容,包括:数据库缓存。、Spring如何配置数据库查询缓存/对象缓存EHCache、redis常见问题等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)