Redis面试核心
主流应用架构
缓存中间件——Memcache和Redis的区别
Memcache:代码层次类似Hash
1、支持简单数据类型
2、不支持数据持久化存储（宕机数据会丢失）
3、不支持主从
4、不支持分片
Redis
1、数据类型丰富
2、支持数据磁盘持久化存储
3、支持主从
4、支持分片
为什么Redis能这么快
100000+QPS（QPS即query per second，每秒内查询次数）
1、完全基于内存，绝大部分请求是纯粹的内存操作，执行效率高
2、数据结构简单，对数据操作也简单
3、采用单线程，单线程也能处理高并发请求，想多核也可启动多实例
4、使用多路I/O复用模型，非阻塞IO
多路I/O复用模型
FD: File Descriptor，文件描述符
一个打开的文件通过唯一的描述符进行引用，该描述符是打开文件的元数据到文件本身的映射
Redis采用的I/O多路复用函数：epoll/kqueue/evport/select?
1、因地制宜
2、优先选择时间复杂度为O(1)的I/O多路复用函数作为底层实现
3、以时间复杂度为O(n)的select作为保底
4、基于react设计模式监听I/O事件
Redis的数据类型
1、String：最基本的数据类型，二进制安全
2、Hash：String元素组成的字典，适合用于存储对象
3、List：列表，按照String元素插入顺序排序
4、Set：String元素组成的无序集合，通过哈希表实现，不允许重复
5、Sorted Set：通过分数来为集合中的成员进行从小到大的排序
6、用于计数的HyperLogLog，用于支持存储地理位置信息的Geo
从海量key里查询出某一固定前缀的Key
留意细节
摸清数据规模，即问清楚边界
小量数据用keys，大量数据用scan cursor
批量删除某一固定前缀的key
/opt/redis/bin/redis-cli -a '' keys "sale*" | xargs redis-cli -a '
' del
使用keys对线上的业务的影响
keys pattern：查找所有符合给定模式pattern的key
1、keys指令一次性返回所有匹配的key
2、键的数量过大会使服务卡顿
scan cursor[match pattern][count count]
1、基于游标的迭代器，需要上一次的游标延续之前的迭代过程
2、以0作为游标开始一次新的迭代，直到命令返回游标0完成一次遍历
3、不保证每次执行都返回某个给定数量的元素，支持模糊查询
4、一次返回的数量不可控，只能是大概率符合count参数
Redis实现分布式锁
分布式锁需要解决的问题
1、互斥性（只能有一个客户端获取锁）
2、安全性（锁只能由持有该客户端释放）
3、死锁（持有该锁的客户端因为特殊原因宕机，导致其他客户端无法获取锁）
4、容错（当部分节点宕机，客户端也能获取锁释放锁）
setnx key value：如果key不存在，则创建并赋值
1、时间复杂度：O（1）
2、返回值：设置成功，返回1；设置失败，返回0。
因为setnx 有如此特性，而且操作是原子性的，所以“初期”的时候被大家用来作为分布式锁
解决setnx长期有效的问题
expire key seconds
1、设置key的生存时间，当Key过期时（生存时间为0），会被自动删除
2、缺点：原子性得不到满足，当设置完key后宕机，程序还没来得及设置过期时间，就会出现问题
解决setnx与expire 原子性问题
SET key value [EX seconds][PX milliseconds][NX|XX]
1、EX second：设置键的过期时间为second秒
2、PX millisecond：设置键的过期时间为millisecond毫秒
3、NX：只在键不存在时，才对键进行设置操作
4、XX：只在键存在时，才对键进行设置操作
5、SET操作成功完成时，返回OK，反则返回nil
大量的key同时过期的注意事项
集中过期，由于消除大量的key很耗时，会出现短暂的卡顿现象
网上解决方案：在设置key的过期时间的时候，给每个key加上随机值。实在没这个必要，程序的访问非线性，每次设置key的时候访问时间都是不定的，这实际上key的到期时间也是随机的。
如何使用Redis做异步队列
使用List作为队列，RPUSH生产消息，LPOP消费消息
缺点：没有等待队列里有值就直接消费
弥补：可以通过在应用层印入Sleep机制去调用LPOP重试
BLPOP key[key ...] timeout:阻塞直到队列有消息或者超时
缺点：只能供一个消费者消费
pub/sub：主题订阅者模式（一对多）
1、发送者(pub)发送消息，订阅者(sub)接受消息
2、订阅者可以订阅任意数量的频道
缺点：消息的发布是无状态的，无法保证可达
Redis如何做持久化
RDB（快照）持久化：保存某个时间点的全量数据快照
1、save：阻塞Redis的服务器进程，直到RDB文件被创建完毕
2、BGSAVE：Fork出一个子进程来创建RDB文件，不阻塞服务器进程
3、自动触发持久化：根据redis.conf配置里的SAVE m n定时触发（用的是BGSAVE，m间隔秒数，n是间隔秒数内写入次数，save 900 1(900秒内触发1次写入就会持久化)）
4、主从复制时，主节点自动触发
5、执行Debug Reload
6、执行Shutdown且没有开启AOF持久化
BGSAVE原理
Copy-on-Write
RDB持久化缺点
1、内存数据的全量同步，数据量大会由于I/O而严重影响性能
2、可能会因为Redis挂掉而丢失当前至最近一次快照期间的数据
AOF(Append-Only-File)持久化：保存写状态
1、记录下除了查询以外的所有变更数据库状态的指令
2、以append的形式追加保存到AOF文件中（增量）
日志重写解决AOF文件大小不断增大的问题，原理如下：
1、调用fork()，创建一个子进程
2、子进程把新的AOF写到一个临时文件里，不依赖原来的AOF文件
3、主进程持续将新的变动同时写到内存和原来的AOF里
4、主进程获取子进程重写AOF的完成信号，往新AOF同步增量变动
5、使用新的AOF文件替换旧的AOF文件
RDB和AOF的优缺点
1、RDB优点：全量数据快照，文件小，恢复快
2、RDB缺点：无法保存最近一次快照之后的数据
3、AOF优点：可读性高，适合保存增量数据，数据不易丢失
4、AOF缺点：文件体积大，恢复时间长
Redis4.0后出现RDB-AOF混合持久化方式为默认配置
BGSAVE做镜像全量持久化，AOF做增量持久化
使用Pipline的好处
1、Pipline和linux的管道类似
2、Redis基于请求/响应模型，单个请求处理需要一一应答
3、Pipeline批量执行指令，节省多次IO往返的时间
4、有顺序依赖的指令建议分批发送
Redis的同步机制
全同步过程
1、Slave发送sync命令到Master
2、Master启动一个后台进程，将Redis中的数据快照保存到文件中
3、Master将保存数据快照期间接收到的写命令缓存起来
4、Master完成写文件操作后，将该文件发送给Slave
5、使用新的RDB文件替换掉旧的RDB文件
6、Master将这期间收集的增量写命令发送给Slave端
增量同步过程
1、Master接收到用户的操作指令，判断是否需要传播到Slave
2、将操作记录追加到AOF文件
3、将操作传播到其他Slave（1、对齐主从库；2、往相应缓存写入指令）
4、将缓存中的数据发送给Slave
Redis Sentinel（哨兵模式）
解决主从同步Master宕机后的主从切换问题：
1、监控：检查主从服务器是否运行正常
2、提醒：通过API向管理员或者其他应用程序发送故障通知
3、自动故障迁移：主从切换
流言协议Gossip
在杂乱无章中寻求一致
1、每个节点都随机地与地方通信，最终所有节点的状态达成一致
2、种子节点定期随机向其他节点发送节点列表以及需要传播的消息
3、不保证信息一定会传递给所有节点，但是最终会趋于一致
Redis的集群原理
如何从海量数据里快速找到所需？
1、分片：按照某种规则去划分数据，分散存储在多个节点上
2、常规的按照哈希划分无法实现节点的动态增减（关掉一个节点会令部分key出现miss）
为了解决常规哈希算法的问题，Redis出现了一致性哈希算法：对2^32取模，将哈希值空间组织成虚拟的圆环
一致性哈希会出现数据倾斜问题，用虚拟节点解决
