当前位置：首页 > article >正文

Redis面试题整理

article 2024/11/13 9:48:20

Redis

1、Redis主从集群

1.1、搭建主从集群

单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

1.2、主从同步原理

当主从第一次同步连接或断开重连时，从节点都会发送psync请求，尝试数据同步：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

replicationID：每一个master节点都有自己的唯一id，简称replid
offset：repl_backlog中写入过的数据长度，写操作越多，offset值越大，主从的offset一致代表数据一致

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

可以从一下几个方面来优化Redis主从就集群：

在master中配置repl-diskless-sync yes启动无磁盘赋值，避免全量同步时的磁盘IO
Redis单节点上的内存占用不要太大，减少RDB导致的过多磁盘IO
适当提高repl_baklog的大小，发现slave宕机时尽快实现故障恢复，尽可能避免全量同步
限制一个master上的slave节点数量，如果实在时太多slave，则可以采用主-从-从链式结构，减少master压力

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

总结：

1、简述全量同步和增量同步区别？

全量同步：master将完整内存数据生成RDB，发送RDB到slave
增量同步：slave提交自己的offset到master，master获取repl_baklog中slave的offset之后的命令给slave

2、什么时候执行全量同步？

slave节点第一次两节master时
slave节点断开时间太久，repl_baklog中的offset已经被覆盖时

3、什么时候执行增量同步？

slave节点断开又恢复，并且在repl_baklog中能找到offset时

1.3、哨兵原理

Redis提供了哨兵（Sentinel）机制来实现主从集群的自动故障恢复。哨兵的具体作业如下：

监控：Sentinel会不断检查您的master和slave是否按预期工作
自动故障切换：如果master故障，Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主
通知：当集群发生故障转移时，Sentinel会将最新节点角色信息推送给Redis客户端

1.3.1、服务状态监控

Sentinel基于心跳机制检测服务状态，每隔1秒钟向集群的每个实例发送ping命令：

主观下线：如果某Sentinel节点发现某实例未在规定时间内响应，则认为该实例主观下线
客观下线：若超过指定数量（quorum）的Sentinel都认为该实例主观下线，则该实例客观下线。quorum值最好超过Sentinel实例数量的一般

1.3.2、选举新的master

一旦发现master故障，Sentinel需要在slave中选择一个作为新的master，选择依据是这样的：

首先判断slave节点与master节点断开时间长短，如果超过指定值（down-after-milliseconds * 10）则会排除该slave节点
然后判断slave节点的slave-priority值，越小优先级越高，如果是0则永不参与选举
如果slave-priority一样，则判断slave节点的offset值，越大说明数据越新，优先级越高
最后是判断slave节点的运行id大小，越小优先级越高

1.3.3、如何实现故障转移

当选中了其中一个slave为新的master后，故障转移的步骤如下：

Sentinel给备选的slave1节点发送slaveof no one命令，让该节点成为master
Sentinel给所有其他slave发送slaveof 192.168.150.101 7002命令，让这些slave成为新的master从节点，开始从新的master上同步数据
最后，Sentinel将故障节点标记为slave，当故障节点恢复后会自动成为新的master的slave节点

总结：

1、Sentinel的三个作用是什么？

监控
故障转移
通知

2、Sentinel如何判断一个redis实例是否健康？

每隔1秒发送一次ping命令，如果超过一定时间没有响应则认为是主观下线
如果大多数Sentinel都认为实例主观下线，则判定服务下线

3、故障转移步骤有哪些？

首先选定一个slave作为新的master，执行slaveof no one
然后让所有节点都执行slaveof 新master
修改故障节点，执行slaveof 新master

1.4、搭建哨兵集群

首先，停掉之前的redis集群：

# 老版本DockerCompose
docker-compose down

# 新版本Docker
docker compose down

然后，配置文件sentinel.conf文件：

sentinel announce-ip "192.168.150.101"
sentinel monitor hmaster 192.168.150.101 7001 2
sentinel down-after-milliseconds hmaster 5000
sentinel failover-timeout hmaster 60000

说明：

sentinel announce-ip "192.168.150.101"：声明当前sentinel的ip
sentinel monitor hmaster 192.168.150.101 7001 2：指定集群的主节点信息
- hmaster：主节点名称，自定义，任意写
- 192.168.150.101 7001：主节点的ip和端口
- 2：认定master下线时的quorum值
sentinel down-after-milliseconds hmaster 5000：声明master节点超时多久后被标记下线
sentinel failover-timeout hmaster 60000：在第一次故障转移失败后多久再次重试

我们在虚拟机的/root/redis目录下新建3个文件夹：s1、s2、s3:

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

将sentinel.conf文件分别拷贝一份到3个文件夹中

接着修改docker-compose.yaml文件，内容如下：

version: "3.2"

services:
  r1:
    image: redis
    container_name: r1
    network_mode: "host"
    entrypoint: ["redis-server", "--port", "7001"]
  r2:
    image: redis
    container_name: r2
    network_mode: "host"
    entrypoint: ["redis-server", "--port", "7002", "--slaveof", "192.168.150.101", "7001"]
  r3:
    image: redis
    container_name: r3
    network_mode: "host"
    entrypoint: ["redis-server", "--port", "7003", "--slaveof", "192.168.150.101", "7001"]
  s1:
    image: redis
    container_name: s1
    volumes:
      - /root/redis/s1:/etc/redis
    network_mode: "host"
    entrypoint: ["redis-sentinel", "/etc/redis/sentinel.conf", "--port", "27001"]
  s2:
    image: redis
    container_name: s2
    volumes:
      - /root/redis/s2:/etc/redis
    network_mode: "host"
    entrypoint: ["redis-sentinel", "/etc/redis/sentinel.conf", "--port", "27002"]
  s3:
    image: redis
    container_name: s3
    volumes:
      - /root/redis/s3:/etc/redis
    network_mode: "host"
    entrypoint: ["redis-sentinel", "/etc/redis/sentinel.conf", "--port", "27003"]

直接运行命令，启动集群：

docker-compose up -d

运行结果：

我们以s1节点为例，查看其运行日志：

# Sentinel ID is 8e91bd24ea8e5eb2aee38f1cf796dcb26bb88acf
# +monitor master hmaster 192.168.150.101 7001 quorum 2
* +slave slave 192.168.150.101:7003 192.168.150.101 7003 @ hmaster 192.168.150.101 7001
* +sentinel sentinel 5bafeb97fc16a82b431c339f67b015a51dad5e4f 192.168.150.101 27002 @ hmaster 192.168.150.101 7001
* +sentinel sentinel 56546568a2f7977da36abd3d2d7324c6c3f06b8d 192.168.150.101 27003 @ hmaster 192.168.150.101 7001
* +slave slave 192.168.150.101:7002 192.168.150.101 7002 @ hmaster 192.168.150.101 7001

可以看到sentinel已经联系到了7001这个节点，并且与其它几个哨兵也建立了链接。哨兵信息如下：

27001：Sentinel ID是8e91bd24ea8e5eb2aee38f1cf796dcb26bb88acf
27002：Sentinel ID是5bafeb97fc16a82b431c339f67b015a51dad5e4f
27003：Sentinel ID是56546568a2f7977da36abd3d2d7324c6c3f06b8d

2、Redis分片集群

2.1、搭建分片集群

主从和哨兵可以解决高可用、高并发读的问题。但是依然有两个问题没有解决：

海量数据存储问题
高并发写的问题

使用分片集群可以解决上述问题，分片集群特征：

集群有多个master，每个master保存不同数据
每个master都可以有多个slave节点
master之间通过ping检测彼此健康状态

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

Redis分片集群最少也需要3个master节点，由于我们的机器性能有限，我们只给每个master配置1个slave，形成最小的分片集群：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

计划部署的节点信息如下：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

2.1.1、集群配置

分片集群中的Redis节点必须开启集群模式，一般在配置文件中添加下面参数：

port 7000
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes

中有3个我们没见过的参数：

cluster-enabled：是否开启集群模式
cluster-config-file：集群模式的配置文件名称，无需手动创建，由集群自动维护
cluster-node-timeout：集群中节点之间心跳超时时间

一般搭建部署集群肯定是给每个节点都配置上述参数，不过考虑到我们计划用docker-compose部署，因此可以直接在启动命令中指定参数，偷个懒。

在虚拟机的/root目录下新建一个redis-cluster目录，然后在其中新建一个docker-compose.yaml文件，内容如下：

version: "3.2"

services:
  r1:
    image: redis
    container_name: r1
    network_mode: "host"
    entrypoint: ["redis-server", "--port", "7001", "--cluster-enabled", "yes", "--cluster-config-file", "node.conf"]
  r2:
    image: redis
    container_name: r2
    network_mode: "host"
    entrypoint: ["redis-server", "--port", "7002", "--cluster-enabled", "yes", "--cluster-config-file", "node.conf"]
  r3:
    image: redis
    container_name: r3
    network_mode: "host"
    entrypoint: ["redis-server", "--port", "7003", "--cluster-enabled", "yes", "--cluster-config-file", "node.conf"]
  r4:
    image: redis
    container_name: r4
    network_mode: "host"
    entrypoint: ["redis-server", "--port", "7004", "--cluster-enabled", "yes", "--cluster-config-file", "node.conf"]
  r5:
    image: redis
    container_name: r5
    network_mode: "host"
    entrypoint: ["redis-server", "--port", "7005", "--cluster-enabled", "yes", "--cluster-config-file", "node.conf"]
  r6:
    image: redis
    container_name: r6
    network_mode: "host"
    entrypoint: ["redis-server", "--port", "7006", "--cluster-enabled", "yes", "--cluster-config-file", "node.conf"]

注意：使用Docker部署Redis集群，network模式必须采用host

2.1.2、启动集群

进入/root/redis-cluster目录，使用命令启动redis：

docker-compose up -d

启动成功，可以通过命令查看启动进程：

ps -ef | grep redis
# 结果：
root       4822   4743  0 14:29 ?        00:00:02 redis-server *:7002 [cluster]
root       4827   4745  0 14:29 ?        00:00:01 redis-server *:7005 [cluster]
root       4897   4778  0 14:29 ?        00:00:01 redis-server *:7004 [cluster]
root       4903   4759  0 14:29 ?        00:00:01 redis-server *:7006 [cluster]
root       4905   4775  0 14:29 ?        00:00:02 redis-server *:7001 [cluster]
root       4912   4732  0 14:29 ?        00:00:01 redis-server *:7003 [cluster]

可以发现每个redis节点都以cluster模式运行。不过节点与节点之间并未建立连接。

接下来，我们使用命令创建集群：

# 进入任意节点容器
docker exec -it r1 bash
# 然后，执行命令
redis-cli --cluster create --cluster-replicas 1 \
192.168.150.101:7001 192.168.150.101:7002 192.168.150.101:7003 \
192.168.150.101:7004 192.168.150.101:7005 192.168.150.101:7006

命令说明：

redis-cli --cluster：代表集群操作命令
create：代表是创建集群
--cluster-replicas 1:指定集群中每个master的副本个数为1
- 此时节点总数 / (replicas + 1)得到的就是master的数量n。因此节点列表中的前n个节点就是master，其它节点都是slave节点，随机分配到不同master

输入命令后控制台会弹出下面的信息：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

这里展示了集群中master与slave节点分配情况，并询问你是否同意，节点信息如下：

7001是master，节点id后6位是da134f
7002是master，节点id后6位是862fa0
7003是master，节点id后6位是ad5083
7004是slave，节点id后6位是391f8b，认ad5083（7003）为master
7005是slave，节点id后6位是e152cd，认da134f（7001）为master
7006是slave，节点id后6位是4a018a，认862fa0（7002）为master

输入yes然后回车吗。会发现集群开始创建，并输出下列信息：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

接着，我们可以通过命令查看集群状态：

redis-cli -p 7001 cluster nodes

结果：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

2.2、散列插槽

在Redis集群中，共有16384个hash slots，集群中的每一个master节点都会分配一定数量的hash slots：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

Redis数据不是与节点绑定，而是与插槽slot绑定。当我们读写数据时，Redis基于CRC16算法对key做hash运算1，得到的结果与16384取余，就计算出这个key的slot值。然后到slot所在的Redis节点执行读写操作.

redis在计算key的hash值是不一定是根据整个key计算，分两种情况：

当key中包含{}中，根据{}之间的字符串计算hash slot
当key中不包含{}时，则根据整个key字符串计算hash slot

例如：key是num，那么就根据num计算，如果是{itcast}num，则根据itcast计算。

总结：

Redis如何判断某个key应该在哪个实例？

将16384个插槽分配到不同的实例
根据key的有效部分计算哈希值，对16384取余
余数作为插槽，寻找插槽所在实例即可

3、Redis数据结构

3.1、RedisObject

Redis中的任意数据类型的值和键都会被封装为一个RedisObject，也叫做Redis对象，源码如下：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

Redis中会根据存储的数据类型不同，选择不同的编码方式，共包含12种不同类型：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

Redis中会根据存储的数据类型不同，选择不同的编码方式。每种数据类型的使用的编码方式如下：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

3.2、SkipList

**SkipList（跳表）**首先是链表，但与传统链表相比有几点差异：

元素按照升序排列存储
节点可能包含多个指针，指针跨度不同。

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

SkipList的特点：

跳跃表是一个有序的双向链表
每个节点都可以包含多层指针，层数是1到32之间的随机数
不同层指针到下一个节点的跨度不同，层数越高，跨度越大
增删改查效率与红黑树基本一致，实现却更简单。但空间复杂度更高

3.3、SortedSet

SortedSet数据结构的特点是：

每组数据都包含score和member
member唯一
可根据score排序

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

总结：SortedSet的底层数据结构是怎样的？

首先SortedSet需要能存储score和member值，而且要快捷的根据member查询score，因此底层有一个哈希白哦，以member为键，以score为value
其次SortedSet还需要能根据score排序，因此底层还维护了一个跳表
当需要根据member查询score时，就去哈希表中查询
当需要根据score排序查询时，则基于跳表查询

4、Redis内存回收

4.1、过期KEY处理

Redis提供了expire命令，给key设置TTL（存活时间）：

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

可以发现，当key的TTL到期以后，再次访问name返回的是null，说明这个key已经不存在了，对应的内存也得到了释放。从而起到内存回收的目的。

这里有两个问题需要思考：

1、Redis是如何知道一个key是否过期呢？

Redis的本身是键值型数据库，其所有数据都存在一个redisDB的结构体中，其中包含两个哈希表：

dict：保存Redis中所有的键值对
expires：保存Redis中所有的设置了过期时间的KEY及其到期时间（写入时间+TTL）

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

2、是不是TTl到期就立即删除了呢？

Redis并不会实时监测key的过期时间，在key过期后立刻删除，而是采用两种延迟删除的策略：

惰性删除：当有命令需要操作一个key的时候，检查该key的存活时间，如果已经过期才执行删除
周期删除：通过一个定时任务，周期型的抽样部分有TTL的key，如果过期则执行删除

周期删除的定时任务执行周期有两种：

SLOW模式：默认执行频率为每秒10次，但每次执行时长不能超过25ms，瘦server.hz参数影响
FAST模式：频率不固定，跟随Redis内部IO时间循环执行。两次任务之间间隔不低于2ms，执行时长不超过1ms

4.2、内存淘汰策略

内存淘汰：就是当Redis内存使用达到设置的阈值时，Redis主动挑选部分key删除以释放更多内存的流程

Redis会在每次处理客户端命令时都会对内存使用情况做判断，如果必要则执行内存淘汰。内存淘汰的策略有：

negeviction:不淘汰任何key，但是内存满时不允许写入新数据，默认就是这种策略
volatile-ttl：对设置了TTL的key，比较key的剩余TTL值，TTl值越小越先被淘汰
allkeys-random：对全体key，随机进行淘汰。也就是直接从db->dict中随机挑选
volatile-random：对设置了TTL的key，随机进行淘汰。也就是从db->expires中随机挑选
allkeys-lru：对全体key，基于LRU算法进行淘汰
volatile-lru：对设置了TTL的key，基于LRU算法进行淘汰
allkeys-lfu：对全体key，基于LFU算法进行淘汰
volatile-lfu：对设置了TTL的key，基于LFU算法进行淘汰

比较容易混淆的有两个：

LRU（Least Recently Used），最近最少使用，用当前时间减去最后一次访问时间，这个值越大则淘汰优先级越高
LFU（Least Frequently Used），最少频率使用，会统计每个key的访问频率，值越小淘汰优先级越高

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

5、Redis缓存

5.1、缓存一致性

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

缓存一致性策略的最佳实践方案：

低一致性需求：使用Redis的key过期清理方案
高一致性需求：主动更新，并以超时剔除作为兜底方案
- 读操作：
  - 缓存命中则直接返回
  - 缓存未命中则查询数据库，并写入缓存，设定超时时间
- 写操作：
  - 先写数据库，然后再删除缓存
  - 要确保数据库与缓存操作的原子性

5.2、缓存穿透

缓存穿透是指客户端请求的数据在数据库中根本不存在，从而导致请求穿透缓存，直接打到数据库的问题。

常见的解决方案有两种：

缓存空对象（最常见）
- 优点：实现简单，维护方便
- 缺点：额外消耗缓存

布隆过滤
- 布隆过滤式一种数据统计的算法，用于检索一个元素是否存在一个集合中。但是布隆过滤无需存储元素到集合，而是把元素映射到一个很长的二进制数位上。
  - 首先需要一个很长的二进制数，默认每一位都是0
  - 然后需要N个不同算法的哈希函数
  - 将集合中的元素根据N个哈希函数做运算，得到N个数字，然后将每个数字对应的bit位标记为1
  - 要判断某个元素是否存在，只需要把元素按照上述方式运算，判断对应的bit位是否为1即可
- 优点：内存占用较少，没有多余key
- 缺点：
  - 实现复杂
  - 存在误判可能（它判断不存在一定不存在，它判断存在不一定存在）