高并发系统三大利器之缓存

引言

随着互联网的高速发展，市面上也出现了愈来愈多的网站和app。咱们判断一个软件是否好用，用户体验就是一个重要的衡量标准。好比说咱们常常用的微信，打开一个页面要十几秒，发个语音要几分钟对方才能收到。相信这样的软件你们确定是都不肯意用的。软件要作到用户体验好，响应速度快，缓存就是必不可少的一个神器。缓存又分进程内缓存和分布式缓存两种：分布式缓存如redis、memcached等，还有本地（进程内）缓存如ehcache、GuavaCache、Caffeine等。

缓存特征

缓存做为一个数据数据模型对象，那么它有一些什么样的特征呢？下面咱们分别来介绍下这些特征。

命中率

• 命中率=命中数/（命中数+没有命中数）当某个请求可以经过访问缓存而获得响应时，称为缓存命中。缓存命中率越高，缓存的利用率也就越高。

最大空间

• 缓存中能够容纳最大元素的数量。当缓存存放的数据超过最大空间时，就须要根据淘汰算法来淘汰部分数据存放新到达的数据。

淘汰算法

• 缓存的存储空间有限制，当缓存空间被用满时，如何保证在稳定服务的同时有效提高命中率？这就由缓存淘汰算法来处理，设计适合自身数据特征的淘汰算法可以有效提高缓存命中率。常见的淘汰算法有：

FIFO(first in first out)

• 先进先出。最早进入缓存的数据在缓存空间不够的状况下（超出最大元素限制）会被优先被清除掉，以腾出新的空间接受新的数据。策略算法主要比较缓存元素的建立时间。适用于保证高频数据有效性场景，优先保障最新数据可用。

LFU(less frequently used)

• 最少使用，不管是否过时，根据元素的被使用次数判断，清除使用次数较少的元素释放空间。策略算法主要比较元素的hitCount（命中次数）。适用于保证高频数据有效性场景。

LRU(least recently used)

• 最近最少使用，不管是否过时，根据元素最后一次被使用的时间戳，清除最远使用时间戳的元素释放空间。策略算法主要比较元素最近一次被get使用时间。比较适用于热点数据场景，优先保证热点数据的有效性。

进程缓存

为何须要引入本地缓存，本地缓存的应用场景有哪些？

本地缓存的话是咱们的应用和缓存都在同一个进程里面，获取缓存数据的时候纯内存操做，没有额外的网络开销，速度很是快。它适用于缓存一些应用中基本不会变化的数据，好比（国家、省份、城市等）。

项目中通常如何适用、怎么样加载、怎么样更新？

进程缓存的话，通常能够在应用启动的时候，把须要的数据加载到系统中。更新缓存的话能够采起定时更新（实时性不高）。具体实现的话就是在应用中起一个定时任务（ScheduledExecutorService、TimerTask等），让它每隔多久去加载变动（数据变动以后能够修改数据库最后修改的时间，每次查询变动数据的时候均可以根据这个最后变动时间加上半小时大于当前时间的数据）的数据从新到缓存里面来。若是以为这个比较麻烦的话，还能够直接所有全量更新（就跟项目启动加载数据同样）。这种方式的话，对数据更新可能会有点延迟。可能这台机器看到的是更新后的数据，那台机器看到的数据仍是老的（机器发布时间可能不同）。因此这种方式比较适用于对数据实时性要求不高的数据。若是对实时性有要求的话能够经过广播订阅mq消息。若是有数据更新mq会把更新数据推送到每一台机器，这种方式的话实时性会比前一种定时更新的方法会好。可是实现起来会比较复杂。

本地缓存有哪些实现方式？

常见本地缓存有如下几种实现方式：

从上述表格咱们看出性能最佳的是Caffeine。关于这个本地缓存的话我仍是强烈推荐的，里面提供了丰富的api，以及各类各样的淘汰算法。如需了解更加详细的话能够看下之前写的这个篇文章《本地缓存性能之王Caffeine》。

本地缓存缺点

• 本地缓存与业务系统耦合再一块儿，应用之间没法直接共享缓存的内容。须要每一个应用节点单独的维护本身的缓存。每一个节点都须要一份同样的缓存，对服务器内存形成一种浪费。本地缓存机器重启、或者宕机都会丢失。

分布式缓存

• 分布式缓存是与应用分离的缓存组件或服务，其最大的优势是自身就是一个独立的应用，与本地应用隔离，多个应用可直接的共享缓存。常见的分布式缓存有redis、MemCache等。

分布式缓存的应用

在高并发的环境下，好比春节抢票大战，一到放票的时间节点，分分钟大量用户以及黄牛的各类抢票软件流量进入12306，这时候若是每一个用户的访问都去数据库实时查询票的库存，大量读的请求涌入到数据库，瞬间Db就会被打爆，cpu直接上升100%，服务立刻就要宕机或者假死。即便进行了分库分表也是没法避免的。为了减轻db的压力以及提升系统的响应速度。通常都会在数据库前面加上一层缓存，甚至可能还会有多级缓存。

缓存常见问题

缓存雪崩

指大量缓存同一时间段集体失效，或者缓存总体不能提供服务，致使大量的请求所有到达数据库
对数据CPU和内存形成巨大压力，严重的会形成数据库宕机。所以而造成的一系列连锁反应形成整个系统奔溃。
解决这个问题能够从如下方面入手：

• 保证缓存的高可用。使用redis的集群模式，即便个别redis节点下线，缓存仍是能够用。通常稍微大点的公司还可能会在多个机房部署Redis。
  这样即便某个机房忽然停电，或者光纤又被挖断了，这时候缓存仍是可使用。
• 使用多级缓存。不一样级别缓存时间过期时间不同，即便某个级别缓存过时了，还有其余缓存级别
  兜底。好比咱们Redis缓存过时了，咱们还有本地缓存。这样的话即便没有命中redis，有可能会命中本地缓存。
• 缓存永不过时。Redis中保存的key永久不失效，这样的话就不会出现大量缓存同时失效的问题，可是这种作法会浪费更多的存储空间，通常应该也不会推荐这种作法。
• 使用随机过时时间。为每个key都合理的设计一个过时时间，这样能够避免大量的key再同一时刻集体失效。
• 异步重建缓存。这样的话须要维护每一个key的过时时间，定时去轮询这些key的过时时间。例如一个key的value设置的过时时间是30min，那咱们能够为这个key设置它本身的一个过时时间为20min。因此当这个key到了20min的时候咱们就能够从新去构建这个key的缓存，同时也更新这个key的一个过时时间。

缓存穿透

指查询一个不存在的数据，每次经过接口或者去查询数据库都查不到这个数据，好比黑客的恶意攻击，好比知道一个订单号后，而后就伪造一些不存在的订单号，而后并发来请求你这个订单详情。这些订单号在缓存中都查询不到，而后会致使把这些查询请求所有打到数据库或者SOA接口。这样的话就会致使数据库宕机或者你的服务大量超时。
这种查询不存在的数据就是缓存击穿。
解决这个问题能够从如下方面入手：

• 缓存空值，对于这些不存在的请求，仍然给它缓存一个空的结果，这种方式简单粗暴，可是若是后续这个请求有新值了须要把原来缓存的空值删除掉（因此通常过时时间能够稍微设置的比较短）。
• 经过布隆过滤器。查询缓存以前先去布隆过滤器查询下这个数据是否存在。若是数据不存在，而后直接返回空。这样的话也会减小底层系统的查询压力。
• 缓存没有直接返回。 这种方式的话要根据本身的实际业务来进行选择。好比固定的数据，一些省份信息或者城市信息，能够所有缓存起来。这样的话数据有变化的状况，缓存也须要跟着变化。实现起来可能比较复杂。

缓存击穿

是指缓存里面的一个热点key(拼多多的五菱宏光神车的秒杀)在某个时间点过时。针对于这一个key有大量并发请求过来而后都会同时去数据库请求数据，瞬间对数据库形成巨大的压力。
这个的话能够用缓存雪崩的几种解决方法来避免：

• 缓存永不过时。Redis中保存的key永久不失效，这样的话就不会出现大量缓存同时失效的问题，可是这种作法会浪费更多的存储空间，通常应该也不会推荐这种作法。
• 异步重建缓存。这样的话须要维护每一个key的过时时间，定时去轮询这些key的过时时间。例如一个key的value设置的过时时间是30min，那咱们能够为这个key设置它本身的一个过时时间为20min。因此当这个key到了20min的时候咱们就能够从新去构建这个key的缓存，同时也更新这个key的一个过时时间。
• 互斥锁重建缓存。这种状况的话只能针对于同一个key的状况下，好比你有100个并发请求都要来取A的缓存，这时候咱们能够借助redis分布式锁来构建缓存，让只有一个请求能够去查询DB其余99个（没有获取到锁）都在外面等着，等A查询到数据而且把缓存构建好以后其余99个请求都只须要从缓存取就行了。原理就跟咱们java的DCL（double checked locking）思想有点相似。
  

缓存更新

咱们通常的缓存更新主要有如下几种更新策略：

• 先更新缓存，再更新数据库
• 先更新数据库，再更新缓存
• 先删除缓存，再更新数据库
• 先更新数据源库，再删除缓存
  至于选择哪一种更新策略的话，没有绝对的选择，能够根据本身的业务状况来选择适合本身的不过通常推荐的话是选择 先更新数据源库，再删除缓存。关于这几种更新的介绍能够推荐你们看下博客园大佬孤独烟写的《分布式之数据库和缓存双写一致性方案解析》这一篇文章，看完文章评论也能够去看看，评论跟内容同样精彩。

总结

若是想要真正的设计好一个缓存，咱们仍是必需要掌握不少的知识，对于不一样场景，缓存有各自不一样的用法。好比实际工做中咱们对于订单详情的一个缓存。咱们可能会根据订单的状态来来构建缓存。咱们就以机票订单为例，已出行、或者已经取消的订单咱们基本上是不会去管的（订单状态已经终止了），这种的话数据基本也不会变了，因此对于这种订单咱们设置的过时时间是否是就能够久一点，好比7天或者30天。对于未出行即将起飞的订单，这时候顾客是否是就会频繁的去刷新订单看看，看看有没有晚点什么的，或者登机口是在哪。对于这种实时性要求比较高的订单咱们过时时间仍是要设置的比较短的，若是是须要更改订单的状态查询的时候能够直接不走缓存，直接查询master库。毕竟这种更改订单状态的操做仍是比较有限的。大多数状况都是用来展现的。展现的话是能够容许实时性要求没那么高。总的来讲须要开具体的业务，没有通用的方案。看你的业务需求的容忍度，毕竟脱离了业务来谈技术都是耍流氓，是业务驱动技术。

结束

• 因为本身才疏学浅，不免会有纰漏，假如你发现了错误的地方，还望留言给我指出来,我会对其加以修正。
• 若是你以为文章还不错，你的转发、分享、赞扬、点赞、留言就是对我最大的鼓励。
• 感谢您的阅读,十分欢迎并感谢您的关注。

站在巨人的肩膀上摘苹果:
https://juejin.im/post/6844903665845665805
https://tech.meituan.com/2017/03/17/cache-about.html
http://www.javashuo.com/article/p-ftdcqtnl-cx.html