Redis与数据库的爱恨纠葛
Redis 是完全开源的，遵守 BSD 协议，是一个高性能的 key-value 数据库。
早期数据库只要有数据库的操作---增--删--改--查
当用户量特别多的情况下，数据库的数量一定是跟不上用户的数量，对数据库来说是特别繁忙的
看着每天都累趴下的数据库，顿时有种心疼的感觉。
对数据库操作进行了分析，发现读取的业务大于其它业务的总和，那为给数据库介绍了一个专门干缓存的对象----redis
redis
- 性能极高 – Redis能读的速度是110000次/s,写的速度是81000次/s 。
- 丰富的数据类型 – Redis支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作。
- 原子 – Redis的所有操作都是原子性的，意思就是要么成功执行要么失败完全不执行。单个操作是原子性的。多个操作也支持事务，即原子性，通过MULTI和EXEC指令包起来。
- 丰富的特性 – Redis还支持 publish/subscribe, 通知, key 过期等等特性。
自从给数据库分配了对象之后，大量的读取内容都登记在redis中，后续有相同的读取可以直接找redis要了，不用再跑数据库进行I/O操作了，数据库顿时感觉到了工作轻松了不少
redis缓存过期
Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，而内存是有限的，如果一直存下去，迟早会有溢满的情况
那能不能清理掉一些老旧过期的数据呢？好像是可行了，那怎么让redis知道它们是老旧的数据呢？
如果我们给这个数据加上标识，那不就可以知道了吗，那又出来一个问题，我们这个数据要使用多久什么时候过期，----------不如就把这个标识改成它的过期时间，只要到了过期时间我们就去把这个数据给删除掉
那redis清理缓存最简单的就是定期清理的比如1000ms去清理一次这个已经过期的缓存，但是如果redis有1000个缓存，redis没有办法一次性清理完毕否则会影响到其它业务的正常存取，为了兼容redis每次只能随机清理100个，能保证缓解一定的内存压力
那么又出来了一个问题既然是随机删的话，我一边删一边又有新的数据过期，那有没有一种可能，redis有一部分数据已经不需要了也长时间没有随机到它，成了漏网之鱼，又霸占着内存
如果再做个一旦遇到查询请求，发现已经超期了，就立即删除，惰性删除,被动触发时发现就删除，但是也会存在一直不被请求到但是也一直在随机之外的过期数据(缓存数据几千上万是非常大概率出现这种漏中漏的漏网之鱼)
缓存淘汰
缓存过期这种情况非常有可能把我们的内存溢满，就算能非常好的处理完这些过期数据，但是还是有一种情况
redis还没过期的时候，数据量redis的内存就给溢满了，怎么办？
volatile-lru：针对设置了过期时间的key，使用LRU算法进行淘汰
allkeys-lru：针对所有key使用LRU算法进行淘汰
volatile-lfu：针对设置了过期时间的key，使用LFU算法进行淘汰
allkeys-lfu：针对所有key使用LFU算法进行淘汰
volatile-random: 从设置了过期时间的key中随机删除
allkeys-random: 从所有key中随机删除
volatile-ttl：删除生存时间最近的一个键
noeviction（默认策略）：不删除键，返回错误OOM，只能读取不能写入
LRU
Least Recently Used 最近很少使用(最长时间)
LFU
Least Frequently Used最少使用(最少频率) 在LRU的算法上加了次数
图1：
当我输入为5的时候，我需要删除一个数字，我这个时候按LRU算法来 我应该删出的是2，因为3在2出现之后再出现了一次距离5出现的时间比2近
如果按LFU算法 我应该删除的是4 因为3我使用了3次，2我使用2次，4只出现了一次，频率最低
图2：
当图2情况下 输入到5的情况下，我需要删除一个数字
LRU 删除2
LFU 这个删除的就是4了，首先按频率来3出现最多 4和1出现次数相同，但是 还会按LRU算法来算一次，1距离5比4距离5的时间短
缓存穿透
当查询的数据不存在时，redis里面也没有缓存，就会去数据库里面查询，但是也有可能数据库也不存在，导致同样的请求来了每次都要去让 MySQL 白忙活一场。作为缓存的价值就没得到体现啦！这就是人们常说的缓存穿透。
解决方案
(1)布隆过滤器
在控制层对请求先进行校验，不符合条件的请求则被丢弃，从而避免对持久层数据库造成的查询压力。
(2)缓存空对象
当查询的数据不存在于redis中时，请求到了持久层数据库中去查询数据，但查询不出数据，这时会返回空对象，同时把该空对象缓存到redis里，然后设置一个过期时间，往后只要再次请求查询该条数据，该条数据都会从redis中获取(获取redis返回的空对象)，从而保护了后端的数据源。
缓存击穿
redis里面有一个高频的热点key，可能有大量的访问针对这个key进行访问，如果这个key在某个时间过期了，会导致大量的请求越过redis直接作用在数据库上，而数据库连接资源有限，直接导致其它业务宕机
解决方案:
(1)设置热点key永不过期。
(2)加锁对redis与数据库中间加锁，保证每次只有可控的线程数量访问，其它线程等待
缓存雪崩
这个相对缓存击穿更加严重，多个key在统一时间批量失效或者redis直接宕机，导致大批量/所有访问直接作用在数据库上，导致数据库直接挂掉，或者其它大量服务宕机
解决方案:
(1)redis高可用
1.主从
2.哨兵
3.集群
(2)限流降级：通过加锁或队列来控制读取持久层数据库的线程数量
(3)数据预热：预先把可能被大量访问的数据加载到缓存中，并给这些key设置不同的过期时间，让key失效的时间点尽量均匀开来。