Hibernate的缓存技术有哪些

缓存是数据库数据在内存中的临时容器,它包含了库表数据在内存中的临时拷贝,位于数据库与应用程序之间,其作用是为了降低应用程序对物理数据源访问的频次,从而提高应用的运行性能。

Hibernate的缓存机制

11持久化层的缓存的范围

持久层设计中,往往需要考虑几个不同层次中的数据缓存策略。这些层次的划分标准针对不同情况有所差异,一般而言,ORM的数据缓存应包含如下几个层次:

事务级缓存(Transaction Layer Cache)

缓存只能被当前事务访问。缓存的生命周期依赖于事务的生命周期,当事务结束时,缓存也就结束生命周期。在此范围下,缓存的介质是内存。事务可以是数据库事务或者应用事务,每个事务都有独自的缓存,缓存内的数据通常采用相互关联的对象形式。

应用级/进程级缓存(Application/Process Layer Cache)

缓存被进程内的所有事务共享。这些事务有可能是并发访问缓存,因此必须对缓存采取必要的事务隔离机制。缓存的生命周期依赖于进程的生命周期,进程结束时,缓存也就结束了生命周期。进程范围的缓存可能会存放大量的数据,所以存放的介质可以是内存或硬盘。缓存内的数据既可以是相互关联的对象形式也可以是对象的松散数据形式。对象的松散数据形式有点类似于对象的序列化数据,但是对象分解为松散的算法比对象序列化的算法要求更快。

集群级缓存(Cluster Layer Cache)

在集群环境中,缓存被一个机器或者多个机器的进程共享。缓存中的数据被复制到集群环境中的每个进程节点,进程间通过远程通信来保证缓存中的数据的一致性,缓存中的数据通常采用对象的松散数据形式。对大多数应用来说,应该慎重地考虑是否需要使用集群范围的缓存,因为访问的速度不一定会比直接访问数据库数据的速度快多少。

持久层提供以上多种层次的缓存。如果在事务级缓存中没有查到相应的数据,还可以到进程级或集群级缓存内查询,如果还是没有查到,那么只有到数据库中查询。事务级缓存是持久化层的第一级缓存,通常它是必需的;进程级或集群级缓存是持久化层的第二级缓存,通常是可选的。

12 hibernate缓存机制

Hibernate提供了两种缓存,第一种是Session的缓存,又称为一级缓存。由于Session对象的生命周期通常对应一个数据库事务或者一个应用事务,因此它的缓存是事务范围的缓存。第一级缓存是必需的,不允许而且事实上也无法卸除。在第一级缓存中,持久化类的每个实例都具有唯一的OID。

在java项目广泛的使用。它是一个开源的、设计于提高在数据从RDBMS中取出来的高花费、高延迟采取的一种缓存方案。正因为Ehcache具有健壮性（基于java开发）、被认证（具有apache 20 license）、充满特色（稍后会详细介绍），所以被用于大型复杂分布式web application的各个节点中。

1 够快

Ehcache的发行有一段时长了，经过几年的努力和不计其数的性能测试，Ehcache终被设计于large, high concurrency systems

2 够简单

开发者提供的接口非常简单明了，从Ehcache的搭建到运用运行仅仅需要的是你宝贵的几分钟。其实很多开发者都不知道自己用在用Ehcache，Ehcache被广泛的运用于其他的开源项目

比如：hibernate

3够袖珍

关于这点的特性，官方给了一个很可爱的名字small foot print ，一般Ehcache的发布版本不会到2M，V 223 才 668KB。

4 够轻量

核心程序仅仅依赖slf4j这一个包，没有之一！

5好扩展

Ehcache提供了对大数据的内存和硬盘的存储，最近版本允许多实例、保存对象高灵活性、提供LRU、LFU、FIFO淘汰算法，基础属性支持热配置、支持的插件多

6监听器

缓存管理器监听器 （CacheManagerListener）和 缓存监听器（CacheEvenListener）,做一些统计或数据一致性广播挺好用的

如何使用？

够简单就是Ehcache的一大特色，自然用起来just so easy!

redis

redis是在memcache之后编写的，大家经常把这两者做比较，如果说它是个key-value store 的话但是它具有丰富的数据类型，我想暂时把它叫做缓存数据流中心，就像现在物流中心那样，order、package、store、classification、distribute、end。现在还很流行的LAMP PHP架构 不知道和 redis+mysql 或者 redis + mongodb的性能比较（听群里的人说mongodb分片不稳定）。

先说说reidis的特性

1 支持持久化

redis的本地持久化支持两种方式：RDB和AOF。RDB 在redisconf配置文件里配置持久化触发器，AOF指的是redis没增加一条记录都会保存到持久化文件中（保存的是这条记录的生成命令），如果不是用redis做DB用的话还会不要开AOF ，数据太庞大了，重启恢复的时候是一个巨大的工程！

2丰富的数据类型

redis 支持 String 、Lists、sets、sorted sets、hashes 多种数据类型,新浪微博会使用redis做nosql主要也是它具有这些类型，时间排序、职能排序、我的微博、发给我的这些功能List 和 sorted set 的强大 *** 作功能息息相关

3高性能

这点跟memcache很想象，内存 *** 作的级别是毫秒级的比硬盘 *** 作秒级 *** 作自然高效不少，较少了磁头寻道、数据读取、页面交换这些高开销的 *** 作！这也是NOSQL冒出来的原因吧，应该是高性能

是基于RDBMS的衍生产品，虽然RDBMS也具有缓存结构，但是始终在app层面不是我们想要的那么 *** 控的。

4replication

redis提供主从复制方案，跟mysql一样增量复制而且复制的实现都很相似，这个复制跟AOF有点类似复制的是新增记录命令，主库新增记录将新增脚本发送给从库，从库根据脚本生成记录，这个过程非常快，就看网络了，一般主从都是在同一个局域网，所以可以说redis的主从近似及时同步，同事它还支持一主多从，动态添加从库，从库数量没有限制。 主从库搭建，我觉得还是采用网状模式，如果使用链式（master-slave-slave-slave-slave·····）如果第一个slave出现宕机重启，首先从master 接收 数据恢复脚本，这个是阻塞的，如果主库数据几TB的情况恢复过程得花上一段时间，在这个过程中其他的slave就无法和主库同步了。

5更新快

这点好像从我接触到redis到目前为止 已经发了大版本就4个，小版本没算过。redis作者是个非常积极的人，无论是邮件提问还是论坛发帖，他都能及时耐心的为你解答，维护度很高。有人维护的话，让我们用的也省心和放心。目前作者对redis 的主导开发方向是redis的集群方向。

根据名称其实就能理解，这是属于Node级别的缓存。主要用于缓存Filter中的Query结果，基于LRU策略，当缓存满了的情况下，会自动去除一个最近最少被使用的Query Cache。

缓存分为两个级别，第一级是 Query ，第二级是 Segmemt ，就像是 Map<Query, Map<Segment, DocIdSet>> 这种结构一样。 DocIdSet 使用的数据结构是 Bitset 。

indicesqueriescachesize 集群中的每个节点都必须有的静态配置，用来控制用来缓存的内存大小，默认是10%，支持两种格式一种是百分数，代表占节点heap的百分比，另一种则是精确的值，比如512mb。

indicesqueriescachecount 在官方文档并没有写，这是一个节点级别的配置，可以在elasticsearchyml中配置，控制缓存的总数量。

indicesqueriescacheall_segments 用于是否在所有 Segment 上启用缓存，默认是false，不会对文档数小于100000或者小于整个索引大小的3%的 Segment 进行缓存。

indexqueriescacheenabled 是属于index级别的配置，用来控制是否启用缓存，默认是开启的。

Segment 中文档数大于100000或者大于整个所以大小的3%。

请注意如果想要索引所有段，请设置indicesqueriescacheall_segments

缓存不会失效，而是通过判断文档是否符合 Query 的条件，如果符合条件的话则会将文档加入到 Bitset 中。

主要用于 sort 以及 aggs 的字段。这会把字段的值加载到内存中，以便于快速访问。 field data cache 的构建非常昂贵，因此最好能分配足够的内存以保障它能长时间处于被加载的状态。

indicesfielddatacachesize 用来控制缓存的大小，支持两种格式，一种是百分数，代表占节点heap的百分比，另一种是精确值，如10gb，默认是无限。

顾名思义，Shard级别的缓存。默认的主要用于缓存size=0的请求， aggs 和 suggestions ，还有就是 hitstotal 。

需要注意，每当分片索引refresh的时候，如果数据发生了实际变化，那么缓存就会自动失效。所以呢，refresh时间越长，那么缓存的时间也就越长。缓存采用的也是LRU策略。

indexrequestscacheenable 这个参数用来控制是否启用分片级别的缓存，默认是false

通过url传参方式request_cache=true

indicesrequestscachesize 用来控制缓存在 heap 中的大小，默认是1%。

用于缓存新索引的数据，用于缓存新索引的数据，当空间填满之后，会将数据写到磁盘上成为一个新的段。

通常，为了提高网站响应速度，总是把热点数据保存在内存中而不是直接从后端数据库中读取。Redis是一个很好的Cache工具。大型网站应用，热点数据量往往巨大，几十G上百G是很正常的事儿，在这种情况下，如何正确架构Redis呢？

首先，无论我们是使用自己的物理主机，还是使用云服务主机，内存资源往往是有限制的，scale up不是一个好办法，我们需要scale out横向可伸缩扩展，这需要由多台主机协同提供服务，即分布式多个Redis实例协同运行。

其次，目前硬件资源成本降低，多核CPU，几十G内存的主机很普遍，对于主进程是单线程工作的Redis，只运行一个实例就显得有些浪费。同时，管理一个巨大内存不如管理相对较小的内存高效。因此，实际使用中，通常一台机器上同时跑多个Redis实例。

方案

1Redis官方集群方案 Redis Cluster

Redis Cluster是一种服务器Sharding技术，30版本开始正式提供。

Redis

Cluster中，Sharding采用slot(槽)的概念，一共分成16384个槽，这有点儿类似前面讲的pre

sharding思路。对于每个进入Redis的键值对，根据key进行散列，分配到这16384个slot中的某一个中。使用的hash算法也比较简

单，就是CRC16后16384取模。

Redis集群中的每个node(节点)负责分摊这16384个slot中的一部分，也就是说，每个

slot都对应一个node负责处理。当动态添加或减少node节点时，需要将16384个槽做个再分配，槽中的键值也要迁移。当然，这一过程，在目前实

现中，还处于半自动状态，需要人工介入。

Redis集群，要保证16384个槽对应的node都正常工作，如果某个node发生故障，那它负责的slots也就失效，整个集群将不能工作。

为

了增加集群的可访问性，官方推荐的方案是将node配置成主从结构，即一个master主节点，挂n个slave从节点。这时，如果主节点失

效，Redis Cluster会根据选举算法从slave节点中选择一个上升为主节点，整个集群继续对外提供服务。这非常类似前篇文章提到的Redis

Sharding场景下服务器节点通过Sentinel监控架构成主从结构，只是Redis Cluster本身提供了故障转移容错的能力。

Redis

Cluster的新节点识别能力、故障判断及故障转移能力是通过集群中的每个node都在和其它nodes进行通信，这被称为集群总线(cluster

bus)。它们使用特殊的端口号，即对外服务端口号加10000。例如如果某个node的端口号是6379，那么它与其它nodes通信的端口号是

16379。nodes之间的通信采用特殊的二进制协议。

对客户端来说，整个cluster被看做是一个整体，客户端可以连接任意一个

node进行 *** 作，就像 *** 作单一Redis实例一样，当客户端 *** 作的key没有分配到该node上时，Redis会返回转向指令，指向正确的node，这

有点儿像浏览器页面的302 redirect跳转。

Redis Cluster是Redis 30以后才正式推出，时间较晚，目前能证明在大规模生产环境下成功的案例还不是很多，需要时间检验。

2Redis Sharding集群

Redis 3正式推出了官方集群技术，解决了多Redis实例协同服务问题。Redis Cluster可以说是服务端Sharding分片技术的体现，即将键值按照一定算法合理分配到各个实例分片上，同时各个实例节点协调沟通，共同对外承担一致服务。

多Redis实例服务，比单Redis实例要复杂的多，这涉及到定位、协同、容错、扩容等技术难题。这里，我们介绍一种轻量级的客户端Redis Sharding技术。

Redis

Sharding可以说是Redis

Cluster出来之前，业界普遍使用的多Redis实例集群方法。其主要思想是采用哈希算法将Redis数据的key进行散列，通过hash函数，特定

的key会映射到特定的Redis节点上。这样，客户端就知道该向哪个Redis节点 *** 作数据。Sharding架构如图：

庆幸的是，java redis客户端驱动jedis，已支持Redis Sharding功能，即ShardedJedis以及结合缓存池的ShardedJedisPool。

Jedis的Redis Sharding实现具有如下特点：

采

用一致性哈希算法(consistent

hashing)，将key和节点name同时hashing，然后进行映射匹配，采用的算法是MURMUR_HASH。采用一致性哈希而不是采用简单类

似哈希求模映射的主要原因是当增加或减少节点时，不会产生由于重新匹配造成的rehashing。一致性哈希只影响相邻节点key分配，影响量小。

2

为了避免一致性哈希只影响相邻节点造成节点分配压力，ShardedJedis会对每个Redis节点根据名字(没有，Jedis会赋予缺省名字)会虚拟

化出160个虚拟节点进行散列。根据权重weight，也可虚拟化出160倍数的虚拟节点。用虚拟节点做映射匹配，可以在增加或减少Redis节点

时，key在各Redis节点移动再分配更均匀，而不是只有相邻节点受影响。

3ShardedJedis支持keyTagPattern模式，即抽取key的一部分keyTag做sharding，这样通过合理命名key，可以将一组相关联的key放入同一个Redis节点，这在避免跨节点访问相关数据时很重要。

Redis Sharding采用客户端Sharding方式，服务端Redis还是一个个相对独立的Redis实例节点，没有做任何变动。同时，我们也不需要增加额外的中间处理组件，这是一种非常轻量、灵活的Redis多实例集群方法。

当然，Redis Sharding这种轻量灵活方式必然在集群其它能力方面做出妥协。比如扩容，当想要增加Redis节点时，尽管采用一致性哈希，毕竟还是会有key匹配不到而丢失，这时需要键值迁移。

作为轻量级客户端sharding，处理Redis键值迁移是不现实的，这就要求应用层面允许Redis中数据丢失或从后端数据库重新加载数据。但有些时候，击穿缓存层，直接访问数据库层，会对系统访问造成很大压力。有没有其它手段改善这种情况？

Redis

作者给出了一个比较讨巧的办法--presharding，即预先根据系统规模尽量部署好多个Redis实例，这些实例占用系统资源很小，一台物理机可部

署多个，让他们都参与sharding，当需要扩容时，选中一个实例作为主节点，新加入的Redis节点作为从节点进行数据复制。数据同步后，修改

sharding配置，让指向原实例的Shard指向新机器上扩容后的Redis节点，同时调整新Redis节点为主节点，原实例可不再使用。

presharding

是预先分配好足够的分片，扩容时只是将属于某一分片的原Redis实例替换成新的容量更大的Redis实例。参与sharding的分片没有改变，所以也

就不存在key值从一个区转移到另一个分片区的现象，只是将属于同分片区的键值从原Redis实例同步到新Redis实例。

并不是只有增

删Redis节点引起键值丢失问题，更大的障碍来自Redis节点突然宕机。在《Redis持久化》一文中已提到，为不影响Redis性能，尽量不开启

AOF和RDB文件保存功能，可架构Redis主备模式，主Redis宕机，数据不会丢失，备Redis留有备份。

这样，我们的架构模式变

成一个Redis节点切片包含一个主Redis和一个备Redis。在主Redis宕机时，备Redis接管过来，上升为主Redis，继续提供服务。主

备共同组成一个Redis节点，通过自动故障转移，保证了节点的高可用性。则Sharding架构演变成：

Redis Sentinel提供了主备模式下Redis监控、故障转移功能达到系统的高可用性。

高访问量下，即使采用Sharding分片，一个单独节点还是承担了很大的访问压力，这时我们还需要进一步分解。通常情况下，应用访问Redis读 *** 作量和写 *** 作量差异很大，读常常是写的数倍，这时我们可以将读写分离，而且读提供更多的实例数。

可以利用主从模式实现读写分离，主负责写，从负责只读，同时一主挂多个从。在Sentinel监控下，还可以保障节点故障的自动监测。

3利用代理中间件实现大规模Redis集群

上面分别介绍了多Redis服务器集群的两种方式，它们是基于客户端sharding的Redis Sharding和基于服务端sharding的Redis Cluster。

客户端sharding技术其优势在于服务端的Redis实例彼此独立，相互无关联，每个Redis实例像单服务器一样运行，非常容易线性扩展，系统的灵活性很强。其不足之处在于：

由于sharding处理放到客户端，规模进步扩大时给运维带来挑战。

服务端Redis实例群拓扑结构有变化时，每个客户端都需要更新调整。

连接不能共享，当应用规模增大时，资源浪费制约优化。

服务端sharding的Redis Cluster其优势在于服务端Redis集群拓扑结构变化时，客户端不需要感知，客户端像使用单Redis服务器一样使用Redis集群，运维管理也比较方便。

不过Redis Cluster正式版推出时间不长，系统稳定性、性能等都需要时间检验，尤其在大规模使用场合。

能不能结合二者优势？即能使服务端各实例彼此独立，支持线性可伸缩，同时sharding又能集中处理，方便统一管理？本篇介绍的Redis代理中间件twemproxy就是这样一种利用中间件做sharding的技术。

twemproxy处于客户端和服务器的中间，将客户端发来的请求，进行一定的处理后(如sharding)，再转发给后端真正的Redis服务器。也就是说，客户端不直接访问Redis服务器，而是通过twemproxy代理中间件间接访问。

参照Redis Sharding架构，增加代理中间件的Redis集群架构如下：

twemproxy中间件的内部处理是无状态的，它本身可以很轻松地集群，这样可避免单点压力或故障。

twemproxy又叫nutcracker，起源于twitter系统中redis/memcached集群开发实践，运行效果良好，后代码奉献给开源社区。其轻量高效，采用C语言开发，工程网址是：GitHub - twitter/twemproxy: A fast, light-weight proxy for memcached and redis

twemproxy后端不仅支持redis，同时也支持memcached，这是twitter系统具体环境造成的。

由于使用了中间件，twemproxy可以通过共享与后端系统的连接，降低客户端直接连接后端服务器的连接数量。同时，它也提供sharding功能，支持后端服务器集群水平扩展。统一运维管理也带来了方便。

当然，也是由于使用了中间件代理，相比客户端直连服务器方式，性能上会有所损耗，实测结果大约降低了20%左右。

原文来自Ceph官方文档： CACHE TIERING

部分摘抄自Ceph中国社区翻译文档： 分级缓存

    分层缓存为ceph客户端中的某些存放在存储层的数据提供更好的IO性能。分级缓存需创建一个由高速而昂贵存储设备（如 SSD ）组成的存储池、作为缓存层，以及一个相对低速/廉价设备组成的后端存储池（或纠删码编码的）、作为经济存储层。Ceph 的对象处理器决定往哪里存储对象，分级代理决定何时把缓存内的对象刷回后端存储层；所以缓存层和后端存储层对 Ceph 客户端来说是完全透明的。

    缓存代理层管理着数据在缓存层和存储层之间的自动迁移。但是, 管理员也可以通过配置来干预迁移规则， 下面是对两个主要场景的介绍:

Writeback Mode： 当管理员将缓存层配置成回写模式, Ceph客户端将数据写入缓存层，并接收返回的ACK。同时，写入缓存层的数据迁移到存储层，  然后从缓存层刷掉。 直观的看， 缓存层在存储层之前。 当Ceph客户端需要存在于存储层的数据时， 缓存层代理会把这些数据迁移到缓存层，然后再发往 Ceph 客户端。因此，Ceph 客户端将与缓存层进行 I/O *** 作，直到数据不再被读写。此模式对于易变数据来说较理想（如照片/视频编辑、事务数据等）。

Read-proxy Mode： 这个模式将使用一些已经存在于缓存层的数据，但是，如果数据不在缓存层，请求将被代理转发到底层。这个模式对于从回写模式过渡到禁用缓存非常有用的， 因为它润需负载一直工作到缓存干涸，不再向缓存添加任何数据。

  如果负载过多，分层缓存会降低性能。用户在使用以下特性时需要极其谨慎。

Workload dependent : 缓存是否能提升性能，高度依赖于负载能力。因为将数据移入或移除缓存会导致额外的开销，它只在对数据集的访问有大的偏离时有影响。例如, 众多的请求访问小数量的objects，这时，你的缓存池需要非常大，才能在处理所有请求时，避免数据过渡。

Difficult to benchmark : 用户使用评测性能时，大部分的关于分层缓存bechmarks测试结果，将会是一个糟糕的结果。其中部分原因是很少的bechmarks倾斜于一组小的对象集合的请求 ， 这会使缓存经过很长时间后才能“活跃起来”，并且这种“活跃起来”会导致高昂的开销。

Usually slower : 对于并没有友好使用分级缓存的工作负载，性能普遍低于一个没使用分级缓存的普通rados池。

librados object enumeration : 对于librados级别的枚举对象API并不能连贯存在在这种情况中（The librados-level object enumeration API is not meant to be coherent in the presence of the case）。 如果你的应用直接使用rados，并且依赖于枚举对象，分级缓存不能向期待的那样工作 (对于RGW, RBD, or CephFS，没有这个问题)

Complexity : 在使用RADOS集群时，使用分级缓存意味着大量的额外器械和复杂性。这会增加你遇到未知的BUG（可能其他人未遇到过）的可能性， 并且使你的部署拥有更大的风险。

RGW time-skewed : 如果RGW工作中遇到的大部分 *** 作是朝向最近写入的数据，一个简单的分级缓存可以工作得很好。

    下面的配置使用分层缓存效果不佳。

RBD with replicated cache and erasure-coded base : 这是一个普遍的需求, 但是通常不能很好工作。即使合理的倾斜工作负载，仍然会遇到一些对于冷门object的写 *** 作的情况，并且由于纠删码类型的池还不支持轻微的读写 *** 作，为了适应一些小的写入 *** 作（通常4kb），整个object块（通常4MB）必须被全部迁移到缓存 。只有少数用户成功的应用了这种部署方式，并且这种部署方案只能为他们工作是因为他们的数据是极其“冷门”的（例如备份），并且他们对于性能并不敏感。

RBD with replicated cache and base : 在使用备份类型为基础层时比以纠删码为基础层时，RBD的表现更为良好， 但是它在工作负载中仍然依赖于大量的倾斜，并且很难验证。用户需要对他们的工作负载有更好的理解， 并且需要仔细调整分层缓存参数。

    为了建立分层缓存，你必须拥有两个存储池。一个作为后端存储，一个作为缓存。

    建立一个后端存储池包含两种场景：

标准存储 : 在这种场景中，这个池在Ceph存储集群中存储一个对象的多个副本。

纠删码: 在这种场景中，存储池用纠删码高效地存储数据，性能稍有损失。

    在标准存储场景中，你可以用 CRUSH 规则集来标识失败域（如 osd 、主机、机箱、机架、排等）。当规则集所涉及的所有驱动器规格、速度（转速和吞吐量）和类型相同时， OSD 守护进程运行得最优。创建规则集的详情见 CRUSH 图 。创建好规则集后，再创建后端存储池。

     在纠删码编码情景中，创建存储池时指定好参数就会自动生成合适的规则集，详情见 创建存储池 。

     在后续例子中，我们把cold-storage当作后端存储池。

 系统在很早之前就实现了一层对zookeeper的cache，目的是减少运行过程对zk集群的访问压力。

  大体流程是：启动时

     1对zk上某个目录节点A添加CHILD的watch事件，以监听A的子节点数量变更，及时更新cache；

     2 对A的所有子节点进行一次get，并添加每个子节点的变更watch事件，当节点内容变更或者节点删除时会收到回调。

    这套系统运行很长时间，整体跑得很ok。但最近做了一个新功能，线下验证过程中出现了各种奇奇怪怪的问题，比如两个节点直接出现了请求的无限转发，导致cpu持续打满；或者某个任务被分配到了某个节点负责(映射关系在zk上记录)，但是该节点始终不启动这个任务。

    根据debug日志定位了2天，才发现是一个典型的ABA问题，导致cache不对了。

    为啥之前系统跑得好好的呢？因为是去中心化的设计，某些实例节点对某些zk节点的cache不对也不影响整体运行，只有当所有实例节点的zcache都不对，才会work不了。（去中心化的设计有一定优势，但也有一些问题，不同场景需求不同，没有绝对的孰好孰坏）。

接下来具体说一下问题：

假设zk上有目录 A，A下面有节点b，即目录结构为 /A/b

某一时刻节点b被删除了，并且马上重建，则根据前文所述我们加上的watch，zk会给我们发送2个事件

1 目录A的子节点发生变更(加在A上的watch)

2 节点b发生删除(加在b上的watch)

    此时根据我们实现的(有问题)逻辑，直接忽略事件2，然后对A进行一次get children请求，根据拿到的最新子节点列表，跟内存的节点做diff，来删除或者增加cache中的节点。 但是此时节点b又被创建了，所以本次 *** 作不会对cache中的b进行修改。 注意，由于b节点的watch已经触发了，所以b节点的变更将不会再次发送事件通知，即我们内存中所看到的b节点内容永远是错的，除非下一次节点b再被删除，并且我们正确地从cache中删掉他，然后b再创建，我们再次get并加上watch。

    对于这种典型的ABA问题，我们直接想到的就是在get children拿到的最新子节点列表，与内存cache做diff时，带上版本信息，就能搞定了。但是zk的get children接口只能拿到父节点的stat(包含版本、修改时间等)，没有返回所有子节点的stat，故此时我们拿不到版本信息。

    我们的解决办法是，在收到事件2后，直接对节点b再发送一次get请求，若返回NO NODE，说明b确实被删除了，将内存cache中节点b删除；若返回ok，说明节点b又被创建了，则用最新的内容更新内存cache中的b信息，并且此时还是带着节点b的watch的。

区别：

1、存储方式不同

memecache 把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小；redis有部份存在硬盘上，这样能保证数据的持久性，支持数据的持久化（笔者注：有快照和AOF日志两种持久化方式，在实际应用的时候，要特别注意配置文件快照参数，要不就很有可能服务器频繁满载做dump）。

2、数据支持类型不同

redis在数据支持上要比memecache多的多。

3、使用底层模型不同

新版本的redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。

4、运行环境不同

redis目前官方只支持LINUX 上去行，从而省去了对于其它系统的支持，这样的话可以更好的把精力用于本系统 环境上的优化，虽然后来微软有一个小组为其写了补丁。但是没有放到主干上。

扩展资料

注意事项

1、 Redis和Memcache都是将数据存放在内存中，都是内存数据库。不过memcache还可用于缓存其他东西，例如、视频等等。

2、Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，hash等数据结构的存储。

3、虚拟内存–Redis当物理内存用完时，可以将一些很久没用到的value 交换到磁盘 。

4、过期策略–memcache在set时就指定，例如set key1 0 0 8,即永不过期。Redis可以通过例如expire 设定，例如expire name 10 。

5、分布式–设定memcache集群，利用magent做一主多从;redis可以做一主多从。都可以一主一，存储数据安全–memcache挂掉后，数据没了；redis可以定期保存到磁盘（持久化） 。

参考资料：

百度百科：redis 百度百科：memcache

以上就是关于Hibernate的缓存技术有哪些全部的内容，包括:Hibernate的缓存技术有哪些、redis和c#cache的区别 博客园、Elasticsearch的缓存机制简介等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！