1. 0 背景

在之前的文章中缓存进化史介绍了某大型互联网公司的缓存架构和缓存的进化历史。俗话说得好，工欲善其事，必先利其器，有了好的工具肯定得知道如何用好这些工具，本篇将介绍如何利用好缓存。

2. 1.确认是否需要缓存

在使用缓存之前，需要确认你的项目是否真的需要缓存。使用缓存会引入的一定的技术复杂度，后文也将会一一介绍这些复杂度。一般来说从两个方面来个是否需要使用缓存:

1，CPU占用:如果你有某些应用需要消耗大量的cpu去计算，比如正则表达式，如果你使用正则表达式比较频繁，而其又占用了很多CPU的话，那你就应该使用缓存将正则表达式的结果给缓存下来。

2，数据库IO占用:如果你发现你的数据库连接池比较空闲，那么不应该用缓存。但是如果数据库连接池比较繁忙，甚至经常报出连接不够的报警，那么是时候应该考虑缓存了。笔者曾经有个服务，被很多其他服务调用，其他时间都还好，但是在每天早上10点的时候总是会报出数据库连接池连接不够的报警，经过排查，发现有几个服务选择了在10点做定时任务，大量的请求打过来，DB连接池不够，从而报出连接池不够的报警。这个时候有几个选择，我们可以通过扩容机器来解决，也可以通过增加数据库连接池来解决，但是没有必要增加这些成本，因为只有在10点的时候才会出现这个问题。后来引入了缓存，不仅解决了这个问题，而且还增加了读的性能。

如果并没有上述两个问题，那么你不必为了增加缓存而缓存。

 

3. 2.选择合适的缓存

缓存又分进程内缓存和分布式缓存两种。很多人包括笔者在开始选缓存框架的时候都感到了困惑:网上的缓存太多了，大家都吹嘘自己很牛逼，我该怎么选择呢？

3-1. 2.1 选择合适的进程缓存

首先看看几个比较常用的缓存的比较，具体原理可以参考你应该知道的缓存进化史:

对于ConcurrentHashMap来说，比较适合缓存比较固定不变的元素，且缓存的数量较小的。虽然从上面表格中比起来有点逊色，但是其由于是jdk自带的类，在各种框架中依然有大量的使用,比如我们可以用来缓存我们反射的Method,Field等等;也可以缓存一些链接，防止其重复建立。在Caffeine中也是使用的ConcurrentHashMap来存储元素。

对于LRUMap来说，如果不想引入第三方包，又想使用淘汰算法淘汰数据，可以使用这个。

对于Ehcache来说，由于其jar包很大，较重量级。对于需要持久化和集群的一些功能的，可以选择Ehcache。笔者没怎么使用过这个缓存，如果要选择的话，可以选择分布式缓存来替代Ehcache。

对于Guava Cache来说，Guava这个jar包在很多Java应用程序中都有大量的引入，所以很多时候其实是直接用就好了，并且其本身是轻量级的而且功能较为丰富，在不了解Caffeine的情况下可以选择Guava Cache。

对于Caffeine来说，笔者是非常推荐的，其在命中率，读写性能上都比Guava Cache好很多，并且其API和Guava cache基本一致，甚至会多一点。在真实环境中使用Caffeine，取得过不错的效果。

总结一下:如果不需要淘汰算法则选择ConcurrentHashMap，如果需要淘汰算法和一些丰富的API，这里推荐选择Caffeine。

3-2. 2.2 选择合适的分布式缓存

这里选取三个比较出名的分布式缓存来作为比较，MemCache(没有实战使用过)，Redis(在美团又叫Squirrel)，Tair(在美团又叫Cellar)。不同的分布式缓存功能特性和实现原理方面有很大的差异，因此他们所适应的场景也有所不同。

4. 3.多级缓存

很多人一想到缓存马上脑子里面就会出现下面的图:

Redis用来存储热点数据，Redis中没有的数据则直接去数据库访问。

在之前介绍本地缓存的时候，很多人都问我，我已经有Redis了，我干嘛还需要了解Guava，Caffeine这些进程缓存呢。我基本统一回复下面两个答案:

1，Redis如果挂了或者使用老版本的Redis,其会进行全量同步，此时Redis是不可用的，这个时候我们只能访问数据库，很容易造成雪崩。

2，访问Redis会有一定的网络I/O以及序列化反序列化，虽然性能很高但是其终究没有本地方法快，可以将最热的数据存放在本地，以便进一步加快访问速度。这个思路并不是我们做互联网架构独有的，在计算机系统中使用L1,L2,L3多级缓存，用来减少对内存的直接访问，从而加快访问速度。

所以如果仅仅是使用Redis，能满足我们大部分需求，但是当需要追求更高的性能以及更高的可用性的时候，那就不得不了解多级缓存。

4-1. 3.1使用进程缓存

对于进程内缓存，其本来受限于内存的大小的限制，以及进程缓存更新后其他缓存无法得知，所以一般来说进程缓存适用于:

1，数据量不是很大，数据更新频率较低，之前我们有个查询商家名字的服务，在发送短信的时候需要调用，由于商家名字变更频率较低，并且就算是变更了没有及时变更缓存，短信里面带有老的商家名字客户也能接受。利用Caffeine作为本地缓存,size设置为1万，过期时间设置为1个小时，基本能在高峰期解决问题。

2，如果数据量更新频繁，也想使用进程缓存的话，那么可以将其过期时间设置为较短，或者设置其较短的自动刷新的时间。这些对于Caffeine或者Guava Cache来说都是现成的API。

4-2. 3.2使用多级缓存

俗话说得好，世界上没有什么是一个缓存解决不了的事，如果有，那就两个。

一般来说我们选择一个进程缓存和一个分布式缓存来搭配做多级缓存，一般来说引入两个也足够了，如果使用三个，四个的话，技术维护成本会很高，反而有可能会得不偿失，如下图所示:

利用Caffeine做一级缓存，Redis作为二级缓存。

1，首先去Caffeine中查询数据，如果有直接返回。如果没有则进行第2步。

2，再去Redis中查询，如果查询到了返回数据并在Caffeine中填充此数据。如果没有查到则进行第3步。

3，最后去Mysql中查询，如果查询到了返回数据并在Redis，Caffeine中依次填充此数据。

对于Caffeine的缓存，如果有数据更新，只能删除更新数据的那台机器上的缓存，其他机器只能通过超时来过期缓存，超时设定可以有两种策略:

• 设置成写入后多少时间后过期
• 设置成写入后多少时间刷新

对于Redis的缓存更新，其他机器立马可见，但是也必须要设置超时时间，其时间比Caffeine的过期长。

为了解决进程内缓存的问题，设计进一步优化:

通过Redis的pub/sub，可以通知其他进程缓存对此缓存进行删除。如果Redis挂了或者订阅机制不靠谱，依靠超时设定，依然可以做兜底处理。

5. 4.缓存更新

怎样保证数据在 DB 和缓存中的一致性呢？现在一个比较好的最佳实践方案，就是 Cache Aside Pattern。

先来看一下数据的读取过程，规则是：先读 Cache，再读 DB。

一般来说缓存的更新有两种情况:

• 先删除缓存，再更新数据库。
• 先更新数据库，再删除缓存。 这两种情况在业界，大家对其都有自己的看法。具体怎么使用还得看各自的取舍。当然肯定会有人问为什么要删除缓存呢？而不是更新缓存呢？你可以想想当有多个并发的请求更新数据，你并不能保证更新数据库的顺序和更新缓存的顺序一致，那就会出现数据库中和缓存中数据不一致的情况。所以一般来说考虑删除缓存。

 

为什么是删除缓存，而不是更新缓存？

原因很简单。很多时候，在复杂点的缓存场景，缓存不单单是数据库中直接取出来的值。比如可能更新了某个表的一个字段，然后其对应的缓存，是需要查询另外两个表的数据并进行运算，才能计算出缓存最新的值的。

另外更新缓存的代价有时候是很高的。是不是说，每次修改数据库的时候，都一定要将其对应的缓存更新一份？也许有的场景是这样，但是对于比较复杂的缓存数据计算的场景，就不是这样了。如果你频繁修改一个缓存涉及的多个表，缓存也频繁更新。但是问题在于，这个缓存到底会不会被频繁访问到？

举个例子，一个缓存涉及的表的字段，在 1 分钟内就修改了 20 次，或者是 100 次，那么缓存更新 20 次、100 次；但是这个缓存在 1 分钟内只被读取了 1 次，有大量的冷数据。实际上，如果你只是删除缓存的话，那么在 1 分钟内，这个缓存不过就重新计算一次而已，开销大幅度降低。用到缓存才去算缓存。

其实删除缓存，而不是更新缓存，就是一个 Lazy 计算的思想，不要每次都重新做复杂的计算，不管它会不会用到，而是让它到需要被使用的时候再重新计算。像 Mybatis、Hibernate，都有懒加载思想。查询一个部门，部门带了一个员工的 list，没有必要说每次查询部门，都里面的 1000 个员工的数据也同时查出来啊。80% 的情况，查这个部门，就只是要访问这个部门的信息就可以了。先查部门，同时要访问里面的员工，那么这个时候只有在你要访问里面的员工的时候，才会去数据库里面查询 1000 个员工。

5-1. 4.1先删除缓存，再更新数据库

对于一个查询[写]操作简单来说，就是先去各级缓存进行删除，然后更新数据库。这个操作有一个比较大的问题，在对缓存删除完之后，有一个读请求，这个时候由于缓存被删除所以直接会读库，读操作的数据是老的并且会被加载进入缓存当中，后续读请求全部访问的老数据。

对缓存的操作不论成功失败都不能阻塞我们对数据库的操作，那么很多时候删除缓存可以用异步的操作，但是先删除缓存不能很好的适用于这个场景。

先删除缓存也有一个好处是，如果对数据库操作失败了，那么由于先删除的缓存，最多只是造成Cache Miss。

5-2. 4.2先更新数据库，再删除缓存(推荐)

如果我们使用更新数据库，再删除缓存就能避免上面的问题。但是同样的引入了新的问题, 试想一下有一个数据此时是没有缓存的，所以查询请求没有命中缓存会直接落库，此时来了个查询[写]操作，但是查询[写]操作以及更新缓存操作，发生在入库查询完之后并且回填缓存之前，就会导致我们缓存中和数据库出现缓存不一致。

为什么我们这种情况有问题，很多公司包括Facebook还会选择呢？因为要触发这个条件比较苛刻。

1，首先需要数据不在缓存中。

2，其次查询操作需要在更新操作先到达数据库。

3，最后查询操作的回填比更新操作的删除后触发，这个条件基本很难出现，因为更新操作本来在查询[写]操作之后，实际上数据库的写操作会比读操作慢得多，而且还要锁表，而读操作必需在查询[写]操作前进入数据库操作，而又要晚于查询[写]操作更新缓存，所有的这些条件都具备的概率基本并不大。

对比上面4.1的问题来说这种问题的概率很低，况且我们有超时机制保底所以基本能满足我们的需求。如果真的需要追求完美，可以使用二阶段提交，但是其成本和收益一般来说不成正比。

当然还有个问题是如果我们删除缓存失败了，缓存的数据就会和数据库的数据不一致，那么我们就只能靠过期超时来进行兜底。对此我们可以进行优化，如果删除失败的话 我们不能影响主流程那么我们可以将其放入队列后续进行异步删除。

5-3. 4.3先更新数据库，再异步删除缓存

4.3 这个是方案三的改进方案，都是先操作数据库再操作缓存，但可能删除缓存失败。

通过数据库的binlog来异步淘汰key，以mysql为例，可以使用阿里的canal将binlog日志采集发送到MQ队列里面，然后通过ACK机制确认处理 这条数据更新消息，删除缓存，保证数据缓存一致性。

但是呢还有个问题，如果是主从数据库呢？

 

5-4. 4.4先更新数据库，再异步删除缓存(多库)

主从DB问题：因为主从DB同步存在同时延时时间如果删除缓存之后，数据同步到备库之前已经有请求过来时，会从备库中读到脏数据，如何解决呢？

解决方案如下流程图：

综上所述，在分布式系统中，缓存和数据库同时存在时，如果有写操作的时候，先操作数据库，再操作缓存。如下：

1. 读取缓存中是否有相关数据
2. 如果缓存中有相关数据value，则返回
3. 如果缓存中没有相关数据，则从数据库读取相关数据放入缓存中key->value，再返回
4. 如果有更新数据，则先更新数据，再删除缓存
5. 为了保证第四步删除缓存成功，使用binlog异步删除
6. 如果是主从数据库，binglog取自于从库
7. 如果是一主多从，每个从库都要采集binlog，然后消费端收到最后一台binlog数据才删除缓存

 

5-5. 4.5 比较复杂的数据不一致问题分析

对于4.1的数据发生了变更的情况，先删除缓存，再更新数据库。此时还没来得及修改，一个请求过来，去读缓存，发现缓存空了，去查询数据库，查到了修改前的旧数据，放到了缓存中。随后数据变更的程序完成了数据库的修改。数据库和缓存中的数据不一样了……

为什么上亿流量高并发场景下，缓存会出现这个问题？

只有在对一个数据在并发的进行读写的时候，才可能会出现这种问题。其实如果说你的并发量很低的话，特别是读并发很低。每天访问量就 1 万次，那么很少的情况下，会出现刚才描述的那种不一致的场景。但是问题是，如果每天的是上亿的流量，每秒并发读请求是几万，每秒只要有数据更新的请求，就可能会出现上述的数据库+缓存不一致的情况。

解决方案如下：

更新数据的时候，根据数据的唯一标识，将操作路由之后，发送到一个 JVM 内部队列中。读取数据的时候，如果发现数据不在缓存中，那么将重新读取数据+更新缓存的操作，根据唯一标识路由之后，也发送同一个 JVM 内部队列中。

一个队列对应一个工作线程，每个工作线程串行拿到对应的操作，然后一条一条的执行。这样的话，一个数据变更的操作，先删除缓存，然后再去更新数据库，但是还没完成更新。此时如果一个读请求过来，读到了空的缓存，那么可以先将缓存更新的请求发送到队列中，此时会在队列中积压，然后同步等待缓存更新完成。

这里有一个优化点：一个队列中，其实多个更新缓存请求串在一起是没意义的，因此可以做过滤。如果发现队列中已经有一个更新缓存的请求了，那么就不用再放个更新请求操作进去了，直接等待前面的更新操作请求完成即可。

待那个队列对应的工作线程完成了上一个操作的数据库的修改之后，才会去执行下一个操作，也就是缓存更新的操作，此时会从数据库中读取最新的值，然后写入缓存中。

如果请求还在等待时间范围内，不断轮询发现可以取到值了，那么就直接返回；如果请求等待的时间超过一定时长，那么这一次直接从数据库中读取当前的旧值。

高并发的场景下，该解决方案要注意的问题：读请求长时阻塞。

由于读请求进行了非常轻度的异步化，所以一定要注意读超时的问题，每个读请求必须在超时时间范围内返回。

该解决方案，最大的风险点在于：可能数据更新很频繁，导致队列中积压了大量更新操作。然后读请求会发生大量的超时，最后导致大量的请求直接走数据库。务必通过一些模拟真实的测试，看看更新数据的频率是怎样的。

另外，因为一个队列中可能会积压针对多个数据项的更新操作，因此需要根据自己的业务情况进行测试，可能需要部署多个服务，每个服务分摊一些数据的更新操作。如果一个内存队列里居然会挤压 100 个商品的库存修改操作，每个库存修改操作要耗费 10ms 去完成，那么最后一个商品的读请求，可能等待 10 * 100 = 1000ms = 1s 后，才能得到数据，这个时候就导致读请求的长时阻塞。

一定要做根据实际业务系统的运行情况，去进行一些压力测试，和模拟线上环境，去看看最繁忙的时候，内存队列可能会挤压多少更新操作，可能会导致最后一个更新操作对应的读请求，会 hang 多少时间，如果读请求在 200ms 返回，如果你计算过后，哪怕是最繁忙的时候，积压 10 个更新操作，最多等待 200ms，那还可以的。

如果一个内存队列中可能积压的更新操作特别多，那么你就要加机器，让每个机器上部署的服务实例处理更少的数据，那么每个内存队列中积压的更新操作就会越少。

其实根据之前的项目经验，一般来说，数据的写频率是很低的，因此实际上正常来说，在队列中积压的更新操作应该是很少的。像这种针对读高并发、读缓存架构的项目，一般来说写请求是非常少的，每秒的 QPS 能到几百就不错了。

我们来实际粗略测算一下。

如果一秒有 500 的写操作，如果分成 5 个时间片，每 200ms 就 100 个写操作，放到 20 个内存队列中，每个内存队列，可能就积压 5 个写操作。每个写操作性能测试后，一般是在 20ms 左右就完成，那么针对每个内存队列的数据的读请求，也就最多 hang 一会儿，200ms 以内肯定能返回了。

经过刚才简单的测算，我们知道，单机支撑的写 QPS 在几百是没问题的，如果写 QPS 扩大了 10 倍，那么就扩容机器，扩容 10 倍的机器，每个机器 20 个队列。

• 读请求并发量过高

这里还必须做好压力测试，确保恰巧碰上上述情况的时候能够处理。还有一个风险，就是突然间大量读请求会在几十毫秒的延时 hang 在服务上，看服务能不能扛的住，需要多少机器才能扛住最大的极限情况的峰值。

但是因为并不是所有的数据都在同一时间更新，缓存也不会同一时间失效，所以每次可能也就是少数数据的缓存失效了，然后那些数据对应的读请求过来，并发量应该也不会特别大。

• 多服务实例部署的请求路由

可能这个服务部署了多个实例，那么必须保证说，执行数据更新操作，以及执行缓存更新操作的请求，都通过 Nginx 服务器路由到相同的服务实例上。

比如说，对同一个商品的读写请求，全部路由到同一台机器上。可以自己去做服务间的按照某个请求参数的 hash 路由，也可以用 Nginx 的 hash 路由功能等等。

• 热点商品的路由问题，导致请求的倾斜

万一某个商品的读写请求特别高，全部打到相同的机器的相同的队列里面去了，可能会造成某台机器的压力过大。就是说，因为只有在商品数据更新的时候才会清空缓存，然后才会导致读写并发，所以其实要根据业务系统去看，如果更新频率不是太高的话，这个问题的影响并不是特别大，但是的确可能某些机器的负载会高一些。

 

5-6. 4.6 Spring 中的缓存注解

使用 SpringBoot 可以很容易地对 Redis 进行操作，Java 的 Redis的客户端，常用的有三个：jedis、redisson 和 lettuce，Spring 默认使用的是 lettuce。

很多人，喜欢使用 Spring 抽象的缓存包 spring-cache。

它使用注解，采用 AOP 的方式，对 Cache 层进行了抽象，可以在各种堆内缓存框架和分布式框架之间进行切换。

这是它的 maven 坐标：

使用 spring-cache 有三个步骤：

• 在启动类上加入 @EnableCaching 注解。
• 使用 CacheManager 初始化要使用的缓存框架，使用 @CacheConfig 注解注入要使用的资源。
• 使用 @Cacheable 等注解对资源进行缓存。

而针对缓存操作的注解，有三个：

• @Cacheable：表示如果缓存系统里没有这个数值，就将方法的返回值缓存起来。
• @CachePut：表示每次执行该方法，都把返回值缓存起来。
• @CacheEvict：表示执行方法的时候，清除某些缓存值。

那么问题来了，spring-cache 中的 @CacheEvict 注解，到底是先删缓存，还是后删缓存呢？不弄明白这一点，真的是让人夜不能寐。关键技术嘛，不仅要用的开心，也要用的放心。

缓存的移除，是在 CacheAspectSupport 中实现的，我们注意到下面的代码：

它有一个前置的清除动作，还有后置的清除动作，是通过一个 bool 变量 boolean beforeInvocation 进行设置的。

这个值从哪里来的呢？还是得看 @CacheEvict 注解：

很好很好，它的默认值是 false，证明删除动作是滞后的，践行的也是 Cache Aside Pattern。

 

一行代码解决缓存击穿的问题

5-6-1. 缓存穿透

布谷过滤器多么多么牛逼，却没有任何落地的方案。

对于缓存穿透问题，有一个很简单的解决方案，就是缓存NULL值~从缓存取不到的数据，在数据库中也没有取到，直接返回空值。

那么spring-cache中，有一个配置是这样的

带上该配置后，就可以缓存null值了，值得一提的是，这个缓存时间要设的少一点，例如15秒就够，如果设置过长，会导致正常的缓存也无法使用。

5-6-2. 缓存击穿

Spring4.3为@Cacheable注解提供了一个新的参数“sync”（boolean类型，缺省为false），当设置它为true时，只有一个线程的请求会去到数据库，其他线程都会等待直到缓存可用。这个设置可以减少对数据库的瞬间并发访问。

看到这里！！这不就是一个限流方案么？

所以解决方法就是，加一个属性sync=true，就行。代码就像下面这样

用了该属性后，可以指示底层将缓存锁住，使只有一个线程可以进入计算，而其他线程堵塞，直到返回结果更新到缓存中。

这个只是针对单机的限流，并不是整体集群的限流！

当然，如果你非要解决，也有办法。spring的aop有套路的，比如@Transactional的Advice是TransactionInterceptor，那么cache也对应对一个CacheInterceptor，我们只要去改CacheInterceptor，这个切面就能解决。在里头做一个分布式锁！伪代码如下

5-6-3. 缓存雪崩

在高并发下，大量的缓存key在同一时间失效，导致大量的请求落到数据库上，如活动系统里面同时进行着非常多的活动，但是在某个时间点所有的活动缓存全部过期。

那么针对该问题，最简单的解决方法就是，过期时间加随机值！

但是很麻烦的是，我们在使用@Cacheable注解的时候，原生功能没法直接设置随机过期时间的。

这个老实说，真没啥好方法，只能自己继承RedisCache，对其增强，改写其中的put方法，带上随机时间！

 

6. 5.缓存挖坑三剑客

大家一听到缓存有哪些注意事项，肯定首先想到的是缓存穿透，缓存击穿，缓存雪崩这三个挖坑的小能手，这里简单介绍一下他们具体是什么以及应对的方法。

6-1. 5.1缓存穿透 Cache penetration

缓存穿透是指查询的数据在数据库是没有的，那么在缓存中自然也没有，所以，在缓存中查不到就会去数据库取查询，这样的请求一多，那么我们的数据库的压力自然会增大。

为了避免这个问题，可以采取下面两个手段:

1，约定:对于返回为NULL的依然缓存，对于抛出异常的返回不进行缓存,注意不要把抛异常的也给缓存了。采用这种手段的会增加我们缓存的维护成本，需要在插入缓存的时候删除这个空缓存，当然我们可以通过设置较短的超时时间来解决这个问题。

2，制定一些规则过滤一些不可能存在的数据，小数据用BitMap，大数据可以用布隆过滤器，比如你的订单ID 明显是在一个范围1-1000，如果不是1-1000之内的数据那其实可以直接给过滤掉。

6-2. 5.2 热点失效 Hotspot data set is invalid

【原文小节标题为缓存击穿，和缓存穿透区别不大，我觉得还是采用附录中英文原文的 热点失效较好】

对于某些key设置了过期时间，但是其是热点数据，如果某个key失效，可能大量的请求打过来，缓存未命中，然后去数据库访问，此时数据库访问量会急剧增加。

为了避免这个问题，我们可以采取下面的两个手段:

1，加分布式锁:加载数据的时候可以利用分布式锁锁住这个数据的Key,在Redis中直接使用setNX操作即可，对于获取到这个锁的线程，查询数据库更新缓存，其他线程采取重试策略，这样数据库不会同时受到很多线程访问同一条数据。

1.1 使用互斥锁(mutex key)

业界比较常用的做法，是使用mutex。简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法。

SETNX，是「SET if Not eXists」的缩写，也就是只有不存在的时候才设置，可以利用它来实现锁的效果。在redis2.6.1之前版本未实现setnx的过期时间，所以这里给出两种版本代码参考：

最新版本代码：

memcache代码：

6-2-1-1. 1.2 “提前”使用互斥锁(mutex key)：

在value内部设置1个超时值(timeout1), timeout1比实际的memcache timeout(timeout2)小。当从cache读取到timeout1发现它已经过期时候，马上延长timeout1并重新设置到cache。然后再从数据库加载数据并设置到cache中。伪代码如下：

6-2-1-2. 1.3 异步加载（永远不过期）：  

由于热点失效是热点数据才会出现的问题，可以对这部分热点数据采取到期自动刷新的策略，而不是到期自动淘汰。淘汰其实也是为了数据的时效性，所以采用自动刷新也可以。

这里的“永远不过期”包含两层意思：

(1) 从redis上看，确实没有设置过期时间，这就保证了，不会出现热点key过期问题，也就是“物理”不过期。

(2) 从功能上看，如果不过期，那不就成静态的了吗？所以我们把过期时间存在key对应的value里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建，也就是“逻辑”过期

从实战看，这种方法对于性能非常友好，唯一不足的就是构建缓存时候，其余线程(非构建缓存的线程)可能访问的是老数据，但是对于一般的互联网功能来说这个还是可以忍受。

 

2. 资源保护：

采用netflix的hystrix，可以做资源的隔离保护主线程池，如果把这个应用到缓存的构建也未尝不可。

四种解决方案：没有最佳只有最合适

解决方案	优点	缺点
简单分布式互斥锁（mutex key）	1. 思路简单 2. 保证一致性	1. 代码复杂度增大 2. 存在死锁的风险 3. 存在线程池阻塞的风险
“提前”使用互斥锁	1. 保证一致性	同上
不过期(本文)	1. 异步构建缓存，不会阻塞线程池	1. 不保证一致性。 2. 代码复杂度增大(每个value都要维护一个timekey)。 3. 占用一定的内存空间(每个value都要维护一个timekey)。
资源隔离组件hystrix(本文)	1. hystrix技术成熟，有效保证后端。 2. hystrix监控强大。	1. 部分访问存在降级策略。

此节可参照：

[总结]Redis热点Key发现及常见解决方案

[]

 

6-3. 5.3缓存雪崩 Cache Avalanche

缓存雪崩是指缓存不可用或者大量缓存由于超时时间相同在同一时间段失效，大量请求直接访问数据库，数据库压力过大导致系统雪崩。

为了避免这个问题，我们采取下面的手段:

1，增加缓存系统可用性,通过监控关注缓存的健康程度，根据业务量适当的扩容缓存。

2，采用多级缓存，不同级别缓存设置的超时时间不同，及时某个级别缓存都过期，也有其他级别缓存兜底。

3，缓存的key值可以取个随机值，比如以前是设置10分钟的超时时间，那每个Key都可以随机8-13分钟过期，尽量让不同Key的过期时间不同。

此节可参照：

[总结]为什么分布式一定要有Redis？

3 major problems and solutions in the cache world 

 

7. 6.缓存污染

缓存污染一般出现在我们使用本地缓存中，可以想象，在本地缓存中如果你获得了缓存，但是你接下来修改了这个数据，但是这个数据并没有更新在数据库，这样就造成了缓存污染:

上面的代码就造成了缓存污染，通过id获取Customer，但是需求需要修改Customer的名字，所以开发人员直接在取出来的对象中直接修改，这个Customer对象就会被污染，其他线程取出这个数据就是错误的数据。

要想避免这个问题需要开发人员从编码上注意，并且代码必须经过严格的review，以及全方位的回归测试，才能从一定程度上解决这个问题。

 

8. 7.序列化

序列化是很多人都不注意的一个问题，很多人忽略了序列化的问题，上线之后马上报出一下奇怪的错误异常，造成了不必要的损失，最后一排查都是序列化的问题。列举几个序列化常见的问题:

1，key-value对象过于复杂导致序列化不支持:笔者之前出过一个问题，在美团的Tair内部默认是使用protostuff进行序列化，而美团使用的通讯框架是thfift，thrift的TO是自动生成的，这个TO里面很多复杂的数据结构，但是将其存放到了Tair中。查询的时候反序列化也没有报错，单测也通过，但是到qa测试的时候发现这一块功能有问题，发现有个字段是boolean类型默认是false，把它改成true之后，序列化到tair中再反序列化还是false。定位到是protostuff对于复杂结构的对象(比如数组，List）

2，添加了字段或者删除了字段，导致上线之后老的缓存获取的时候反序列化报错，或者出现一些数据移位。

3，不同的JVM的序列化不同，如果你的缓存有不同的服务都在共同使用(不提倡)，那么需要注意不同JVM可能会对Class内部的Field排序不同，而影响序列化。比如下面的代码，在Jdk7和Jdk8中对象A的排列顺序不同，最终会导致反序列化结果出现问题:

序列化的问题必须得到重视，解决的办法有如下几点:

1,测试:对于序列化需要进行全面的测试，如果有不同的服务并且他们的JVM不同那么你也需要做这一块的测试，在上面的问题中笔者的单测通过的原因是用的默认数据false，所以根本没有测试true的情况，还好QA给力，将其给测试出来了。

2,对于不同的序列化框架都有自己不同的原理，对于添加字段之后如果当前序列化框架不能兼容老的，那么可以换个序列化框架。 对于protostuff来说他是按照Field的顺序来进行反序列化的，对于添加字段我们需要放到末尾，也就是不能插在中间，否则会出现错误。对于删除字段来说，用@Deprecated注解进行标注弃用，如果贸然删除，除非是最后一个字段，否则肯定会出现序列化异常。

3,可以使用双写来避免，对于每个缓存的key值可以加上版本号，每次上线版本号都加1，比如现在线上的缓存用的是Key1，即将要上线的是Key2,上线之后对缓存的添加是会写新老两个不同的版本(Key1,Key2)的Key-Value，读取数据还是读取老版本Key_1的数据,假设之前的缓存的过期时间是半个小时，那么上线半个小时之后，之前的老缓存存量的数据都会被淘汰，此时线上老缓存和新缓存他们的数据基本是一样的,切换读操作到新缓存，然后停止双写。采用这种方法基本能平滑过渡新老Model交替，但是不好的点就是需要短暂的维护两套新老Model，下次上线的时候需要删除掉老Model，增加了维护成本。

 

9. 8. GC调优

对于大量使用本地缓存的应用，由于涉及到缓存淘汰，那么GC问题必定是常事。如果出现GC较多，STW时间较长，那么必定会影响服务可用性。这一块给出下面几点建议:

1,经常查看GC监控，如何发现不正常，需要想办法对其进行优化。

2,对于CMS垃圾收集器，如果发现remark过长，如果是大量本地缓存应用的话这个过长应该很正常，因为在并发阶段很容易有很多新对象进入缓存，从而remark阶段扫描很耗时，remark又会暂停。可以开启-XX:CMSScavengeBeforeRemark，在remark阶段前进行一次YGC，从而减少remark阶段扫描gc root的开销。

3,可以使用G1垃圾收集器，通过-XX:MaxGCPauseMillis设置最大停顿时间，提高服务可用性。

 

10. 9. 缓存的监控

很多人对于缓存的监控也比较忽略，基本上线之后如果不报错然后就默认他就生效了。但是存在这个问题，很多人由于经验不足，有可能设置了不恰当的过期时间，或者不恰当的缓存大小导致缓存命中率不高，让缓存就成为了代码中的一个装饰品。所以对于缓存各种指标的监控，也比较重要，通过其不同的指标数据，我们可以对缓存的参数进行优化，从而让缓存达到最优化:

上面的代码中用来记录get操作的，通过Cat记录了获取缓存成功，缓存不存在，缓存过期，缓存失败(获取缓存时如果抛出异常，则叫失败)，通过这些指标，我们就能统计出命中率，我们调整过期时间和大小的时候就可以参考这些指标进行优化。

 

11. 10. 一款好的框架

一个好的剑客没有一把好剑怎么行呢？如果要使用好缓存，一个好的框架也必不可少。在最开始使用的时候大家使用缓存都用一些util，把缓存的逻辑写在业务逻辑中:

上面的代码把缓存的逻辑耦合在业务逻辑当中，如果我们要增加成多级缓存那就需要修改我们的业务逻辑，不符合开闭原则，所以引入一个好的框架是不错的选择。

推荐大家使用JetCache这款开源框架，其实现了Java缓存规范JSR107并且支持自动刷新等高级功能。笔者参考JetCache结合Spring Cache, 监控框架Cat以及美团的熔断限流框架Rhino实现了一套自有的缓存框架，让操作缓存，打点监控，熔断降级，业务人员无需关心。上面的代码可以优化成:

对于一些监控数据也能轻松从大盘上看到:

 

12. 总结

想要真正的使用好一个缓存，必须要掌握很多的知识，并不是看几个Redis原理分析，就能把Redis缓存用得炉火纯青。对于不同场景，缓存有各自不同的用法，同样的不同的缓存也有自己的调优策略，进程内缓存你需要关注的是他的淘汰算法和GC调优，以及要避免缓存污染等。分布式缓存你需要关注的是他的高可用，如果其不可用了如何进行降级，以及一些序列化的问题。一个好的框架也是必不可少的，对其如果使用得当再加上上面介绍的经验，相信能让你很好的驾驭住这头野马——缓存。

 

 

[resource]聊聊如何把缓存玩出一种境界

Redis：MySQL算老几？

缓存穿透，缓存击穿，缓存雪崩解决方案分析

如何保证缓存与数据库的双写一致性？

5个方案告诉你：高并发下先操作数据库还是先操作缓存？

同事乱用缓存，CTO发飙了…

一行代码解决缓存击穿的问题