高并发场景下缓存处理的一些思路！

转载自：微信公众号《Java知音》
在实际的开发当中，咱们常常须要进行磁盘数据的读取和搜索，所以常常会有出现从数据库读取数据的场景出现。

可是当数据访问量次数增大的时候，过多的磁盘读取可能会最终成为整个系统的性能瓶颈，甚至是压垮整个数据库，致使系统卡死等严重问题。

常规的应用系统中，咱们一般会在须要的时候对数据库进行查找，所以系统的大体结构以下所示：

当数据量较高的时候，须要减小对于数据库里面的磁盘读写操做，所以一般都会选择在业务系统和MySQL数据库之间加入一层缓存从而减小对数据库方面的访问压力。

可是不少时候，缓存在实际项目中的应用并不是这么简单。下边咱们来经过几个比较经典的缓存应用场景来列举一些问题：

1.缓存和数据库之间数据一致性问题

经常使用于缓存处理的机制我总结为了如下几种：

Cache Aside
Read Through
Write Through
Write Behind Caching
首先来简单说说Cache aside的这种方式：

Cache Aside模式

这种模式处理缓存一般都是先从数据库缓存查询，若是缓存没有命中则从数据库中进行查找。

这里面会发生的三种状况以下：

缓存命中：

当查询的时候发现缓存存在，那么直接从缓存中提取。

缓存失效：

当缓存没有数据的时候，则从database里面读取源数据，再加入到cache里面去。

缓存更新：

当有新的写操做去修改database里面的数据时，须要在写操做完成以后，让cache里面对应的数据失效。

这种Cache aside模式一般是咱们在实际应用开发中最为经常使用到的模式。可是并不是说这种模式的缓存处理就必定能作到完美。
关于这种模式下依然会存在缺陷。

好比，一个是读操做，可是没有命中缓存，而后就到数据库中取数据，此时来了一个写操做，写完数据库后，让缓存失效，而后，以前的那个读操做再把老的数据放进去，因此，会形成脏数据。

Facebook的大牛们也曾经就缓存处理这个问题发表过相关的论文，连接以下:

https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final170_update.pdf
分布式环境中要想彻底的保证数据一致性是一件极为困难的事情，咱们只可以尽量的减低这种数据不一致性问题产生的状况。

Read Through模式

Read Through模式是指应用程序始终从缓存中请求数据。若是缓存没有数据，则它负责使用底层提供程序插件从数据库中检索数据。检索数据后，缓存会自行更新并将数据返回给调用应用程序。使用Read Through 有一个好处。

咱们老是使用key从缓存中检索数据, 调用的应用程序不知道数据库， 由存储方来负责本身的缓存处理，这使代码更具可读性， 代码更清晰。

可是这也有相应的缺陷，开发人员须要给编写相关的程序插件，增长了开发的难度性。

Write Through模式

Write Through模式和Read Through模式相似，当数据发生更新的时候，先去Cache里面进行更新，若是命中了，则先更新缓存再由Cache方来更新database。若是没有命中的话，就直接更新Cache里面的数据。

Write Behind Caching模式

Write Behind Caching 这种模式一般是先将数据写入到缓存里面，而后再异步的写入到database中进行数据同步

这样的设计既能够直接的减小咱们对于数据的database里面的直接访问，下降压力，同时对于database的屡次修改能够进行合并操做，极大的提高了系统的承载能力。

可是这种模式处理缓存数据具备必定的风险性，例如说当cache机器出现宕机的时候，数据会有丢失的可能。

2.缓存穿透问题

在高并发的场景中，缓存穿透是一个常常都会遇到的问题。

什么是缓存穿透？

大量的请求在缓存中没有查询到指定的数据，所以须要从数据库中进行查询，形成缓存穿透。

会形成什么后果？

大量的请求短期内涌入到database中进行查询会增长database的压力，最终致使database没法承载客户单请求的压力，出现宕机卡死等现象。

经常使用的解决方案一般有如下几类：

1.空值缓存

在某些特定的业务场景中，对于数据的查询可能会是空的，没有实际的存在，而且这类数据信息在短期进行屡次的反复查询也不会有变化，那么整个过程当中，屡次的请求数据库操做会显得有些多余。

不妨能够将这些空值（没有查询结果的数据）对应的key存储在缓存中，那么第二次查找的时候就不须要再次请求到database那么麻烦，只须要经过内存查询便可。这样的作法可以大大减小对于database的访问压力。

2.布隆过滤器

一般对于database里面的数据的key值能够预先存储在布隆过滤器里面去，而后先在布隆过滤器里面进行过滤

若是发现布隆过滤器中没有的话，就再去redis里面进行查询，若是redis中也没有数据的话，再去database查询。这样能够避免不存在的数据信息也去往存储库中进行查询状况。

关于布隆过滤器的学习能够参考下个人这篇笔记：
https://blog.csdn.net/Danny_idea/article/details/88946673

3.缓存雪崩场景

什么是缓存雪崩？

当缓存服务器重启或者大量缓存集中在某一个时间段失效，这样在失效的时候，也会给后端系统(好比DB)带来很大压力。

如何避免缓存雪崩问题？

1.使用加锁队列来应付这种问题。当有多个请求涌入的时候，当缓存失效的时候加入一把分布式锁，只容许抢锁成功的请求去库里面读取数据而后将其存入缓存中，再释放锁，让后续的读请求从缓存中取数据。

可是这种作法有必定的弊端，过多的读请求线程堵塞，将机器内存占满，依然没有可以从根本上解决问题。

2.在并发场景发生前，先手动触发请求，将缓存都存储起来，以减小后期请求对database的第一次查询的压力。

数据过时时间设置尽可能分散开来，不要让数据出现同一时间段出现缓存过时的状况。

3.从缓存可用性的角度来思考，避免缓存出现单点故障的问题，能够结合使用 主从+哨兵的模式来搭建缓存架构

可是这种模式搭建的缓存架构有个弊端，就是没法进行缓存分片，存储缓存的数据量有限制，所以能够升级为Redis Cluster架构来进行优化处理

（须要结合企业实际的经济实力，毕竟Redis Cluster的搭建须要更多的机器）

4.Ehcache本地缓存 + Hystrix限流&降级,避免MySQL被打死。

使用 Ehcache本地缓存的目的也是考虑在 Redis Cluster 彻底不可用的时候，Ehcache本地缓存还可以支撑一阵。

使用 Hystrix进行限流 & 降级 ，好比一秒来了5000个请求，咱们能够设置假设只能有一秒 2000个请求能经过这个组件，那么其余剩余的 3000 请求就会走限流逻辑。

而后去调用咱们本身开发的降级组件（降级），好比设置的一些默认值呀之类的。以此来保护最后的 MySQL 不会被大量的请求给打死。