Redis面试题总结

Redis面试题

参考博客： 2021年Redis面试题（持续更新）_GEEK-BANANA-CSDN博客_redis面试题2021

1.Redis是什么？

Redis是一个key-value存储系统，它支持存储的value类型相对更多，包括string、list、set、zset（sorted set --有序集合）和hash。这些数据结构都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，Redis支持各种不同方式的排序。为了保证效率，数据都是缓存在内存中，Redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave（主从）同步。

2.Redis都有哪些使用场景？

Redis是基于内存的nosql数据库，可以通过新建线程的形式进行持久化，不影响Redis单线程的读写操作。
通过list取最新的N条数据。
模拟类似于token这种需要设置过期时间的场景。
发布订阅消息系统。
定时器、计数器。

3.redis 的五大数据类型

Redis 有 5 种数据类型：string (字符串)、list (列表)、set (集合)、hash (哈希) 和 zset (有序集合)。

Redis 的列表相当于 Java 语言里面的 LinkedList ，注意它是链表而 不是数组。这意味着 list 的插入和删除操作非常快，时间复杂度为 O(1)，但是索引定位很慢，时间复杂度为 O(n)，这点让人非常意外。 当列表弹出了最后一个元素之后，该数据结构自动被删除，内存被回收。

Redis 的哈希相当于 Java 语言里面的 HashMap，它是无序字典。内部实现结构上同 Java 的 HashMap 也是一致的，同样的数组 + 链表二维结构。第一维 hash 的数组位置碰撞时，就会将碰撞的元素使用链表串接起来。

Redis 的集合相当于 Java 语言里面的 HashSet，它内部的键值对是无序的唯一的。它的内部实现相当于一个特殊的字典，字典中所有的 value 都是一个值NULL。 当集合中最后一个元素移除之后，数据结构自动删除，内存被回收。

zset 类似于 Java 的 SortedSet 和 HashMap 的结合体，一方面它是一个 set，保证了内部 value 的唯一性，另一方面它可以给每个 value 赋予一个 score，代表这个 value 的排序权重。

4.六种底层数据结构

参考博客： 深入了解 Redis 底层数据结构_TurboSnail-CSDN博客_redis的底层数据结构是什么

简单动态字符串、链表、字典、跳跃表、整数集合、压缩列表

(1)SDS简单动态字符串

Redis是用C语言写的，但是Redis并没有使用C的字符串表示（C是字符串是以\0空字符结尾的字符数组），而是自己构建了一种简单动态字符串（simple dynamic string，SDS）的抽象类型，并作为Redis的默认字符串表示

len：记录当前已使用的字节数（不包括’\0’），获取SDS长度的复杂度为O(1)
alloc：记录当前字节数组总共分配的字节数量（不包括’\0’）
flags：标记当前字节数组的属性，是sdshdr8还是sdshdr16等，flags值的定义可以看下面代码
buf：字节数组，用于保存字符串，包括结尾空白字符’\0’

SDS与C字符串的区别:

• 常数复杂度获取字符串长度

C字符串不记录字符串长度，获取长度必须遍历整个字符串，复杂度为O(N)；而SDS结构中本身就有记录字符串长度的len属性，所有复杂度为O(1)。Redis将获取字符串长度所需的复杂度从O(N)降到了O(1)，确保获取字符串长度的工作不会成为Redis的性能瓶颈。

• 杜绝缓冲区溢出，减少修改字符串时带来的内存重分配次数

C字符串不记录自身的长度，每次增长或缩短一个字符串，都要对底层的字符数组进行一次内存重分配操作。如果是拼接append操作之前没有通过内存重分配来扩展底层数据的空间大小，就会产生缓存区溢出；如果是截断trim操作之后没有通过内存重分配来释放不再使用的空间，就会产生内存泄漏。

而SDS通过未使用空间解除了字符串长度和底层数据长度的关联，3.0版本是用free属性记录未使用空间，3.2版本则是alloc属性记录总的分配字节数量。通过未使用空间，SDS实现了空间预分配和惰性空间释放两种优化的空间分配策略，解决了字符串拼接和截取的空间问题

• 二进制安全

C字符串中的字符必须符合某种编码，除了字符串的末尾，字符串里面是不能包含空字符的，否则会被认为是字符串结尾，这些限制了C字符串只能保存文本数据，而不能保存像图片这样的二进制数据。

而SDS的API都会以处理二进制的方式来处理存放在buf数组里的数据，不会对里面的数据做任何的限制。SDS使用len属性的值来判断字符串是否结束，而不是空字符。

• 兼容部分C字符串函数

虽然SDS的API是二进制安全的，但还是像C字符串一样以空字符结尾，目的是为了让保存文本数据的SDS可以重用一部分C字符串的函数

(2)链表

链表是一种比较常见的数据结构了，特点是易于插入和删除、内存利用率高、且可以灵活调整链表长度，但随机访问困难。许多高级编程语言都内置了链表的实现，但是C语言并没有实现链表，所以Redis实现了自己的链表数据结构。

每个节点listNode可以通过prev和next指针分布指向前一个节点和后一个节点组成双端链表，同时每个链表还会有一个list结构为链表提供表头指针head、表尾指针tail、以及链表长度计数器len，还有三个用于实现多态链表的类型特定函数。

dup：用于复制链表节点所保存的值
free：用于释放链表节点所保存的值
match：用于对比链表节点所保存的值和另一个输入值是否相等

链表特性

• 双端链表：带有指向前置节点和后置节点的指针，获取这两个节点的复杂度为O(1)
• 无环：表头节点的prev和表尾节点的next都指向NULL，对链表的访问以NULL结束
• 链表长度计数器：带有len属性，获取链表长度的复杂度为O(1)
• 多态：链表节点使用 void*指针保存节点值，可以保存不同类型的值

(3)字典

​ 字典，是一种用于保存键值对（key-value pair）的抽象数据结构。字典中的每一个键都是唯一的，可以通过键查找与之关联的值，并对其修改或删除。

dict的ht属性是两个元素的数组，包含两个dictht哈希表，一般字典只使用ht[0]哈希表，ht[1]哈希表会在对ht[0]哈希表进行rehash（重哈希）的时候使用，即当哈希表的键值对数量超过负载数量过多的时候，会将键值对迁移到ht[1]上。

rehashidx也是跟rehash相关的，rehash的操作不是瞬间完成的，rehashidx记录着rehash的进度，如果目前没有在进行rehash，它的值为-1。

(4)跳跃表

​

zskiplistNode结构:

level数组（层）：每次创建一个新的跳表节点都会根据幂次定律计算出level数组的大小，也就是次层的高度，每一层带有两个属性-前进指针和跨度，前进指针用于访问表尾方向的其他指针；跨度用于记录当前节点与前进指针所指节点的距离（指向的为NULL，阔度为0）
backward（后退指针）：指向当前节点的前一个节点
score（分值）：用来排序，如果分值相同看成员变量在字典序大小排序
obj或ele：成员对象是一个指针，指向一个字符串对象，里面保存着一个sds；在跳表中各个节点的成员对象必须唯一，分值可以相同

zskiplist结构:

header、tail表头节点和表尾节点
length表中节点的数量
level表中层数最大的节点的层数

查找元素：

​

添加元素：

通过抛硬币的方式来决定该元素会出现到多少层，也就是说它会有 1/2的概率出现第二层、1/4 的概率出现在第三层…

跳跃表节点的删除和添加都是不可预测的，很难保证跳表的索引是始终均匀的，抛硬币的方式可以让大体上是趋于均匀的

删除元素：

先找到要删除的节点，然后顺藤摸瓜删除每一层相同的节点就好了

跳跃表维持结构平衡的成本是比较低的，完全是依靠随机，相比二叉查找树，在多次插入删除后，需要Rebalance来重新调整结构平衡

(5)整数集合

整数集合（intset）是Redis用于保存整数值的集合抽象数据结构，可以保存类型为int16_t、int32_t、int64_t的整数值，并且保证集合中不会出现重复元素。

整数集合是集合（Set）的底层实现之一，如果一个集合只包含整数值元素，且元素数量不多时，会使用整数集合作为底层实现。

​

contents数组：整数集合的每个元素在数组中按值的大小从小到大排序，且不包含重复项
length记录整数集合的元素数量，即contents数组长度
encoding决定contents数组的真正类型，如INTSET_ENC_INT16、INTSET_ENC_INT32、INTSET_ENC_INT64

整数集合的升级

当想要添加一个新元素到整数集合中时，并且新元素的类型比整数集合现有的所有元素的类型都要长，整数集合需要先进行升级（upgrade），才能将新元素添加到整数集合里面。每次想整数集合中添加新元素都有可能会引起升级，每次升级都需要对底层数组已有的所有元素进行类型转换。

步骤：

• 根据新元素类型，扩展整数集合底层数组的空间大小，并为新元素分配空间
• 把数组现有的元素都转换成新元素的类型，并将转换后的元素放到正确的位置，且要保持数组的有序性
• 添加新元素到底层数组

整数集合的升级策略可以提升整数集合的灵活性，并尽可能的节约内存

另外，整数集合不支持降级，一旦升级，编码就会一直保持升级后的状态

(6)压缩列表

压缩列表（ziplist）是为了节约内存而设计的，是由一系列特殊编码的连续内存块组成的顺序性（sequential）数据结构，一个压缩列表可以包含多个节点，每个节点可以保存一个字节数组或者一个整数值。

zlbytes：记录整个压缩列表占用的内存字节数，在压缩列表内存重分配，或者计算zlend的位置时使用
zltail：记录压缩列表表尾节点距离压缩列表的起始地址有多少字节，通过该偏移量，可以不用遍历整个压缩列表就可以确定表尾节点的地址
zllen：记录压缩列表包含的节点数量，但该属性值小于UINT16_MAX（65535）时，该值就是压缩列表的节点数量，否则需要遍历整个压缩列表才能计算出真实的节点数量
entryX：压缩列表的节点
zlend：特殊值0xFF（十进制255），用于标记压缩列表的末端

​

previous_entry_ength：记录压缩列表前一个字节的长度
encoding：节点的encoding保存的是节点的content的内容类型
content：content区域用于保存节点的内容，节点内容类型和长度由encoding决定

quicklist

Redis 早期版本存储 list 列表数据结构使用的是压缩列表 ziplist 和普通的双向链表linkedlist，也就是元素少时用 ziplist，元素多时用 linkedlist。 考虑到链表的附加空间相对太高，prev 和 next 指针就要占去 16 个字节(64bit 系统的指针是 8 个字节)，另外每个节点的内存都是单独分配，会加剧内存的碎片化，影响内存管理效率。后续版本对列表数据结构进行了改造，使用 quicklist 代替了 ziplist 和 linkedlist。

quickList 是 zipList 和 linkedList 的混合体，它将 linkedList 按段切分，每一段使用 zipList 来紧凑存储，多个 zipList 之间使用双向指针串接起来。

quicklist 内部默认单个 ziplist 长度为 8k 字节，超出了这个字节数，就会新起一个 ziplist。ziplist 的长度由配置参数 list-max-ziplist-size 决定。

5.Redis为什么是单线程的？

代码更清晰，处理逻辑更简单；
不用考虑各种锁的问题，不存在加锁和释放锁的操作，没有因为可能出现死锁而导致的性能问题；
不存在多线程切换而消耗CPU；
无法发挥多核CPU的优势，但可以采用多开几个Redis实例来完善；

6.Redis真的是单线程的吗？

Redis6.0之前是单线程的，Redis6.0之后开始支持多线程；
redis内部使用了基于epoll的多路服用，也可以多部署几个redis服务器解决单线程的问题；
redis主要的性能瓶颈是内存和网络；
内存好说，加内存条就行了，而网络才是大麻烦，所以redis6内存好说，加内存条就行了；
而网络才是大麻烦，所以redis6.0引入了多线程的概念，
redis6.0在网络IO处理方面引入了多线程，如网络数据的读写和协议解析等，需要注意的是，执行命令的核心模块还是单线程的。

7.为什么redis能够快速执行

• 绝大部分请求是纯粹的内存操作（非常快速）
• 采用单线程,避免了不必要的上下文切换和竞争条件
• IO多路复用

参考博客： Redis为何那么快？/多路I/O复用模型，非阻塞IO_JobShow裁员加班实况-微信小程序-CSDN博客_redis非阻塞多路复用

8.Redis的持久化

Redis源码解析：坏了，Redis服崩了，内存中的数据该如何恢复？_小识的博客-CSDN博客_redis崩了

RDB持久化

RDB持久化即通过创建快照（压缩的二进制文件）的方式进行持久化，保存某个时间点的全量数据。RDB持久化是Redis默认的持久化方式。RDB持久化的触发包括手动触发与自动触发两种方式。

AOF持久化

AOF（Append-Only-File）持久化即记录所有变更数据库状态的指令，以append的形式追加保存到AOF文件中。在服务器下次启动时，就可以通过载入和执行AOF文件中保存的命令，来还原服务器关闭前的数据库状态。

RDB、AOF混合持久化

Redis从4.0版开始支持RDB与AOF的混合持久化方案。首先由RDB定期完成内存快照的备份，然后再由AOF完成两次RDB之间的数据备份，由这两部分共同构成持久化文件。该方案的优点是充分利用了RDB加载快、备份文件小及AOF尽可能不丢数据的特性。缺点是兼容性差，一旦开启了混合持久化，在4.0之前的版本都不识别该持久化文件，同时由于前部分是RDB格式，阅读性较低。

Redis 持久化方案的建议
如果Redis只是用来做缓存服务器，比如数据库查询数据后缓存，那可以不用考虑持久化，因为缓存服务失效还能再从数据库获取恢复。

如果你要想提供很高的数据保障性，那么建议你同时使用两种持久化方式。如果你可以接受灾难带来的几分钟的数据丢失，那么可以仅使用RDB。

通常的设计思路是利用主从复制机制来弥补持久化时性能上的影响。即Master上RDB、AOF都不做，保证Master的读写性能，而Slave上则同时开启RDB和AOF（或4.0以上版本的混合持久化方式）来进行持久化，保证数据的安全性。

Redis 持久化方案的优缺点
RDB持久化

优点：RDB文件紧凑，体积小，网络传输快，适合全量复制；恢复速度比AOF快很多。当然，与AOF相比，RDB最重要的优点之一是对性能的影响相对较小。

缺点：RDB文件的致命缺点在于其数据快照的持久化方式决定了必然做不到实时持久化，而在数据越来越重要的今天，数据的大量丢失很多时候是无法接受的，因此AOF持久化成为主流。此外，RDB文件需要满足特定格式，兼容性差（如老版本的Redis不兼容新版本的RDB文件）。

AOF持久化

与RDB持久化相对应，AOF的优点在于支持秒级持久化、兼容性好，缺点是文件大、恢复速度慢、对性能影响大。

9.缓存穿透、缓存击穿、缓存雪崩解决方案

(1)缓存穿透

指查询一个一定不存在的数据，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到 DB 去查询，可能导致 DB 挂掉。

解决方案：

i. 查询返回的数据为空，仍把这个空结果进行缓存，但过期时间会比较短

ii. 布隆过滤器：将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个一定不存在的数据会被这个 bitmap 拦截掉，从而避免了对 DB 的查询。

布隆过滤器

所有可能存在的数据哈希到一个足够大的 bitmap（由01组成） 中，通过哈希函数得出多个索引值，如果均为1，则该数据可能存在（因为该1可能是其他数据的索引），如果存在0，则该数据一定不存在。

布隆过滤器详解 参考博客： 布隆过滤器究竟是什么，这一篇给讲的明明白白的_vincent-CSDN博客_布隆过滤器

(2)缓存击穿

对于设置了过期时间的 key，缓存在某个时间点过期的时候，恰好这时间点对这个 Key 有大量的并发请求过来，这些请求发现缓存过期一般都会从后端 DB 加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把 DB 压垮。

解决方案：

i. 设置热点数据永远不过期。

ii. 加互斥锁，互斥锁：缓存中没有数据，第1个进入的线程，获取锁并从数据库去取数据，没释放锁之前，其他并行进入的线程会等待100ms，再重新去缓存取数据。这样就防止都去数据库重复取数据，重复往缓存中更新数据情况出现。

(3)缓存雪崩

设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到 DB， DB 瞬时压力过重雪崩。与缓存击穿的区别：雪崩是很多 key，击穿是某一个key 缓存。

解决方案：

缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。
如果缓存数据库是分布式部署，将热点数据均匀分布在不同搞得缓存数据库中。
设置热点数据永远不过期。

10.Redis 的集群模式

主从复制

当从数据库启动时，会向主数据库发送sync命令，主数据库接收到sync后开始在后台保存快照rdb，在保存快照期间收到的命令缓存起来，当快照完成时，主数据库会将快照和缓存的命令一块发送给从。复制初始化结束。 之后，主每收到1个命令就同步发送给从。 当出现断开重连后，2.8之后的版本会将断线期间的命令传给从。

主从复制是乐观复制，当客户端发送写执行给主，主执行完立即将结果返回客户端，并异步的把命令发送给从，从而不影响性能。也可以设置至少同步给多少个从主才可写。 无硬盘复制:如果硬盘效率低将会影响复制性能，2.8之后可以设置无硬盘复制，repl-diskless-sync yes

哨兵模式

哨兵的作用：

1、监控redis主、从数据库是否正常运行

2、主出现故障自动将从数据库转换为主数据库。

哨兵的核心知识

1、哨兵至少需要 3 个实例，来保证自己的健壮性。

2、哨兵 + redis 主从的部署架构，是不保证数据零丢失的，只能保证 redis 集群的高可用性。

3、对于哨兵 + redis 主从这种复杂的部署架构，尽量在测试环境和生产环境，都进行充足的测试和演练。

4、配置哨兵监控一个系统时，只需要配置其监控主数据库即可，哨兵会自动发现所有复制该主数据库的从数据库。

11.Redis分布式锁

(1)死锁有哪些情况？

情况1：加锁，没有释放锁。需要加释放锁的操作。比如delete key。

情况2：加锁后，程序还没有执行释放锁，程序挂了。需要用的key的过期机制。

(2)Redis如何做分布式锁？

假设有两个服务A、B都希望获得锁，执行过程大致如下:

Step1： 服务A为了获得锁，向Redis发起如下命令: SET productId:lock 0xx9p03001 NX EX 30000 其中，"productId"由自己定义，可以是与本次业务有关的id，"0xx9p03001"是一串随机值，必须保证全局唯一，“NX"指的是当且仅当key(也就是案例中的"productId:lock”)在Redis中不存在时，返回执行成功，否则执行失败。"EX 30000"指的是在30秒后，key将被自动删除。执行命令后返回成功，表明服务成功的获得了锁。

Step2: 服务B为了获得锁，向Redis发起同样的命令: SET productId:lock 0000111 NX EX 30000
由于Redis内已经存在同名key，且并未过期，因此命令执行失败，服务B未能获得锁。服务B进入循环请求状态，比如每隔1秒钟(自行设置)向Redis发送请求，直到执行成功并获得锁。

Step3: 服务A的业务代码执行时长超过了30秒，导致key超时，因此Redis自动删除了key。此时服务B再次发送命令执行成功，假设本次请求中设置的value值为0000222。此时需要在服务A中对key进行续期。

Step4: 服务A执行完毕，为了释放锁，服务A会主动向Redis发起删除key的请求。注意: 在删除key之前，一定要判断服务A持有的value与Redis内存储的value是否一致。比如当前场景下，Redis中的锁早就不是服务A持有的那一把了，而是由服务2创建，如果贸然使用服务A持有的key来删除锁，则会误将服务2的锁释放掉。此外，由于删除锁时涉及到一系列判断逻辑，因此一般使用lua脚本，具体如下:

if redis.call("get", KEYS[1])==ARGV[1] then
	return redis.call("del", KEYS[1])
else
	return 0
end

(3)红锁算法

需要锁的条件：

1. 多任务环境下。（进程，线程）
2. 任务都对同一共享资源进行写操作。
3. 对资源的访问是互斥的。

操作周期：

1. 竞争锁。获取锁后才能对资源进行操作。
2. 占有锁。操作中。
3. 其他竞争者，任务阻塞。
4. 占有锁者，释放锁。继续从1开始。

用Redis中的多个master实例，来获取锁，只有大多数实例获取到了锁，才算是获取成功。具体的红锁算法分为以下五步：

• 获取当前时间（毫秒数）。
• 按顺序依次向N个Redis节点执行 获取锁 的操作。为了保证在某个Redis节点不可用的时候算法能够继续运行，这个 获取锁 的操作还有一个超时时间(time out)，它要远小于锁的有效时间（几十毫秒量级）。客户端在向某个Redis节点获取锁失败以后，应该立即尝试下一个Redis节点。这里的失败，应该包含任何类型的失败，比如该Redis节点不可用，或者该Redis节点上的锁已经被其它客户端持有。
• 计算整个获取锁的过程总共消耗了多长时间，计算方法是用当前时间减去第1步记录的时间。如果客户端从大多数Redis节点（>= N/2+1）成功获取到了锁，并且获取锁总共消耗的时间没有超过锁的有效时间(lock validity time)，那么这时客户端才认为最终获取锁成功；否则，认为最终获取锁失败。
• 如果最终获取锁成功了，那么这个锁的有效时间应该重新计算，它等于最初的锁的有效时间减去第3步计算出来的获取锁消耗的时间。
• 如果最终获取锁失败了（可能由于获取到锁的Redis节点个数少于N/2+1，或者整个获取锁的过程消耗的时间超过了锁的最初有效时间），那么客户端应该立即向所有Redis节点发起 释放锁 的操作。

释放锁 的过程比较简单：客户端向所有Redis节点发起 释放锁 的操作，不管这些节点当时在获取锁的时候成功与否。

12.内存淘汰机制

redis 内存淘汰机制有以下几个：

• noeviction: 当内存不足以容纳新写入数据时，新写入操作会报错，这个一般没人用吧，实在是太恶心了。
• allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的 key（这个是最常用的）。
• allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个 key，这个一般没人用吧，为啥要随机，肯定是把最近最少使用的 key 给干掉啊。
• volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的 key（这个一般不太合适）。
• volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个 key。
• volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的 key 优先移除。

13.Redis、Mysql数据不一致

采用延时双删策略

要修改数据库数据，需要将缓存中该数据删除，并更新数据库。下次读取该数据时，在缓存中找不到数据，则去数据库找，返回数据，并将该数据存到缓存中。但可能出现下面情况：

• 如果删除了缓存Redis，还没有来得及写库MySQL，另一个线程就来读取，发现缓存为空，则去数据库中读取数据写入缓存，此时缓存中为脏数据。
• 如果先写了库，在删除缓存前，写库的线程宕机了，没有删除掉缓存，则也会出现数据不一致情况。

public void use(String key, Object data){
    redis.delKey(key);
    db.updateData(data);
    Thread.sleep(800);
    redis.delKey(key);
}

（1）先淘汰缓存

（2）再写数据库（这两步和原来一样）

（3）休眠800ms，再次淘汰缓存

这么做，可以将800ms内所造成的缓存脏数据，再次删除。

14.Redis常见性能问题

i. Master最好不要做任何持久化工作，如RDB内存快照和AOF日志文件；(Master写内存快照，save命令调度rdbSave函数，会阻塞主线程的工作，当快照比较大时对性能影响是非常大的，会间断性暂停服务，所以Master最好不要写内存快照;AOF文件过大会影响Master重启的恢复速度)

ii. 如果数据比较重要，某个Slave开启AOF备份数据，策略设置为每秒同步一次

iii. 为了主从复制的速度和连接的稳定性，Master和Slave最好在同一个局域网内

iv. 尽量避免在压力很大的主库上增加从库

v. 主从复制不要用图状结构，用单向链表结构更为稳定，即：Master <- Slave1 <- Slave2 <- Slave3…；这样的结构方便解决单点故障问题，实现Slave对Master的替换。如果Master挂了，可以立刻启用Slave1做Master，其他不变。

15.mySQL里有2000w数据，redis中只存20w的数据，如何保证redis中的数据都是热点数据

volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰

volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰

volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰

allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰

allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰

no-enviction（驱逐）：禁止驱逐数据

使用策略规则：

1、如果数据呈现幂律分布，也就是一部分数据访问频率高，一部分数据访问频率低，则使用allkeys-lru

2、如果数据呈现平等分布，也就是所有的数据访问频率都相同，则使用allkeys-random

16.Redis里面有1亿个key，其中有10w个key是以某个固定的已知的前缀开头的，如何将它们全部找出来？

使用keys指令可以扫出指定模式的key列表。

如果这个redis正在给线上的业务提供服务，那使用keys指令会有什么问题？

redis的单线程的。keys指令会导致线程阻塞一段时间，线上服务会停顿，直到指令执行完毕，服务才能恢复。这个时候可以使用scan指令，scan指令可以无阻塞的提取出指定模式的key列表，但是会有一定的重复概率，在客户端做一次去重就可以了，但是整体所花费的时间会比直接用keys指令长。

17.一致性hash算法

详解： 一致性Hash原理与实现 - 简书 (jianshu.com)

一致性hash算法

一致性Hash算法使用取模的方法，不过，与对服务器的数量进行取模不同，一致性Hash算法是对2的32方取模。即，一致性Hash算法将整个Hash空间组织成一个虚拟的圆环，Hash函数的值空间为0 ~ 2^32 - 1(一个32位无符号整型)。

将数据Key使用相同的函数Hash计算出哈希值，并确定此数据在环上的位置，从此位置沿环顺时针查找，遇到的服务器就是其应该定位到的服务器。

一致性Hash算法的容错性和可扩展性

假设某节点宕机了，多数其他节点不会受到影响，只有该节点中的对象被重新定位到顺时针下一个节点。

假如系统新增了一台服务器，也只需要重定位这个节点之前的数据即可。

总结：一致性Hash算法对于节点的增减都只需重定位环空间中的一小部分数据，有很好的容错性和可扩展性。

数据倾斜问题

在一致性Hash算法服务节点太少的情况下，容易因为节点分布不均匀面造成数据倾斜（被缓存的对象大部分缓存在某一台服务器上）问题。

为了解决数据倾斜问题，一致性Hash算法引入了虚拟节点机制，即对每一个服务器节点计算多个哈希，每个计算结果位置都放置一个此服务节点，称为虚拟节点。

数据定位算法不变，只需要增加一步：虚拟节点到实际点的映射。
所以加入虚拟节点之后，即使在服务节点很少的情况下，也能做到数据的均匀分布。

18.master选举

当salve发现自己的master变为FAIL状态时，尝试进行Failover（故障切换）

当存在多个slave的时候，就需要竞争成为master，过程如下

（1） slave发现自己的master变为FAIL

（2） 将自己记录的集群currentEpock加一，并广播FAILOVER_AUTH_REQUEST信息

（3） 其他小集群的master会相应slave的广播消息，首先判断请求者的合法性，并发送FAILOVER_AUTH_ACK，对每一个epoch只发送一次ack

（4） 尝试failover的slave收集master返回的FAILOVER_AUTH_ACK

（5） Slave受到超过半数的master的ack就成为新的master

（6） Slave广播ping消息通知其他集群节点

Slave节点不是主节点已进入FAIL状态就马上尝试发起选举，而是有一定的延时，一定的延时确保等待FAIL状态在集群中传播。Slave如果立即尝试选举，其它的masters或许尚未意识到FAIL状态，可能会拒绝投票。

延时计算公式：

DELAY = 500ms+random（0~5000ms）+SLAVE_RANK*1000ms

SLAVE_RANK表示此slave已经从master复制数据的总量的rank。Rank越小代表已经复制的数据越新。这种方式下，只有最新数据的slave将会首先发起选举。

Redis集群如果发生脑裂,网络分区导致脑裂后多个主节点对外提供写服务,当网络分区回复,会将其中一个主节点变为从节点,变为从节点之后,回从现有主节点复制数据,那原来的数据就会丢失,redis不像zookeeper有过半机制,是通过配置文件的参数。

min-replicas-to-write 3

min-replicas-max-lag 10

第一个参数表示连接到master的最少slave数量

第二个参数表示slave连接到master的最大延迟时间

按照上面的配置，要求至少3个slave节点，且数据复制和同步的延迟不能超过10秒，否则的话master就会拒绝写请求，配置了这两个参数之后，如果发生集群脑裂，原先的master节点接收到客户端的写入请求会拒绝，就可以减少数据同步之后的数据丢失。

集群为什么至少三个节点而且推荐节点数为奇数
因为选举需要收到大于master节点总数的一半,若只有两个master节点,其中一个挂了,是选举不出来新的master的
奇数个master节点是为了满足上述要求并且节省资源,三个master节点与四个master节点,当大家都挂了一个master的时候,都能进行选举,当挂了两个的是否都选举不了。

19.哨兵leader选举

​ sentinel(哨兵) 会以每秒一次的频率向主从和其他sentienl发送ping命令,当超过设置的down-after-milliseconds后未收到的有效的响应会认为该master主观下线,接着向其他sentiel进行确认,接收到足够数量的后,sentinel会判定该服务器客观下线。

​ 当一个master服务器被sentinel认为下线状态后,sentinel会与其余的sentinel协商选出的leader进行故障转移,每个发现master服务器进入下线的sentinel都可以要求其他sentinel选自己为sentinel的leader,选举是先到先得,同是每个sentinel每次选举都会自增配置纪元(选举周期),每个纪元中只有选择一个sentinel的leader.如果所有超过一半的sentinel选举其中一个sentinel作为leader.之后该sentinel作为leader进行故障转移操作。（选举出的slave会执行slaveof no one成为主节点,向其他slave发送命令其成为新的master的slave,监视旧的master恢复后成为新的master的slave并进行同步）

20.Redis如何做内存优化？

1、缩短键值的长度

缩短值的长度才是关键，如果值是一个大的业务对象，可以将对象序列化成二进制数组；
首先应该在业务上进行精简，去掉不必要的属性，避免存储一些没用的数据；
其次是序列化的工具选择上，应该选择更高效的序列化工具来降低字节数组大小；
以JAVA为例，内置的序列化方式无论从速度还是压缩比都不尽如人意，这时可以选择更高效的序列化工具，如: protostuff，kryo等
2、共享对象池

对象共享池指Redis内部维护[0-9999]的整数对象池。创建大量的整数类型redisObject存在内存开销，每个redisObject内部结构至少占16字节，甚至超过了整数自身空间消耗。所以Redis内存维护一个[0-9999]的整数对象池，用于节约内存。 除了整数值对象，其他类型如list,hash,set,zset内部元素也可以使用整数对象池。因此开发中在满足需求的前提下，尽量使用整数对象以节省内存。

3、字符串优化

4、编码优化

5、控制key的数量