剑指Java面试-Redis整理（不定期更新！）

一、Redis简介

1.缓存中间件-Memcache和Redis的区别

Memcache：代码层次类似Hash

• 支持简单数据类型
• 不支持数据持久化存储
• 不支持主从
• 不支持分片

Redis：

• 数据类型丰富
• 支持数据磁盘持久化存储
• 支持主从
• 支持分片

2.为什么Redis能这么快

100000+QPS（QPS即query per second，每秒内查询次数）

• 完全基于内存，绝大部分请求是纯粹的内存操作，执行效率高
• 数据结构简单，对数据操作也简单
• 采用单线程，单线程也能处理高并发请求，想多核也可启动多实例
• 使用多路I/O复用模型，非阻塞IO

3.多路I/O复用模型

FD：File Descriptor，文件描述符

一个打开的文件通过唯一的描述符进行引用，该描述符是打开文件的元数据到文件本身的映射。

传统的阻塞IO模型

系统调用

Redis采用的多路IO复用模型

Redis采用的IO多路复用函数：epoll/kueue/evport/select

• 因地制宜
• 优先选择时间复杂度为O（1）的IO多路复用函数作为底层实现
• 以时间复杂度为O（n）的select作为保底
• 基于react涉及模式监听IO事件

二、Redis常用的数据类型

可以参考我之前整理的博文：

内容	连接地址
Redis五大基础数据结构	https://blog.csdn.net/weixin_43519048/article/details/101173849
Redis分布式锁与延时队列	https://blog.csdn.net/weixin_43519048/article/details/101173935
Redis位图与 HyperLogLog	https://blog.csdn.net/weixin_43519048/article/details/101174038

这里简单概括一下：
供用户使用的数据类型：

• String：最基本的数据类型，二进制安全
• Hash：String元素组成的字典，适合用于存储对象
• List：列表，按照String元素插入顺序排序
• Set：String元素组成的无序集合，通过哈希表实现，不允许重复
• Sorted Set：通过分数来为集合中的成员进行从小到大的排序
• 用于计数的HyperLogLog，用于支持存储地理位置信息的Geo

三、从海量key里查询出某一个固定前缀的key

一定要留意细节

• 要摸清数据规模，即一定要问清楚数据边界（数据量多大）

1. KEYS指令

KEYS pattern
查找所有符合给定模式pattern的key

• KEYS指令一次性返回所有匹配的key
• 键的数量过大会使服务卡顿

2. SCAN指令

SCAN cursor [MATCH pattern] [COUNT count]

• 基于游标的迭代器，需要基于上一次的游标延续之前的迭代过程
• 以0作为游标开始一次新的迭代，直到命令返回游标0完成一次遍历
• 不保证每次执行都返回某个给定数量的元素，支持模糊查询
• 一次返回的数量不可控，只能是大概率符合count参数

四、如何通过Redis实现分布式锁

可参考我之前整理的博文：Redis分布式锁与延时队列

分布式锁需要解决的问题

• 互斥性
• 安全性
• 死锁
• 容错

1.SETNX 指令

SETNX key value ：如果key不存在，则创建并赋值

• 时间复杂度：O（1）
• 返回值：设置成功，返回1；设置失败，返回0.

2.如何解决SETNX长期有效的问题

EXPIRE key seconds

• 设置key的生存时间，当key过期时（生存时间为0，会被自动删除）
• 缺点：原子性得不到满足

RedisService redisService = SpringUtils.getBean(RedisService.class)
long status = redisService.setnx(key,"1");
//俩条指令原子性得不到满足
if(status == 1){
	redisService.expire(key,expire);
	doOcuppiedWork();
}

SET key value [EX seconds] [PX milliseconds] [NX|XX]

• EX second：设置键的过期时间为second秒
• PX millisecond：设置键的过期时间为millisecond毫秒
• NX：只在键不存在时，才对键进行设置操作
• XX：只在键已经存在时，才对键进行设置操作
• SET操作成功完成时，返回OK，否则返回nil

3.大量的key同时过期的注意事项

集中过期，由于清除大量的key很耗时，会出现短暂的卡顿现象。
解决方案：在设置key 的过期时间的时候，给每个key加上随机值

五、Redis如何实现异步队列

适用List作为队列，RPUSH生产消息，LPOP消费消息

• 缺点：没有等待队列里右值就直接消费
• 弥补：可以通过在应用层引入Sleep机制去调用LPOP重试

1.不想通过Sleep方式去重试怎么办

BLPOP key [key ...] timeout
阻塞直到队列有消息或者超时

• 缺点：只能供一个消费者消费

Pub/Sub：主题订阅者模式

• 发送者（pub）发送消息，订阅者（sub）接收消息
• 订阅者可以订阅任意数量的频道
• 缺点：消息的发布是无状态的，无法保证可达

六、Redis的持久化

• RDB（快照）持久化：保存某个时间点的全量数据快照
• AOF（Append-Only-File）持久化：保存写状态

1. RDB（快照）

RDB（快照）持久化：保存某个时间点的全量数据快照

• SAVE：阻塞Redis的服务器进程，直到RDB文件被创建完毕
• BGSAVE：Fork出一个子进程来创建RDB文件，不阻塞服务器进程

自动化触发RDB持久化的方式

• 根据redis.conf配置里的SAVE m n定时触发（用的是BGSAVE）
• 主从复制时，主节点自动触发
• 执行Debug Reload
• 执行Shutdown 且没有开启AOF持久化

BGSAVE原理

• 系统调用fork()：创建进程，实现了Copy-on-Write

Copy-on-Write

如果有多个调用者同时要求相同资源（如内存或者磁盘上的数据存储），她们会共同获取相同的指针指向相同的资源，直到某个调用者试图修改资源的内容时，系统才会真正复制一个专用的副本给该调用者，而其他调用者所见到的最初的资源仍然保持不变。

RDB缺点

• 内存数据的全量同步，数据量大会由于IO而严重影响性能
• 可能会因为Redis挂掉而丢失从当前至最近以此的快照期间的数据

2. AOF

AOF（Append-Only-File）持久化：保存写状态

• 记录下除了查询以外的所有变更数据库状态的指令
• 以append的形式追加保存到AOF文件中（增量）

AOF日志重写

日志重写解决AOF文件大小不断增大的问题，原理如下：

1. 调用fork（），创建一个子进程
2. 子进程把新的AOF写到一个临时文件里，不依赖原来的AOF文件
3. 主进程持续将新的变动同时写道内存和原来的AOF里
4. 主进程获取子进程重写AOF的完成信号，往新的AOF同步增量变动
5. 使用新的AOF文件替换掉旧的AOF文件

3.Redis数据的恢复

RDB和AOF文件共存情况下的恢复流程

4.RDB和AOF的优缺点

• RDB优点：全量数据快照，文件小，恢复快
• RDB缺点：无法保存最近一次快照之后的数据
• AOF优点：可读性高，适合保存增量数据，数据不易丢失
• AOF缺点：文件体积大，恢复时间长

5.RDB-AOF混合持久化方式

• BGSAVE做镜像全量持久化，AOF做增量持久化

七、Pipeline

1. 使用Pipeline的好处

• Pipeline和Linux的管道类似
• Redis基于请求/响应模型，单个请求处理需要一一应答
• Pipeline批量执行指令，节省多次IO往返的时间

2.Redis的同步机制

全量同步过程

1. Salve发送sync命令到Master
2. Master启动一个后台进程，将Redis中的数据快照保存到文件中
3. Master将保存数据快照期间接收到的写命令缓存起来
4. Master完成写文件操作后，将该文件发送给Salve
5. 使用新的AOF文件替换掉旧的AOF文件
6. Master将这期间收集的增量写命令发送给Salve端

增量同步过程

1. Master接收到用户的操作指令，判断是否需要传播到Slave
2. 将操作记录追加到AOF文件
3. 将操作传播到其他Slave：1、对齐主从库；2、往响应缓存写入指令
4. 将缓存中的数据发送给Slave

Redis Sentinel

解决主从同步Master宕机后的主从切换问题：

• 监控：检查主从服务器是否运行正常
• 提醒：通过API向管理员或者其他应用程序发送故障通知
• 自动故障迁移：主从切换

流言协议Gossip

在杂乱无章中寻求一致

• 每个节点都随机地与对方通信，最终所有节点的状态达成一致
• 种子节点定期随机向其他节点发送节点列表以及需要传播的消息
• 不保证消息一定会传递给所有的节点，但是最终会趋于一致

八、Redis的集群原理

如何从海量数据里快速找到所需？

• 分片：按照某种规则去划分数据，分散存储在多个节点上
• 常规的按照哈希划分无法实现节点的动态增减

1.一致性哈希算法：

对2^32取模，将哈希值空间组织成虚拟的圆环
0和2^32-1 重合
我们把有2^32个数字组成的圆环称为Hash环

将数据key使用相同的函数Hash计算出哈希值

例如我们有四个服务器，四个服务器Node ABCD在环上的位置如下图所示：
根据我们的一致性Hash算法，数据Object A离Node A最近，所以该数据就会存在Node A上，以此类推。

假设，Node C宕机，此时Node A、B、D并不会受到影响，只有Node C（这里指的是Object C）的对象会重新定位到Node D上。
当一台服务器宕机时，受影响的数据，只有该服务器逆时针行走到上一个服务器节点的数据，其它的数据是不会受影响的，而且受影响的数据会存储在该宕机服务器的顺时针行走的下一个服务器上。

新增一台服务器Node X，同上面原理一样。

综上所述，一致性哈希算法对于节点的增减，只需要重新定位环空间中的一小部分数据，具有较好的容错性和扩展性。

但是一致性Hash算法也不是十全十美的。
Hash环的数据倾斜问题：
在服务器节点较少的情况下，容易因为节点分布不均匀而造成数据倾斜问题。

• 数据倾斜：指的是被缓存的对象，大部分集中缓存在某一台服务器上。
  

为了解决数据倾斜问题，引入了虚拟节点。

• 虚拟节点：对每一个节点计算多个Hash，计算结果位置都放置一个此服务器位置。