Redis笔记，涵盖了 Redis 所有知识点，拿走不谢

一、redis为什么那么快

1. QPS达到10万/秒
2. 用C语言实现
3. 基于内存
4. 单线程，不用线程上下文切换及加锁

1. String，常见的缓存，存储登录session等
2. hash，存储对象，单独修改对象属性
3. List，有序列表，可实现简单的消息队列，阻塞队列
4. Set，分布式去重
5. Zset，也叫做sorted set，有序集合，关联一个double类型的分数，根据分数排序，可实现排行榜、延时队列
6. Stream，redis 5.0后的新数据类型，消费者可分组，一条消息只能被同组的一个消费者消费，但可以被不同组的多个消费者重复消费，借此实现可持久化的发布&订阅功能

1. Cache Aside Pattern
2. 应用程序同时对接缓存、数据库
3. 查询时先查询缓存，缓存未命中则查询数据库，同时更新数据库
4. 更新时先更新数据库，在删除缓存缓存
5. 最常用的模式
6. 会有数据不一致性问题
7. 适用读多写少的场景
8. 两种加载缓存的方式，读到再加载，或者启动时就加载

1. 为什么是先更新数据库再删除缓存，而不是先删除缓存再更新数据库？
2. 为什么是更新数据库后删除缓存，而不是更新缓存？

1. Read/Write Through Pattern
2. 应用程序只对接缓存，由缓存对接数据库，相当于Cache Provider中封装了数据库
3. 查询时若缓存未命中则，则Cache Provider去查询数据库，设置到缓存后再返回
4. 更新时，由Cache Provider同时更新缓存和数据库，这里有事务保证
5. 此模式很耗时，但能保证数据一致性
6. 少见的模式

1. Write Behind
2. 应用程序只更新缓存，不直接更新数据库
3. 在一定时间触发异步的方式写入数据库
4. 类似于MySQL InnoDB 缓冲池的模式
5. 在写入数据库前断电挂机会有丢失数据可能
6. 放大了数据不一致性，但速度很快
7. 适用于高并发写，但对数据一致性要求不高且允许丢失的场景

电商首页热点数据会做缓存，定时任务刷新，所有key失效时间一样。

热点key大面积集中失效，大量请求一下子打到数据库，导致数据库挂掉。

1. 失效时间加随机值，不让它们集中失效
2. 设置热点key永不过期，有更新时就更新缓存
3. 如果Redis是集群部署，可让热点key分布在不同的Redis库中

缓存和数据库中都不存在的数据，被攻击者利用，如id = -1，发起攻击的时候会绕过换过，不断查询数据库。

1. 对参数合法性进行检验
2. 使用布隆过滤器，会有一定误判
3. 数据库查询为null时，可以缓存约定的数据，如“请稍后重试”，缓存时间设置短点，如30秒（防止正常了这个id下有数据了也无法正常使用）
4. 限流

一个热点key，在失效的瞬间，遭遇高并发，大量请求在缓存中查不到，会直接去查数据库

1. 设置热点key永不过期
2. 使用分布式互斥锁，保证在缓存失效时，只有一个请求能查到数据库

数据一致性就是指数据库和缓存的数据一致的问题。

根据三种缓存模式可知，在数据一致性和效率是两个极端，只能取一个中间平衡点。

一般是采用旁路缓存模式，且采用先更新数据库，后删除缓存的方式。

但就这时候还是会有少量请求因为删除缓存不及时而读到旧数据，不过一般都能顺利删除缓存，这已经是对业务影响最轻的做法。

这时候如果允许短期的数据不?致不会影响业务，那么只要下次更新时可以成功，能保证最终?致性就可以，那么可以不用再做处理。

如果还要再完美，可以捕捉删除缓存异常增加重试，对耗时敏感的可以进行异步补偿重试，即放到mq里面监听，但是这样对业务侵入性比较大，也可以采用监听MySQL binlog日志的方式进行重试。

十、布隆过滤器

原理：

一个元素被加入到集合时，通过k个哈希函数将这个元素映射成一个位数组中的k个点，把它们设置为1。

检索时，看这些位置是不是为1就知道这个元素在不在集合中了，如果都是1则可能存在，如果有一个是0则一定不存在。

缺点：

1. 存在误判的肯定，可通过建立白名单来存储误判的元素
2. 删除困难，初始化要把所有合法元素加到过滤器中，删除时设置为0可能会影响其他元素的判断，可通过Count Bloom Filter

1. 使用zookeeper分布式锁保证线程安全
2. 如果也要更新数据库，涉及到双写，就会出现数据一致性问题，可以参考上面的删除key
3. 如果不能删除key，则在更新缓存时比较数据的更新时间

1. 记录内存快照的方式
2. 使用bgsave，fork一个子进程进行，不会阻塞set操作，类似于GC的守护进行
3. Copy On Write，写时复制机制，备份的时候发生写入操作，则备份的是写入之前的数据，所以会有数据丢失
4. 定期进行，一般是5分钟一次，断电可能会丢失较多数据
5. 恢复块、备份久
6. 可能把RDB快照文件定期放到远程存储，一般做冷备
7. RDB备份的文件体积小，恢复很快

1. 日志追加的方式，类似于MySQL innoDB引擎中redo.log，备份当前操作命令
2. 恢复慢、备份块
3. 会不会丢失数据取决于Appendfsync配置，配置为实时备份则每次写操作都会备份，性能低，一般是配置为每秒一次，这样最多是丢失一秒的数据
4. 适合做灾备
5. 随着时间增长，AOF文件会越来越大，Redis提供了日志重写功能，可以压缩命令，重写后新的AOF文件仅包含旧AOF文件命令的最小集合
6. AOF备份的文件体积大，即使经过重写，仍然很大，恢复很慢

Redis 4.0后使用了RDB+AOF混合持久化模式，生成RDB文件重新记录，这时AOF日志不再是全量的，而是增量的日志记录，体积很小。

十四、Redis过期策略

Redis需要删除失效的数据以清空内存，过期策略就是怎么删除过期数据。

1. 定期删除：默认每隔100ms随机抽取部门设置了过期时间的key，检查key是否失效，失效了就删除。（不全部检查是因为效率低，类似于MySQL全表扫描）
2. 惰性删除：当应用程序来查key的时候，检查到key失效就会删除，未失效就返回。

Redis使用定期删除+惰性删除，能保证最终一定会删除过期的key，但是定期删除会有漏网之鱼，而应用程序又很久没来查询就会导致长时间滞留在内存之中，这时需要用到内存淘汰机制。

十五、Redis内存淘汰机制

FIFO：First In First Out，先进先出

LRU：Least Recently Used，最近最少使用，从时间上看很久没有使用的被淘汰

LFU：Least Frequently Used，最不经常使用，从次数上看使用得最少的被淘汰

1. volatile-lru：将设定了超时时间的数据，采用LRU算法将数据提前删除
2. allkeys-lru：对所有的数据采用LRU算法进行删除
3. volatile-lfu：设定超时时间的数据采用LFU算法删除
4. allkeys-lfu：对所有数据采用LFU算法删除
5. volatile-random：设定了超时时间的数据随机删除
6. allkeys-random：所有数据随机删除
7. volatile-ttl：设定了超时时间的数据根据剩余时间少的删除数据
8. noeviction：不删除内存数据，如果内存溢出报错返回（默认策略）

全量同步主要发生在Slave初始化阶段，当启动一台Slave时，它需要连接到Master，把Master数据都复制一份。

1. Slave连接上Master，发送sync命令给到Master。
2. Master执行bgsave，按照全量备份方式生成一份RDB快照，并用内存缓冲区记录此后执行的所有写命令。
3. Master向Slave发送RDB快照。
4. Slave收到RDB文件后，丢弃所有旧数据，并载入收到的快照文件。
5. Master发送完RDB快照就接着发缓冲区中的写命令。
6. Slave载入完RDB快照，就开始接收&执行Master发送过来的写命令。

Master每执行一个写命令就会向Slave发送相同的写命令，Slave接收&执行收到的写命令。

十八、Redis主从复制

主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。redis策略是，无论如何，首先会尝试进行增量同步，如不成功，再要求从机进行全量同步。

主从复制，只是实现了容灾备份，不能故障转移，不是实现高可用。

十九、Redis高可用方案A：哨兵模式+主动复制

哨兵是什么？

1. 哨兵是一个独立的进程。
2. 哨兵的作用主要有两个，A：通过心跳机制监控Redis服务器运行状态，包括Master和Slave。B：当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的哨兵、slave，修改配置文件，让它们切换主机。

1. 当一个哨兵监测到Master宕机，系统并不会马上进行故障切换，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为“主观下线”。
2. 当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行故障切换。
3. 切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为“客观下线”。

1. 优点：实现了容灾备份和自动故障切换，是高可用方案。
2. 缺点：不好在线扩容（Slave可以随时配置多个，提高读并发，但Master只有一个，提高不了写并发），配置麻烦，只有一个主节点对外提供服务，没法支持很高的并发量。

Redis集群是一个由多个主从节点群组组成的分布式服务集群，他具有复制、高可用、分片特性，Redis集群不需要sentinel哨兵，也能完成节点移除和故障转移的功能，需要将每个节点设置成集群模式，这种集群模式没有中心节点，可水平扩展；Redis集群的性能和高可用均优于之前版本的哨兵模式，且集群配置非常简单。

故障切换过程是怎么样的？

1. Redis的所有节点都会保存当前redis集群中的全部主从状态信息，并且每个节点都能够相互通信。
2. 当一个节点发生宕机，则集群中的其他节点通过心跳机制检查Redis节点是否宕机。
3. 当有半数以上的节点认为宕机，则认为主节点宕机，同时由Redis剩余的主节点进入选举机制，投票选举链接宕机的主节点的从机，实现故障迁移。
4. 集群中如果主机宕机，那么从机可以继续提供服务，当主机中没有从机时，则向其它主机借用多余的从机，继续提供服务，如果主机宕机时没有从机可用，则集群崩溃。即：每个节点都至少保持是“一主一从”。

数据存储原理是什么？

1. hash槽存储原理，所有的键根据哈希函数(CRC16[key]&16383)映射到0－16384槽内。
2. 当向redis集群中插入数据时，首先将key进行计算.之后将计算结果匹配到具体的某一个槽的区间内，之后再将数据set到管理该槽的节点中。

二十一、keys命令

1. keys命令可以列出所有符合给定模式 pattern的key
2. 单因为redis是单线程的，使用keys命令会导致线程阻塞一段时间，线上服务停顿，知道指令执行完毕，服务才能恢复，如列出10亿个相同前缀的key时，影响特别大。
3. 可以使用scan指令代替，但会有一定重复，通过代码去重就好。

1. 使用String类型缓存用户登录状态
2. 使用Hash类型缓存一张配置表、字典表
3. 使用setnx+expire+Lua实现分布式锁
4. 使用List类型实现高性能的分页（如文章的评论列表）、简单的消息队列功能
5. 使用Set类型实现分布式全局去重
6. 使用Zset类型实现热榜、排行榜、延时队列功能
7. 使用pub/sub实现简单的发布&订阅功能（不可持久化）
8. 使用Stream类型实现有消费组的发布&订阅功能（可持久化）
9. 使用Bitmap（位图）实现签到、布隆过滤器功能
10. 使用HyperLogLog实现的不精确的去重统计，如PV（页面访问）、UV（用户访问）
11. 使用Geospatial保存地理位置，计算位置距离，实现附近的人功能
12. 使用Pipeline（管道）把一批命令打包好发送到redis一次性执行，减少客户端与 redis 的通信次数来实现降低往返延时时间
13. 使用Lua脚本保证原子性，实现秒杀场景扣除商品库存
14. 使用Set类型实现标签系统