数据库缓存。

第一条可以使用 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常见问题等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！