redis理论

1.redis 的应用场景

会话缓存
消息队列(排行榜，计数)
发布订阅，消息通知
商品列表，评论列表

redis数据类型

String(字符串)，hash(哈希)，list(列表)，set(集合)，zset(有序集合)

redis的持久化方式

1. RDB(快照):每隔一段时间对数据进行快照存储。(会丢失最后一次的快照)
2. AOF:持久化的每次记录对服务器写的操作。当服务器重启的时候会执行这些命令来恢复数据。
    redis还会的文件进行后台重写。以至于AOF文件不会太大。(数据相对完整)
3. 如果两种方式都开启。重启服务，会优先加载AOF文件，因为数据AOF文件相对来说会更加完整。

redis事务

1. WATCH命令可以监控一个或多个键，一旦其中有一个键被修改（或删除），之后的事务就不会执行。监控一直持续到EXEC命令（事务中的命令是在EXEC之后才执行的，所以在MULTI命令后可以修改WATCH监控的键值） 
2. 不支持事务回滚.

redis 缓存穿透

缓存击穿表示恶意用户模拟请求很多缓存中不存在的数据，由于缓存中都没有，导致这些请求短时间内直接落在了数据库上，导致数据库异常。

解决:

布隆过滤器
bloomfilter就类似于一个hashset，用于快速判某个元素是否存在于集合中，其典型的应用场景就是快速判断一个key是否存在于某容器，不存在就直接返回。

redis 雪崩

缓存在同一时间内大量键过期（失效），接着来的一大波请求瞬间都落在了数据库中导致连接异常。

解决方案：

方案1、也是像解决缓存穿透一样加锁排队，实现同上;

方案2、建立备份缓存，缓存A和缓存B，A设置超时时间，B不设值超时时间，先从A读缓存，A没有读B，并且更新A缓存和B缓存;

方案3、设置缓存超时时间的时候加上一个随机的时间长度，比如这个缓存key的超时时间是固定的5分钟加上随机的2分钟，酱紫可从一定程度上避免雪崩问题；

redis 分布式锁

1.在加锁和解锁时一定要保原子性。
加锁时：使用Nx和ex操作，保证加锁和过期时间的原子性。不要是固定字符串，使用随机字符。保证在解锁的时候不会借掉别人的锁。
解锁时：使用脚本，在查询如果正确的时候直接解锁。
脚本是：如果key和uuid都是对的，那么直接解锁
2. 锁的续期，设置锁的时间为一个长时间。将业务代码放到try中。解锁放到finally中。不管业务是奔溃还是成功都会解锁

redis内存淘汰机制

有两大类

1.LRU(长时间没有使用淘汰机制)

共有4种

1. LRU
2. LRU-K
3. 2Q
4. MQ

2.LFU(使用次数最少淘汰机制)

LRU 最简单的内存淘汰机制

1.新数据插入到链表头部；

2.每当缓存命中（即缓存数据被访问），则将数据移到链表头部；

3.当链表满的时候，将链表尾部的数据丢弃。

LRU-K算法

1. 数据第一次被访问，加入到FiFO队列中。
2. 如果数据在历史访问中没有达到K次访问。则按照一定的规则(FIFO,LRU)淘汰。
3. 如果达到K次，将数据索引从历史列队中删除。存放到缓存列队中。并缓存此数据。缓存队列按照时间排序。
4. 缓存队列(LRU)被重新访问后，重新排序。
5. 需要淘汰时,缓存队列(LRU)排在末尾的数据，被淘汰。倒数第K次被访问最久的被淘汰。

2Q算法

1. 新访问的数据插入到FIFO队列；

2. 如果数据在FIFO队列中一直没有被再次访问，则最终按照FIFO规则淘汰；

3. 如果数据在FIFO队列中被再次访问，则将数据移到LRU队列头部；

4. 如果数据在LRU队列再次被访问，则将数据移到LRU队列头部；

5. LRU队列淘汰末尾的数据。

MQ算法

1. 新插入的数据放到Q0中
2. 每隔队列按照LRU来管理数据
3. 当数据访问到一定次数。需要提升优先级，将从当前队列中删除，加入到更高级的队列中。
4. 为了防止高优先级永远不对被删除。所以在一定时间内没有被访问。那么就会降级。从当前列表中删除，加入到低优先级的头部。
5. 需要删除的时候从最低一级的队列开始LRU淘汰。每隔队列淘汰数据时，将从缓存中删除，将数据放到历史队列的头部。
6. 如果历史队列的数据重新被访问，则重新计算其优先级，移动到目标队列的头部。
7. 历史队列也按照LRU淘汰。

LRU 4中算法对比

命中率

LRU-2 > MQ(2) > 2Q > LRU

复杂度

LRU-2 > MQ(2) > 2Q > LRU

代价

LRU-2 > MQ(2) > 2Q > LRU

布隆过滤器

1. 布隆过滤器可以理解成一个不怎额精确的set结构。可以查询对象是否存在。当布隆过滤器说某个值存在的时候，这个值可能不存在。当他说这个值不存在的时候那就肯定不存在。所以有误判的可能。
2. bf.reserve 有三个参数，分别是 key, error_rate 和 initial_size。
3. 提高初始值（initial_size）的元素数量，可以降低误判的概率。
4. 布隆过滤器的 initial_size 估计的过大，会浪费存储空间，估计的过小，就会影响准确率，用户在使用之前一定要尽可能地精确估计好元素数量，还需要加上一定的冗余空间以避
   免实际元素可能会意外高出估计值很多。
5. 布隆过滤器的 error_rate 越小，需要的存储空间就越大，对于不需要过于精确的场合，error_rate 设置稍大一点也无伤大雅。

布隆过滤原理

每个布隆过滤器对应到 Redis 的数据结构里面就是一个大型的位数组和几个不一样的无偏 hash 函数。所谓无偏就是能够把元素的 hash 值算得比较均匀。
向布隆过滤器中添加 key 时，会使用多个 hash 函数对 key 进行 hash 算得一个整数索
引值然后对位数组长度进行取模运算得到一个位置，每个 hash 函数都会算得一个不同的位
置。再把位数组的这几个位置都置为 1 就完成了 add 操作。

向布隆过滤器询问 key 是否存在时，跟 add 一样，也会把 hash 的几个位置都算出
来，看看位数组中这几个位置是否都位 1，只要有一个位为 0，那么说明布隆过滤器中这个
key 不存在。如果都是 1，这并不能说明这个 key 就一定存在，只是极有可能存在，因为这
些位被置为 1 可能是因为其它的 key 存在所致。