redis缓存相关问题以及解决方案

1.缓存穿透

 1.1缓存穿透定义
 所谓的缓存穿透，正常情况下，我们进行查询操作时，一般都会查询出数据，但是当你查询缓存和数据库压根不存在的数据时，但是请求每次都会打到数据库上面去。
1.2带来的问题
	当黑客用一直请求缓存和数据库都不存在的数据，这时候请求直接打在了数据库上，就会造成数据库压力过大而宕掉。
1.3解决方案
	缓存空值，将请求的空值key加入到缓存中，这样就不用每次都对数据库进行操作
	加入BloomFilter 类似于一个hbase set 用来判断某个元素（key）是否存在于某个集合中。这种方式在大数据场景应用比较多，比如 		  Hbase 中使用它去判断数据是否在磁盘上。还有在爬虫场景判断url 是否已经被爬取过。这种方案可以加在第一种方案中，在缓存之前在加一层 BloomFilter ，在查询的时候先去 BloomFilter 去查询 key 是否存在，如果不存在就直接返回，存在再走查缓存 -> 查 DB。
	注：针对于一些恶意攻击，攻击带过来的大量key 是不存在的，那么我们采用第一种方案就会缓存大量不存在key的数据。此时我们采用第一种方案就不合适了，我们完全可以先对使用第二种方案进行过滤掉这些key。针对这种key异常多、请求重复率比较低的数据，我们就没有必要进行缓存，使用第二种方案直接过滤掉。而对于空数据的key有限的，重复率比较高的，我们则可以采用第一种方式进行缓存。

2缓存击穿

2.1 缓存击穿定义
	在平常高并发的系统中，大量的请求同时查询一个 key 时，此时这个key正好失效了，就会导致大量的请求都打到数据库上面去。这种现象我们称为缓存击穿。
2.2 带来的问题
	当key在某一时刻失效，并且大量请求执行，此时会造成数据的压力剧增
2.3 解决方案
	在高并发中key失效，加入互斥锁，第一个请求执行，其他请求等待，将第一个查询的结果放入缓存，其他请求直接取缓存即可。

3.缓存雪崩

3.1 缓存雪崩定义
	在某一时刻，缓存中的key值大量失效，数据库坚持不住了，就直接挂了，这种情况比如在服务器停掉了，
3.2 解决方案
	事前：使用集群缓存，保证缓存服务的高可用，这种方案就是在发生雪崩前对缓存集群实现高可用，如果是使用 Redis，可以使用 主从+哨兵 ，Redis Cluster 来避免 Redis 全盘崩溃的情况。
	事中：ehcache本地缓存 + Hystrix限流&降级,避免MySQL被打死。使用 ehcache 本地缓存的目的也是考虑在 Redis Cluster 完全不可用的时候，ehcache 本地缓存还能够支撑一阵。使用 Hystrix进行限流 & 降级 ，比如一秒来了5000个请求，我们可以设置假设只能有一秒 2000个请求能通过这个组件，那么其他剩余的 3000 请求就会走限流逻辑。然后去调用我们自己开发的降级组件（降级），比如设置的一些默认值呀之类的。以此来保护最后的 MySQL 不会被大量的请求给打死。
	事后：开启Redis持久化机制，尽快恢复缓存集群，一旦重启，就能从磁盘上自动加载数据恢复内存中的数据

4解决热点数据集中失效问题

	我们在设置缓存的时候，一般会给缓存设置一个失效时间，过了这个时间，缓存就失效了。对于一些热点的数据来说，当缓存失效以后会存在大量的请求过来，然后打到数据库去，从而可能导致数据库崩溃的情况。
	4.1 解决办法
		4.1.1 设置不同的失效时间为了避免这些热点的数据集中失效，那么我们在设置缓存过期时间的时候，我们让他们失效的时间错开。比如在一个基础的时间上加上或者减去一个范围内的随机值。
		4.1.2 互斥锁结合上面的击穿的情况，在第一个请求去查询数据库的时候对他加一个互斥锁，其余的查询请求都会被阻塞住，直到锁被释放，从而保护数据库。但是也是由于它会阻塞其他的线程，此时系统吞吐量会下降。需要结合实际的业务去考虑是否要这么做。