Ehcache 介绍(1)--Ehcache 功能特性

1.1.1、堆内缓存（heap）

所谓的堆内（heap）缓存，就是我们常规意义上说的内存缓存，严格意义上来说，是指被 JVM 托管占用的部分内存。内存缓存最大的优势就是具有超快的读写速度，但是不足点就在于容量有限、且无法持久化。

1.1.2、堆外缓存（off-heap）

堆外（off-heap）缓存，同样是存储在内存中。其实就是在内存中开辟一块区域，将其当做磁盘进行使用。由于内存的读写速度特别快，所以将数据存储在这个区域，读写上可以获得比本地磁盘读取更优的表现。这里的“堆外”，主要是相对与 JVM 的堆内存而言的，因为这个区域不在 JVM 的堆内存中，所以叫堆外缓存。这块的关系如下图：

既然都是内存中存储，那为何多此一举非要将其划分为堆外缓存呢？直接将这部分的空间类驾到堆内缓存上，不是一样的效果吗？原因如下：

JVM 会基于 GC 机制自动的对内存中不再使用的对象进行垃圾回收，而 GC 的时候对系统性能的影响是非常大的。堆内缓存的数据越多，GC 的压力就会越大，对系统性能的影响也会越明显。所以为了降低大量缓存对象 GC 回收动作的影响，便出现了 off-heap 处理方式。在 JVM 堆外的内存中开辟一块空间，可以像使用本地磁盘一样去使用这块内存区域，这样就既享受了内存的高速读写能力，又避免频繁 GC 带来的烦恼。

堆内缓存与堆外缓存的区别与各自优缺点：
堆内缓存是由 JVM 管理的，在 JVM 中可以直接以引用的形式去读取，所以读写的速度会特别高。而且 JVM 会负责其内容的回收与清理，使用起来比较“省心”。
堆外缓存是在内存中划定了一块独立的存储区域，然后可以将这部分内存当做“磁盘”进行使用。需要使用方自行维护数据的清理，读写前需要序列化与反序列化操作，但可以省去 GC 的影响。

1.1.3、磁盘缓存（disk）

当我们需要缓存的数据量特别大、内存容量无法满足需求的时候，可以使用 disk 磁盘存储来作为补充。相比于内存，磁盘的读写速度显然要慢一些、但是胜在其价格便宜，容量可以足够大。

1.1.4、集群缓存（Cluster）

作为单机缓存，数据都是存在各个进程内的，在分布式组网系统中，如果缓存数据发生变更，就会出现各个进程节点中缓存数据不一致的问题。为了解决这一问题，Ehcache 支持通过集群的方式，将多个分布式节点组网成一个整体，保证相互节点之间的数据同步。

需要注意的是，除了堆内缓存属于 JVM 堆内部，可以直接通过引用的方式进行访问，其余几种类型都属于 JVM 外部的数据交互，所以对这部分数据的读写时，需要先进行序列化与反序列化，因此要求缓存的数据对象一定要支持序列化与反序列化。

不同的缓存类型具有不同的运算处理速度，堆内缓存的速度最快，堆外缓存次之，集群缓存的速度最慢。为了兼具处理性能与缓存容量，可以采用多种缓存形式组合使用的方式，构建多级缓存来实现。组合上述几种不同缓存类型然后构建多级缓存的时候，也需要遵循几个约束：

A、多级缓存中必须有堆内缓存，必须按照 堆内缓存 < 堆外缓存 < 磁盘缓存 < 集群缓存 的顺序进行组合；
B、多级缓存中的容量设定必须遵循 堆内缓存 < 堆外缓存 < 磁盘缓存 < 集群缓存 的原则；
C、多级缓存中不允许磁盘缓存与集群缓存同时出现；

1.2、支持缓存持久化

常规的基于内存的缓存都有一个通病就是无法持久化，每次重启的时候，缓存数据都会丢失，需要重新去构建。而 Ehcache 支持使用磁盘来对缓存内容进行持久化保存。

1.3、支持分布式缓存

对于分布式系统，或者是集群场景下，并非是本地缓存的主战场。为了保证集群内数据的一致性，很多场景往往直接选择 Redis 等集中式缓存。但是集中式缓存也弊端，比如有些数据并不怎么更新、但是每个节点对其依赖度却非常高，如果频繁地去 Redis 请求交互，又会导致大量的性能损耗在网络 IO 交互处理上。
针对这种情况，Ehcache 给出了一个相对完美的答案：本地 + 集群化策略。即在本地缓存的基础上，将集群内各本地节点组成一个相互连接的网，然后基于某种机制，将一个节点上发生的变更同步给其余节点进行同步更新，这样就可以实现各个节点的缓存数据一致。

Ehcache 提供了多种不同的解决方案，可以将其由本地缓存变身为“分布式缓存”：
RMI 组播方式
JMS 消息方式
Cache Server 模式
JGroup 方式
Terracotta 方式

1.4、更灵活和细粒度的过期时间设定

Guava Cache 与 Caffeine，它们支持设定过期时间，但是仅允许设定缓存容器级别的过期时间，容器内的所有元素都遵循同一个过期时间。
Ehcache 不仅支持缓存容器级别的过期时间设定，还会支持为容器中每一条缓存记录设定独立过期时间，允许不同记录有不同的过期时间。这在某些场景下还是非常友好的，可以指定部分热点数据一个相对较长的过期时间，避免热点数据因为过期导致的缓存击穿。

1.5、同时支持 JCache 与 SpringCache 规范

Ehcache 作为一个标准化的通用缓存框架，同时支持 Java 目前最为主流的两大缓存标准，即官方的 JSR107 标准以及使用非常广泛的 Spring Cache 标准，这样使得业务中可以基于标准化的缓存接口去调用，避免了 Ehcache 深度耦合到业务逻辑中去。

1.6、Ehcache、Caffeine、Redis 如何选择

1.6.1、Caffeine

A、更加轻量级，使用更加简单，可以理解为一个增强版的 HashMap
B、足够纯粹，适用于仅需要本地缓存数据的常规场景，可以获取到绝佳的命中率与并发访问性能

1.6.2、Redis

A、纯粹的集中缓存，为集群化、分布式多节点场景而生，可以保证缓存的一致性
B、业务需要通过网络进行交互，相比与本地缓存而言性能上会有损耗

1.6.3、Ehcache