redis之缓存
概念
在一个网站中，我们经常会使用关系型数据库（如MySQL）来存储数据，由于关系型数据的数据是存储在硬盘上的，因此我们对关系型数据库的操作是需要在硬盘上执行的，硬盘的IO 性能是很慢的，因此关系型数据库的性能不大，相比于我们的 NoSQL(如：redis)，这种直接在内存上操作数据的，我们的 redis 则效率很高，因此对于一些热点数据，我们可以存储到 redis 中，由 redis 来分担MySQL的负担
除了引入缓存之外，我们还可以引入更多的机器，部署更多的数据库实例，构成数据库集群.（主从复制，分库分表等…），提高数据库的并发量
注意!
缓存是用来加快“读操作”的速度的.如果是“写操作”，还是要老老实实写数据库，缓存并不能提高写操作的性能.
缓存的更新策略
定期生成
每隔一定的周期（比如一天/一周/一个月），对于访问的数据频次进行统计.挑选出访问频次最高的前N%的数据.
以搜索引擎为例：
用户在搜索引擎中会输入一个“查询词”，有些词是属于高频的，大家都爱搜（鲜花，蛋糕，同城交
友，不孕不育…).有些词就属于低频的，大家很少搜搜索引擎的服务器会把哪个用户什么时间搜了啥词，都通过日志的方式记录的明明白白，然后
每隔一段时间对这期间的搜索结果进行统计（日志的数量可能非常巨大，这个统计的过程可能
需要使用hadoop或者spark等方式完成).从而就可以得到"高频词表".
这种做法实时性较低，对于一些突然情况应对的并不好，比如春节期间，“春晚”这样的词就会成为非常高频的词，而平时则很少会有人搜索“春晚”
实时生成
先给缓存设定容量上限(可以通过Redis配置文件的maxmemory参数设定).
接下来把用户每次查询：
如果在Redis查到了，就直接返回
如果Redis中不存在，就从数据库查，把查到的结果同时也写入Redis。
如果缓存已经满了（达到上限），就触发缓存淘汰策略，把一些“相对不那么热门”的数据淘汰掉。
按照上述过程，持续一段时间之后Redis内部的数据自然就是“热门数据”了.
淘汰策略
FIFO (First In First On)（先进先出）：把缓存中存在时间最久的数据淘汰掉
LRU (Least Recently Used)：将最久未使用的数据淘汰掉，通过记录每个key 的最近访问时间，将最近最久没访问的 key 淘汰掉
LFU (Least Frequently Used)：淘汰访问次数最少的 key
Random 随机淘汰
上面四种是我们的主要的策略，现在我们来看一下 redis 给我们提供了哪些具体的策略：
volatile-lru：当内存不足以容纳新写入数据时，从设置了过期时间的key中使用LRU（最近最少使用）算法进行淘汰
allkeys-lru：当内存不足以容纳新写入数据时，从所有key中使用LRU（最近最少使用）算法进行淘汰.
volatile-lfu：4.0版本新增，当内存不足以容纳新写入数据时，在过期的key中，使用LFU算法进行删除key.
allkeys-lfu：4.0版本新增，当内存不足以容纳新写入数据时，从所有key中使用LFU算法进行淘汰.
volatile-random：当内存不足以容纳新写入数据时，从设置了过期时间的key中，随机淘汰数据.
allkeys-random：当内存不足以容纳新写入数据时，从所有key中随机淘汰数据。
volatile-ttl：在设置了过期时间的key中，根据过期时间进行淘汰，越早过期的优先被淘汰(相当于FIFO，只不过是局限于过期的key)
noeviction：默认策略，当内存不足以容纳新写入数据时，新写入操作会报错。
整体来说Redis提供的策略和我们上述介绍的通用策略是基本一致的.只不过Redis这里会针对“过期key" 和"全部 key" 做分别处理.
缓存预热（Cache preheating）
使用Redis作为MySQL的缓存的时候，当Redis刚刚启动，或者Redis大批key失效之后，此时由于Redis自身相当于是空着的，没啥缓存数据，那么MySQL就可能直接被访问到，从而造成较大的压力。
因此就需要提前把热点数据准备好，直接写入到Redis中.使Redis可以尽快为MySQL撑起保护伞。热点数据可以基于之前介绍的统计的方式生成即可，这份热点数据不一定非得那么“准确"，只要能帮助MySQL抵挡大部分请求即可，随着程序运行的推移，缓存的热点数据会逐渐自动调整，来更适应当前情况.
缓存穿透（Cache penetration）
访问的key在Redis和数据库中都不存在，此时这样的key不会被放到缓存上，后续如果仍然在访问该key,依然会访问到数据库.这就会导致数据库承担的请求太多，压力很大。这种情况称为缓存穿透。
原因可能有几种：
业务设计不合理，比如缺少必要的参数校验环节，导致非法的key也被进行查询了，
开发/运维误操作，不小心把部分数据从数据库上误删了.
黑客恶意攻击.
解决方案：
针对要查询的参数进行严格的合法性校验，比如要查询的key是用户的手机号，那么就需要校验当前key是否满足一个合法的手机号的格式.
针对数据库上也不存在的key，也存储到Redis中，比如value就随便设成一个"".避免后续频繁访问数据库.
使用布隆过滤器先判定key是否存在，再真正查询.
缓存雪崩（Cache avalanche）
什么是缓存雪崩
短时间内大量的key在缓存上失效，导致数据库压力骤增，甚至直接宕机。
产生原因：
大规模 key失效，可能性主要有两种:
Redis挂了.
Redis上的大量的 key同时过期.
为啥会出现大量的key同时过期？
这种和可能是短时间内在Redis上缓存了大量的key，并且设定了相同的过期时间.
解决方案：
部署高可用的Redis集群，并且完善监控报警体系.
不给key设置过期时间或者设置过期时间的时候添加随机时间因子.
缓存击穿（Cache breakdown）
相当于缓存雪崩的特殊情况. 针对热点key，突然过期了，导致大量的请求直接访问到数据库上，甚至引起数据库宕机.
解决方案：
基于统计的方式发现热点key，并设置永不过期。
进行必要的服务降级，例如访问数据库的时候使用分布式锁，限制同时请求数据库的并发数。