本地缓存（EhCache）+远程分布式缓存（Redis）
使用场景
- EhCache：单应用、访问要求很高的应用
- Redis：缓存共享、分布式部署、缓存内容很大
当某台服务器本地缓存更新时，通过广播策略通知其它服务器节点进行更新本地缓存。
- 方案一：Redis发布订阅模式
- 方案二：JGroups广播模式
为考虑本地缓存和服务器缓存要保证数据的一致性，防止因各种原因导致因广播信息没有收到，或因其它未知原因而导致本地缓存没有更新，所以需要定时拉取更新策略来解决这类问题。
定时更新是在广播更新的基础上，在本地缓存增设超时时间，如果超过指定周期没有收到广播信息，则清除本地缓存的KEY（设置超时时间即可），从而保证缓存的最终一致性。
注意：Redis常规缓存必须设置过期时间，防止：①更新失败导致缓存不一致②僵尸类型数据占用服务器内存。而系统配置类型数据，则可设置永久缓存，如系统配置基本不会更新或更新频率低。
应用启动时，需要情况本地与服务器同步的缓存区域数据，以保证缓存的一致性。
- 模式一：本地缓存
- 模式二：服务器缓存
- 模式三：本地缓存+服务器缓存
EhCache是一个纯Java的进程内缓存框架，具有快速、精干等特点。主要特性有：
- 快速、精干
- 简单
- 多种缓存策略
- 缓存数据有两级：内存和磁盘，因此无需担心容量问题
- 缓存数据会在虚拟机重启的过程中写入磁盘
- 可以通过 RMI、可插入 API 等方式进行分布式缓存
- 具有缓存和缓存管理器的侦听接口
- 支持多缓存管理器实例，以及一个实例的多个缓存区域
- 提供 Hibernate 的缓存实现
EhCache集群方案 其中的三种最为常用集群方式，分别是 RMI、JGroups 以及 EhCache Server 。
- Terracotta
- RMI
- JMS : 依赖 ehcache-jmsreplication.jar
- JGroups : 依赖ehcache-jgroupsreplication.jar
- EhCache Server
一般的缓存系统，都是按照key去缓存查询，如果不存在对应的value，就应该去后端系统查找（比如DB）。如果key对应的value是一定不存在的，并且对该key并发请求量很大，就会对后端系统造成很大的压力。这就叫做缓存穿透。
解决方案：
- 布隆过滤：将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力
- 缓存空对象
对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：缓存被“击穿”的问题，这个和缓存雪崩的区别在于这里针对某一key缓存，前者则是很多key。缓存在某个时间点过期的时候，恰好在这个时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。
解决方案：
- 使用互斥锁(mutex key)
- 用不过期策略
当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统(比如DB)带来很大压力。
解决方案：
- 通过锁或队列方式实现固定线程池（进程）读取数据库来写如缓存操作，避免失效时大量请求打入底层
- 缓存过期时间=固定值+随机时间：通过该办法将所有KEY的过期时间，全部分散至这个随机时间段内，降低集体失效概率
- 增设二级缓存：原始缓存(L1，过期时间短) --> 拷贝缓存(L2，过期时间长)
1：缓存系统与底层数据的一致性。这点在底层系统是“可读可写”时，写得尤为重要
2：有继承关系的缓存之间的一致性。为了尽量提高缓存命中率，缓存也是分层：全局缓存，二级缓存。他们是存在继承关系的。全局缓存可以有二级缓存来组成。
3：多个缓存副本之间的一致性。为了保证系统的高可用性，缓存系统背后往往会接两套存储系统（如memcache，redis等）
缓存淘汰的策略有两种，如何取舍根据自己的应用场景来权衡：
(1)定时去清理过期的缓存。缺点是维护大量缓存的key是比较麻烦的
(2)当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。 缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂
- 预估失效时间
- 版本号(必须单调递增，时间戳是最好的选择)
- 提供手动清理缓存的接口