缓存是什么？
存储的速度是有区别的。缓存（Cache）就是把低速存储的结果，临时保存在高速存储的技术。
为什么需要缓存？
缓存的目的就是为了减轻数据库压力，提高存取的效率。
数据存储在如MySQL等关系型数据库中，通常支持事务的ACID特性，因为可靠性，持久性等因素，性能普遍不高，高并发的查询会给MySQL带来压力，造成数据库系统的不稳定。同时也容易产生延迟。根据局部性原理，80%请求会落到20%的热点数据上，在读多写少场景，增加一层缓存非常有助提升系统吞吐量和健壮性。
如何实现本地缓存和分布式缓存？
•本地缓存是指程序级别的缓存组件，它的特点是应用程序和本地缓存会运行在同一个进程中，所以本地缓存的操作会非常快，因为在同一个进程内也意味着不会有网络上的延迟和开销。本地缓存适用于单节点非集群的应用场景，它的优点是快，缺点是多程序无法共享缓存，比如分布式用户 Session 会话信息保存，由于每次用户访问的服务器可能是不同的，如果不能共享缓存，那么就意味着每次的请求操作都有可能被系统阻止，因为会话信息只保存在某一个服务器上，当请求没有被转发到这台存储了用户信息的服务器时，就会被认为是非登录的违规操作。除此之外，无法共享缓存可能会造成系统资源的浪费，这是因为每个系统都单独维护了一份属于自己的缓存，而同一份缓存有可能被多个系统单独进行存储，从而浪费了系统资源。本地缓存可以使用 EhCache 和 Google 的 Guava 来实现.
•分布式缓存是指将应用系统和缓存组件进行分离的缓存机制，这样多个应用系统就可以共享一套缓存数据了，它的特点是共享缓存服务和可集群部署，为缓存系统提供了高可用的运行环境，以及缓存共享的程序运行机制。而分布式缓存可以使用 Redis 或 Memcached 来实现。由于 Redis 本身就是独立的缓存系统，因此可以作为第三方来提供共享的数据缓存，而 Redis 的分布式支持主从、哨兵和集群的模式，所以它就可以支持分布式的缓存，而 Memcached 的情况也是类似的。
存在问题
缓存和数据库一致性问题，存储的数据随着时间可能会发生变化，而缓存中的数据就会不一致。具体能容忍的不一致时间，需要具体业务具体分析，但是通常的业务，都需要做到最终一致性。
一致性介绍
一致性又可以分为强一致性与弱一致性。
1.强一致性
强一致性可以理解为在任意时刻，所有节点中的数据是一样的。同一时间点，你在节点A中获取到key1的值与在节点B中获取到key1的值应该都是一样的。
2.弱一致性
弱一致性包含很多种不同的实现，分布式系统中广泛实现的是最终一致性。
3.最终一致性
所谓最终一致性，是弱一致性的一种特例，保证用户最终能够读取到某操作对系统特定数据的更新。但是随着时间的迁移，不同节点上的同一份数据总是在向趋同的方向变化。也可以简单的理解为在一段时间后，节点间的数据会最终达到一致状态。对于最终一致性最好的例子就是DNS系统，由于DNS多级缓存的实现，所以修改DNS记录后不会在全球所有DNS服务节点生效，需要等待DNS服务器缓存过期后向源服务器更新新的记录才能实现。
如何解决缓存一致性?
（1）更新数据库，不更新缓存
（2）先删除缓存，再更新数据库
删除缓存不更新缓存的理由
选择更新缓存(数据不但写入数据库，还会写入缓存)还是删除缓存呢？主要取决于“更新缓存的复杂度”,更新缓存的代价很大,那么更倾向于删除缓存。删除缓存操作简单，并且带来的副作用只是增加了一次cache miss，建议作为通用的处理方式。
先删除缓存，再更新数据库的理由
(1)假设先更新数据库，再删除缓存
第一步写更新数据库成功，第二步删除缓存失败，则会出现DB中是新数据，Cache中是旧数据，数据不一致。
(2)假设先淘汰缓存，再写数据库
第一步删除缓存成功，第二步更新数据库失败，那没关系，起码数据是一致的。
缓存穿透，缓存雪崩，缓存击穿
缓存穿透
定义：
一般是黑客故意去请求缓存中不存在的数据，导致所有的请求都落到数据库上，造成数据库短时间内承受大量请求而崩掉（在流量大时，可能DB就挂掉了）。
实战说明:
我们在项目中使用缓存通常都是先检查缓存中是否存在，如果存在直接返回缓存内容，如果不存在就直接查询数据库然后再缓存查询结果返回。这个时候如果我们查询的某一个数据在缓存中一直不存在，就会造成每一次请求都查询DB，这样缓存就失去了意义，在流量大时，可能DB就挂掉了。要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。
解决方案：
（1）缓存空对象，设置短暂的过期时间, 简单粗暴的方法（项目常用），如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。
（2）布隆过滤器拦截, 将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。
（3）还有一个比较巧妙的作法是，可以将这个不存在的key预先设定一个值，比如，"key" , “&&”。在返回这个&&值的时候，我们的应用就可以认为这是不存在的key，那我们的应用就可以决定是否继续等待继续访问，还是放弃掉这次操作。如果继续等待访问，过一个时间轮询点后，再次请求这个key，如果取到的值不再是&&，则可以认为这时候key有值了，从而避免了透传到数据库，从而把大量的类似请求挡在了缓存之中。
缓存雪崩(缓存失效)
定义
是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。
实战说明
引起这个问题的主要原因还是高并发的时候，平时我们设定一个缓存的过期时间时，可能有一些会设置1分钟啊，5分钟这些，并发很高时可能会出在某一个时间同时生成了很多的缓存，并且过期时间都一样，这个时候就可能引发一但过期时间到后，这些缓存同时失效，请求全部转发到DB，DB可能会压力过重。
解决方案
(1) 大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上。
(2) 随机过期时间，降低过期时间的重复率。简单方案,就是将缓存失效时间分散开，比如我们可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。
缓存击穿
定义
缓存在某个时间点过期的时候，恰好在这个时间点对某个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端DB压垮。
补充：和缓存雪崩的区别在于缓存击穿针对某一个key缓存，前者则是很多key。
解决方案
我们的目标是：尽量少的线程构建缓存(甚至是一个) + 数据一致性 + 较少的潜在危险，下面会介绍四种方法来解决这个问题：
1、使用互斥锁(mutex key):
这种解决方案思路比较简单，就是只让一个线程构建缓存，其他线程等待构建缓存的线程执行完，重新从缓存获取数据就可以了（如下图）
如果是单机，可以用synchronized或者lock来处理，如果是分布式环境可以用分布式锁就可以了（分布式锁，可以用memcache的add, redis的setnx, zookeeper的添加节点操作）。
redis的setnx(伪代码实现)
2、"提前"使用互斥锁(mutex key)：
在value内部设置1个超时值(timeout1), timeout1比实际的memcache timeout(timeout2)小。当从cache读取到timeout1发现它已经过期时候，马上延长timeout1并重新设置到cache。然后再从数据库加载数据并设置到cache中。
3、"永远不过期"：
这里的“永远不过期”包含两层意思：
1、从redis上看，确实没有设置过期时间，这就保证了，不会出现热点key过期问题，也就是“物理”不过期。
2、从功能上看，如果不过期，那不就成静态的了吗？所以我们把过期时间存在key对应的value里，如果发现要过期了，通过一个后台的异步线程进行缓存的构建，也就是“逻辑”过期。
4、资源保护：
netflix的hystrix，可以做资源的隔离保护主线程池，如果把这个应用到缓存的构建也未尝不可。
参考/好文:
缓存穿透，缓存雪崩，4种解决方案分析 --
https://mp.weixin.qq.com/s/Q9ROd6nH_tPPuo6Hzv3BGg
数据库缓存最终一致性的四种方案，你真的了解过吗？ --
https://stor.51cto.com/art/201909/602413.htm
缓存与数据库一致性之缓存更新设计 --