本文已收录到1.1K Star数开源学习指南——《大厂面试指北》，如果想要了解更多大厂面试相关的内容及获取《大厂面试指北》离线PDF版，请扫描下方二维码码关注公众号“大厂面试”，谢谢大家了！

《大厂面试指北》最佳阅读地址：

http://notfound9.github.io/interviewGuide/

《大厂面试指北》项目地址：

https://github.com/NotFound9/interviewGuide

获取《大厂面试指北》离线PDF版，请扫描下方二维码关注公众号“大厂面试”

《大厂面试指北》项目截图：

干货内容回顾：

【大厂面试01期】高并发场景下，如何保证缓存与数据库一致性？

【大厂面试02期】Redis过期key是怎么样清理的？

【大厂面试03期】MySQL是怎么解决幻读问题的？

【大厂面试04期】讲讲一条MySQL更新语句是怎么执行的？

【大厂面试05期】说一说你对MySQL中锁的理解？

【大厂面试06期】谈一谈你对Redis持久化的理解？

【大厂面试07期】说一说你对synchronized锁的理解？

【大厂面试08期】谈一谈你对HashMap的理解？

摘要

最近是把《Redis设计与实现》看完了，然后也对每一章写了读书笔记。但是总感觉自己掌握得不够，所以就在网上搜集了一些Redis相关的面试题，然后自己去翻笔记，看书，查资料尝试着去解答，目前这篇文章还没有完全覆盖到所有Redis相关的面试题，之后会持续更新，一方面是我自己学习记录，一方面是分享给大家，与大家交流。

面试题列表：

1.Redis是什么？

2.Redis的持久化是怎么实现的？

3.AOF和RDB的区别是什么？

4.怎么防止AOF文件越来越大？

5.Redis持久化策略该如何进行选择？

6.AOF文件追加阻塞是什么？

7.Redis过期key是怎么样清理的？

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

9.Redis性能为什么高?

10.Linux I/O模型一共有哪些？

11.同步与异步的区别是什么？

12.阻塞与非阻塞的区别是什么？

13.如何解决Redis缓存穿透问题？

14.布隆过滤器是什么？

15.如何解决Redis缓存雪崩问题？

16.Redis常见的数据结构有哪些？

17.谈一谈你对Redis中简单动态字符串的理解？

18.谈一谈你对Redis中hash对象的理解？

19.谈一谈你对Redis中List的理解？

20.谈一谈你对Redis中Set的理解？

21.谈一谈你对Redis中ZSet(有序集合)的理解？

22.Redis主从同步是怎么实现的？

23.Redis中哨兵是什么？

24.客户端是怎么接入哨兵系统的？

25.Redis哨兵系统是怎么实现自动故障转移的？

下面是自己查阅书籍，资料，翻看读书笔记后，尝试写的回答，有不对的地方欢迎指正，大家一起学习进步。

Redis是什么？

Redis是一个开源的，基于内存的，也可进行持久化的，基于C语言编写的键值对存储数据库。

Redis的持久化是怎么实现的？

Redis主要通过AOF和RDB实现持久化。

AOF持久化主要是Redis在修改相关的命令后，将命令添加到aof_buf缓存区的末尾，然后在每次事件循环结束时，根据appendfsync的配置（always是总是写入，everysec是每秒写入，no是根据操作系统来决定何时写入），判断是否需要将aof_buf写入AOF文件。

RDB持久化指的是在满足一定的触发条件时（在一个的时间间隔内执行修改命令达到一定的数量，或者手动执行SAVE和BGSAVE命令），对这个时间点的数据库所有键值对信息生成一个压缩文件dump.rdb，然后将旧的删除，进行替换。

实现原理是fork一个子进程，然后对键值对进行遍历，生成rdb文件，在生成过程中，父进程会继续处理客户端发送的请求，当父进程要对数据进行修改时，会对相关的内存页进行拷贝，修改的是拷贝后的数据。（也就是COPY ON WRITE，写时复制技术，就是当多个调用者同时请求同一个资源，如内存或磁盘上的数据存储，他们会共用同一个指向资源的指针，指向相同的资源，只有当一个调用者试图修改资源的内容时，系统才会真正复制一份专用副本给这个调用者，其他调用者还是使用最初的资源,在ArrayList的实现中，也有用到，添加一个新元素时过程是，加锁，对原数组进行复制，然后添加新元素，然后替代旧数组，解锁）

AOF和RDB的区别是什么？

AOF因为是保存了所有执行的修改命令，粒度更细，进行数据恢复时，恢复的数据更加完整，但是由于需要对所有命令执行一遍，效率比较低，同样因为是保存了所有的修改命令，同样的数据集，保存的文件会比RDB大，而且随着执行时间的增加，AOF文件可能会越来越大，所有会通过执行BGREWRITEAOF命令来重新生成AOF文件，减小文件大小。Redis服务器故障重启后，默认恢复数据的方式首选是通过AOF文件恢复，其次是通过RDB文件恢复。 RDB是保存某一个时间点的所有键值对信息，所以恢复时可能会丢失一部分数据，但是恢复效率会比较高

怎么防止AOF文件越来越大？

为了防止AOF文件越来越大，可以通过执行BGREWRITEAOF命令，会fork子进程出来，读取当前数据库的键值对信息，生成所需的写命令，写入新的AOF文件。在生成期间，父进程继续正常处理请求，执行修改命令后，不仅会将命令写入aof_buf缓冲区，还会写入重写aof_buf缓冲区。当新的AOF文件生成完毕后，子进程父进程发送信号，父进程将重写aof_buf缓冲区的修改命令写入新的AOF文件，写入完毕后，对新的AOF文件进行改名，原子地（atomic）地替换旧的AOF文件。

Redis持久化策略该如何进行选择？

RDB持久化的特点是：文件小，恢复快，不影响性能，实时性低，兼容性差（老版本的Redis不兼容新版本的RDB文件） AOF持久化的特点是：文件大，恢复慢，性能影响大，实时性高。是目前持久化的主流(主要是当前项目开发不太能接受大量数据丢失的情况)。需要了解的是持久化选项的开启必然会造成一定的性能消耗 RDB持久化主要在于bgsave在进行fork操作时，会阻塞Redis的主线程。以及向硬盘写数据会有一定的I/O压力。 AOF持久化主要在于将aof_buf缓冲区的数据同步到磁盘时会有I/O压力，而且向硬盘写数据的频率会高很多。其次是，AOF文件重写跟RDB持久化类似，也会有fork时的阻塞和向硬盘写数据的压力。

以下是几种持久化方案选择的场景：

1.不需要考虑数据丢失的情况，那么不需要考虑持久化。

2.单机实例情况下，可以接受丢失十几分钟及更长时间的数据，可以选择RDB持久化，对性能影响小，如果只能接受秒级的数据丢失，只能选择AOF持久化。

3.在主从环境下，因为主服务器在执行修改命令后，会将命令发送给从服务器，从服务进行执行后，与主服务器保持数据同步，实现数据热备份，在master宕掉后继续提供服务。同时也可以进行读写分离，分担Redis的读请求。

那么在从服务器进行数据热备份的情况下，是否还需要持久化呢？需要持久化，因为不进行持久化，主服务器，从服务器同时出现故障时，会导致数据丢失。（例如：机房全部机器断电）。如果系统中有自动拉起机制（即检测到服务停止后重启该服务）将master自动重启，由于没有持久化文件，那么master重启后数据是空的，slave同步数据也变成了空的。应尽量避免“自动拉起机制”和“不做持久化”同时出现。

所以一般可以采用以下方案：

主服务器不开启持久化，使得主服务器性能更好。

从服务器开启AOF持久化，关闭RDB持久化，并且定时对AOF文件进行备份，以及在凌晨执行bgaofrewrite命令来进行AOF文件重写，减小AOF文件大小。（当然如果对数据丢失容忍度高也可以开启RDB持久化，关闭AOF持久化）

4.异地灾备，一般性的故障（停电，关机）不会影响到磁盘，但是一些灾难性的故障（地震，洪水）会影响到磁盘，所以需要定时把单机上或从服务器上的AOF文件，RDB文件备份到其他地区的机房。

AOF文件追加阻塞是什么

修改命令添加到aof_buf之后，如果配置是everysec那么会每秒执行fsync操作，调用write写入磁盘一次，但是如果硬盘负载过高，fsync操作可能会超过1s，Redis主线程持续高速向aof_buf写入命令，硬盘的负载可能会越来越大，IO资源消耗更快，所以Redis的处理逻辑是会对比上次fsync成功的时间，如果超过2s，则主线程阻塞直到fsync同步完成，所以最多可能丢失2s的数据，而不是1s。

Redis过期key是怎么样清理的？

(1)惰性清除。在访问key时，如果发现key已经过期，那么会将key删除。

(2)定时清理。Redis配置项hz定义了serverCron任务的执行周期，默认每次清理时间为25ms，每次清理会依次遍历所有DB，从db随机取出20个key，如果过期就删除，如果其中有5个key过期，那么就继续对这个db进行清理，否则开始清理下一个db。

(3)当执行写入命令时，如果发现内存不够，那么就会按照配置的淘汰策略清理内存，淘汰策略主要由以下几种：

1.noeviction，不删除，达到内存限制时，执行写入命令时直接返回错误信息。

2.allkeys-lru，在所有key中，优先删除最少使用的key。（适合请求符合幂定律分布，也就是一些键访问频繁，一部分键访问较少）

3.allkeys-random，在所有key中，随机删除一部分key。（适合请求分布比较平均）

4.volatile-lru，在设置了expire的key中，优先删除最少使用的key。

5.volatile-random，在设置了expire的key中，随机删除一部分key。

6.volatile-ttl，在设置了expire的key中，优先删除剩余时间段的key。

4.0版本后增加以下两种：

volatile-lfu：从已设置过期时间的数据集(server.db[i].expires)中挑选最不经常使用的数据淘汰。

allkeys-lfu：当内存不足以容纳新写入数据时，在键空间中，移除最不经常使用的key。

LRU算法

LRU算法的设计原则是如果一个数据近期没有被访问到，那么之后一段时间都不会被访问到。所以当元素个数达到限制的值时，优先移除距离上次使用时间最久的元素。可以使用HashMap<String, Node>+双向链表Node来实现，每次访问元素后，将元素移动到链表尾部，当元素满了时，将链表头部的元素移除。使用单向链表能不能实现呢，也可以，单向链表的节点虽然获取不到pre节点的信息，但是可以将下一个节点的key和value设置在当前节点上，然后把当前节点的next指针指向下下个节点。

LFU算法

LFU算法的设计原则时，如果一个数据在最近一段时间被访问的时次数越多，那么之后被访问的概率会越大，实现是每个数据都有一个引用计数，每次数据被访问后，引用计数加1，需要淘汰数据时，淘汰引用计数最小的数据。在Redis的实现中，每次key被访问后，引用计数是加一个介于0到1之间的数p，并且访问越频繁p值越大，而且在一定的时间间隔内，如果key没有被访问，引用计数会减少。

Redis为什么是单线程的？

Redis官方FAQ回答: Redis是基于内存的操作，CPU不会成为瓶颈所在，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了。（这里的单线程指的是处理网络请求的模块是单线程，其他模块不一定是单线程的）

Redis采用单线程的优势:

1.Redis项目的代码会更加清晰，处理逻辑会更加简单。

2.不用考虑多个线程修改数据的情况，修改数据时不用加锁，解锁，也不会出现死锁的问题，导致性能消耗。

3.不存在多进程或者多线程导致的切换而造成的一些性能消耗。

Redis采用单线程的劣势:

1.无法充分发挥多核机器的优势，不过可以通过在机器上启动多个Redis实例来利用资源。

Redis性能为什么高?

根据官网的介绍，Redis单机可以到到10W的QPS(每秒处理请求数)，Redis这么快的原因主要有以下几点：

1.完全基于内存，数据全部存储在内存中，读取时没有磁盘IO，所以速度非常快。

2.Redis采用单线程的模型，没有上下文切换的开销，也没有竞态条件，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗。

3.Redis项目中使用的数据结构都是专门设计的，例如SDS(简单动态字符串)是对C语言中的字符串频繁修改时，会频繁地进行内存分配，十分消耗性能，而SDS会使用空间预分配和惰性空间释放来避免这些问题的出现。空间预分配技术: 对SDS进行修改时，如果修改后SDS实际使用长度为len，

当len<1M时,分配的空间会是2*len+1，也就是会预留len长度的未使用空间，其中1存储空字符

当len>1M时,分配的空间会是len+1+1M，也就是会预留1M长度的未使用空间，其中1存储空字符

4.采用多路复用IO模型，可以同时监测多个流的IO事件能力，在空闲时，会把当前线程阻塞掉，当有一个或多个流有I/O事件时，就从阻塞态唤醒，轮询那些真正发出了事件的流，并只依次顺序的处理就绪的流。可以让单个线程高效的处理多个连接请求（尽量减少网络 I/O 的时间消耗)。

Linux I/O模型一共有哪些？

IO模型主要由阻塞式I/O模型，非阻塞式I/O模型，I/O复用模型，信息驱动式I/O模型，异步I/O模型。

阻塞式I/O模型

用户态进程调用recvfrom系统调用来接受数据，如果当前内核中数据没有准备好，那么会一直等待，不会进行其他操作，直到内核中的数据准备好，将数据拷贝到用户空间内存，然后recvfrom返回成功的信号，此时用户态进行才解除阻塞的状态，处理收到的数据。

非阻塞时I/O模型

在非阻塞式I/O模型中，当进程等待内核的数据，而当该数据未到达的时候，进程会不断询问内核，直到内核准备好数据。用户态进程调用recvfrom接收数据，当前并没有数据报文产生，此时recvfrom返回EWOULDBLOCK，用户态进程会一直调用recvfrom询问内核，待内核准备好数据的时候，之后用户态进程不再询问内核，待数据从内核复制到用户空间，recvfrom成功返回，用户态进程开始处理数据。

I/O多路复用模型

I/O复用指的是多个I/O连接复用一个进程。最初级的I/O复用，就是一个进程对应多个连接，每次从头至尾进行遍历，判断是否有I/O事件需要处理，有的话就进行处理，缺点是效率比较低，如果一直没有事件进来，会导致CPU空转。升级版的I/O复用模型当没有I/O事件时，进程处于阻塞状态，当有I/O事件时，就会有一个代理去唤醒进程，去进行轮询，来处理I/O事件。（这里的代理也就是select和poll，select只能观察1024个连接，poll可以观察无限个连接） epoll是对select和poll的升级版，解决了很多问题，是线程安全的，而且可以通知进程是哪个Socket连接有I/O事件,提高了查找效率。 epoll和select/poll最大区别是 (1)epoll内部使用了mmap共享了用户和内核的部分空间，避免了数据的来回拷贝 (2)epoll基于事件驱动，epoll_wait只返回发生的事件避免了像select和poll对事件的整个轮寻操作。

信息驱动式I/O模型

是非阻塞的，当需要等待数据时，用户态进程会给内核发送一个信号，告知自己需要的数据，然后就去执行其他任务了，内核准备好数据后，会给用户态发送一个信号，用户态进程收到之后，会立马调用recvfrom，等待数据从从内核空间复制到用户空间，待完成之后recvfrom返回成功指示，用户态进程才处理数据。

异步I/O模型

与信息驱动式I/O模型区别在于，是在数据从内核态拷贝到用户空间之后，内核才通知用户态进程来处理数据。在复制数据到用户空间这个时间段内，用户态进程也是不阻塞的。

同步与异步的区别是什么？

同步与异步的区别在于调用结果的通知方式上。同步执行一个方法后，需要等待结果返回，然后继续执行下去。异步执行一个方法后，不会等待结果的返回，调用方定时主动去轮询调用结果或者被调用方在执行完成后通过回调来通知调用方。

阻塞与非阻塞的区别是什么？

阻塞与非阻塞的区别在于进程/线程在等待消息时，进程/线程是否是挂起状态。阻塞调用在发出去后，消息返回之前，当前进程/线程会被挂起，直到有消息返回，当前进/线程才会被激活。非阻塞调用在发出去后，不会阻塞当前进/线程，而会立即返回，可以去执行其他任务。

如何解决Redis缓存穿透问题？

Redis 缓存穿透指的是攻击者故意大量请求一些Redis缓存中不存在key的数据，导致请求打到数据库上，导致数据库压力过大。

1.做好参数校验，无效的请求直接返回，只能避免一部分情况，攻击者总是可以找到一些没有覆盖的情况。

2.对缓存中找不到的key，需要去数据库查找的key，缓存到Redis中，但是可能会导致Redis中缓存大量无效的key，可以设置一个很短的过期时间，例如1分钟。

3.也可以使用布隆过滤器，将所有可能的存在的数据通过去hash值的方式存入到一个足够大的bitmap中去，处理请求时，通过在botmap中查找，可以将不存在的数据拦截掉。

布隆过滤器是什么？

布隆过滤器可以理解为一个有误差的set结构，使用布隆过滤器来判断元素是否存在其中时，如果返回结果是存在，实际可能存在也可能不存在，返回结果不存在时，实际结果肯定是不存在。布隆过滤器实际上是一个大型的位数组，添加key时，通过几个hash函数对key计算得到一个下标，然后根据下标将位数组中对应的值设为1。

如何解决Redis缓存雪崩问题？

缓存雪崩主要指的是短时间内大量key失效，导致所有请求全部转向数据库，导致数据库压力过大。解决方案：

1.在给缓存设置失效时间时加一个随机值，避免集体失效。

2.双缓存机制，缓存A的失效时间为20分钟，缓存B没有失效时间，从缓存A读取数据，缓存A中没有时，去缓存B中读取数据，并且启动一个异步线程来更新缓存A。

如何解决Redis缓存击穿问题？

缓存击穿主要是某个key过期后，恰好有大量高并发的请求访问，导致数据库压力过大。解放方案： 1.访问数据库之前设置互斥锁。在从缓存获取数据失败后，先去设置互斥锁，设置成功，再去进行数据库操作，否则先休眠一段时间再重试。

Redis常见的数据结构有哪些？

Redis中主要的数据结构有String字符串，Hash哈希表，List列表，Set集合，ZSet有序集合。

谈一谈你对Redis中简单动态字符串的理解？

Redis中的简单动态字符串其实是对C语言中的字符串的封装和优化，因为C语言的字符串有两个缺点：

1.不是二进制安全的（因为字符串以空字符作为结束的标志，字符串中间不能有空字符)。

2.频繁修改一个字符串时，会涉及到内存的重分配，比较消耗性能。（Redis中的简单动态字符串会有内存预分配和惰性空间释放）。

所以Redis中的简单动态字符串结构，除了包含一个字符数组的属性，还包含数组的长度，数组的实际使用长度等属性，通过增加长度属性，可以保证字符串是二进制安全的，从而可以保存任意类型的数据，例如一张图片，对象序列化后的数据等等。字符串使用场景如下：

1.字符串可以保存一些字符串数据，也可以保存一些数字类型的数据，所以可以使用INCR, DECR, INCRBY对数字进行加减，所以可以把字符串当成计数器使用。

2.同时因为在C语言中，每个字符是一个字节，是8个二进制位，所以可以把简单动态字符串作为一个位数组来使用，通过setbit，getbit命令来对位数组进行赋值，取值，可以以很小的空间来保存用户一年的每日签到数据，以及Redis中的布隆过滤器也是通过位数组来实现的。

字符串的底层存储

在Redis中，每一个Value都是一个Redis对象，对应的都是RedisObject结构，在RedisObject结构中，保存了对象的类型type，底层的编码encoding等一些属性，也拥有一个ptr指针，指向对象具体的存储地址。

struct RedisObject {
    int4 type; 
    int4 encoding; 
    int24 lru; 
    int32 refcount; 
    void *ptr; 
} robj;

在Redis中，字符串有两种存储方式，int编码，embstr编码和raw编码。

int编码

当value是一个整数，并且可以使用long类型（8字节）来表示时，那么会属于int编码，ptr直接存储数值。（并且Redis会进行优化，启动时创建0~9999的字符串对象作为共享变量。）

embstr和raw编码

两种存储方式下，都RedisObject和SDS结构(简单动态字符串)来存储字符串，区别在于，embstr对象用于存储较短的字符串，embstr编码中RedisObject结构与ptr指向的SDS结构在内存中是连续的，内存分配次数和内存释放次数均是一次，而raw编码会分别调用两次内存分配函数来分别创建RedisObject结构和SDS结构。

谈一谈你对Redis中hash对象的理解？

在Redis中，value可以是一个hash表，底层编码可以是ziplist，也可以是hashtable（默认情况下，当元素小于512个时，底层使用ziplist存储数据）

ziplist

元素保存的字符串长度较短且元素个数较少时(小于64字节，个数小于512)，出于节约内存的考虑，hash表会使用ziplist作为的底层实现，ziplist是一块连续的内存，里面每一个节点保存了对应的key和value，然后每个节点很紧凑地存储在一起，优点是没有冗余空间，缺点插入新元素需要调用realloc扩展内存。（可能会进行内存重分配，将内容拷贝过去，也可能在原有地址上扩展）。

hashtable

元素比较多时就会使用hashtable编码来作为底层实现，这个时候RedisObject的ptr指针会指向一个dict结构，dict结构中的ht数组保存了ht[0]和ht[1]两个元素，通常使用ht[0]保存键值对，ht[1]只在渐进式rehash时使用。hashtable是通过链地址法来解决冲突的，table数组存储的是链表的头结点（添加新元素，首先根据键计算出hash值，然后与数组长度取模之后得到数组下标，将元素添加到数组下标对应的链表中去）。

struct dict {
    int rehashindex;
    dictht ht[2]; 
}
struct dictht {
    dictEntry** table; // 二维
    long size; // 第一维数组的长度 
    long used; // hash 表中的元素个数 ...
}
typedef struct dictEntry {
  //键  
  void *key;
  //值，可以是一个指针，也可以是一个uint64_t整数，也可以是int64_t的整数
  union {
    void *val;
    uint64_tu64;
    int64_ts64;
  } v；
  //指向下一个节点的指针
  struct dictEntry *next;
} dictEntry；

渐进式rehash

进行当负载因子>=1时，会进行哈希表扩展操作（如果是在执行BGSAVE或BGREWRITEAOF命令期间，那么需要>=5才会进行扩展）。

进行当负载因子<0.1时，会进行哈希表收缩操作。

因为直接一次性完成rehash会对性能产生影响，所以可以渐进式rehash，具体执行步骤是 1.首先将对dict结构中ht[1]哈希表分配空间(大小取决于最接近实际使用空间的2的n次方幂)，然后将rehashindex属性设置为0。

2.然后每次对ht[0]中的元素查找，修改，添加时，除了执行指定操作外，还会将对应下标的所有键值对rehash到ht[1],并且会将rehashindex+1。

3.当ht[0]中所有键值对都是rehash到ht[1]中后，那么会ht[1]和ht[0]的指针值进行交换，将rehashindex设置为-1，代表rehash完成。（整个rehash期间，查找，更新，删除会先去ht[0]中执行，没有才会到ht[1]中执行，新添加键值对是会被保存到ht[1]中）。

谈一谈你对Redis中List的理解？

在Redis中，存储的value可以是一个列表List，跟Java中的LinkedList很像，底层数据结构是一个链表，插入和删除很快，随机访问较慢，时间复杂度是O(N)。Java中的列表数据进行缓存时一般是序列化成JSON，以字符串的形式存储在Redis上，而不是使用Redis中的List来进行存储。Redis中的List可以作为一个队列来使用，也可以作为一个栈来使用。在实际使用中，常用来做异步队列使用，将可以延时处理的任务序列化成字符串塞进Redis的列表，另外一个线程从列表中轮询数据进行处理

quiklist

老版本中的Redis，元素较少时，使用ziplist来作为底层编码，元素较多时使用双向链表linkedList作为底层编码。因为链表每个节点需要prev，next指针，需要占用16字节，而且每个节点内存都是单独分配，加剧内存碎片化，所以新版本使用quiklist作为底层编码，quiklist的是一个双向链表，但是它的每一个节点是一个ziplist。（默认每个ziplist最大长度为8k字节）

谈一谈你对Redis中Set的理解？

Set是一个无序的，不重复的字符串集合，底层编码有inset和hashtable两种。

inset

当元素都为整数，且元素个数较少时会使用inset作为底层编码，inset结构中的有一个contents属性，content是是一个整数数组，从小到大保存了所有元素。

hashtable

当元素个数较多时，Set使用hashtable来保存元素，元素的值作为key，value都是NULL。

谈一谈你对Redis中ZSet(有序集合)的理解？

Zset与Set的区别在于每一个元素都有一个Score属性，并且存储时会将元素按照Score从低到高排列。

当元素较少时，ZSet的底层编码使用ziplist实现，所有元素按照Score从低到高排序。

当元素较多时，使用skiplist+dict来实现， skiplist存储元素的值和Score，并且将所有元素按照分值有序排列。便于以O(logN)的时间复杂度插入，删除，更新，及根据Score进行范围性查找。

dict存储元素的值和Score的映射关系，便于以O(1)的时间复杂度查找元素对应的分值。

Redis主从同步是怎么实现的？

主从节点建立连接后，从节点会进行判断

1.如果这是从节点之前没有同步过数据，属于初次复制，会进行全量重同步那么从节点会向主节点发送PSYNC?-1 命令，请求主节点进行全量重同步。

2.如果这是从节点不说初次复制（例如出现掉线后重连），这个时候从节点会将之前进行同步的Replication ID(一个随机字符串，标识主节点上的特定数据集)和offset（从服务器当前的复制偏移量）通过PSYNC 命令发送给主节点，主节点会进行判断，

如果Replication ID跟当前的Replication ID不一致，或者是当前buffer缓冲区中不存在对应的offset，那么会跟上面的初次复制一样，进行全量重同步。
如果Replication ID跟当前的Replication ID一致并且当前buffer缓冲区中存在对应的offset，那么会进行部分重同步。（部分重同步是Redis 2.8之后的版本支持的，主要基于性能考虑，为了断线期间的小部分数据修改进行全量重同步效率比较低）

全量重同步

主节点会执行BGSAVE命令，fork出一个子进程，在后台生成一个RDB持久化文件，完成后，发送给从服务器，从节点接受并载入RDB文件，使得从节点的数据库状态更新至主节点执行BGSAVE命令时的状态。并且在生成RDB文件期间，主节点也会使用一个缓冲区来记录这个期间执行的所有写命令，将这些命令发送给从节点，从节点执行命令将自己数据库状态更新至与主节点完全一致。

部分重同步

因为此时从节点只是落后主节点一小段时间的数据修改，并且偏移量在复制缓冲区buffer中可以找到，所以主节点把从节点落后的这部分数据修改命令发送给从节点，完成同步。

命令传播

在执行全量重同步或者部分重同步以后，主从节点的数据库状态达到一致后，会进入到命令传播阶段。主节点执行修改命令后，会将修改命令添加到内存中的buffer缓冲区（是一个定长的环形数组，满了时就会覆盖前面的数据），然后异步地将buffer缓冲区的命令发送给从节点。

Redis中哨兵是什么？

Redis中的哨兵服务器是一个运行在哨兵模式下的Redis服务器，核心功能是监测主节点和从节点的运行情况，在主节点出现故障后，完成自动故障转移，让某个从节点升级为主节点。

客户端是怎么接入哨兵系统的？

首先Redis中的哨兵节点是一个配置提供者，而不是代理。区别在于，

配置提供者

前者只负责存储当前最新的主从节点信息，供客户端获取。

代理

客户端所有请求都会经过哨兵节点。

所以实际开发中，通过在客户端配置哨兵节点的地址+主节点的名称(哨兵系统可能会监控多个主从节点，名称用于区分)就可以获取到主节点信息，下面的代码在底层实现是客户端向依次向哨兵节点发送"sentinel get-master-addr-by-name"命令，成功获得主节点信息就不向后面的哨兵节点发送命令。同时客户端会订阅哨兵节点的+switch-master频道，一旦主节点发送故障，哨兵服务器对主节点进行自动故障转移，会将从节点升级主节点，并且更新哨兵服务器中存储的主节点信息，会向+switch-master频道发送消息，客户端得到消息后重新从哨兵节点获取主节点信息，初始化连接池。

 String masterName = "mymaster";
 Set<String> sentinels = new HashSet<>();
 sentinels.add("192.168.92.128:26379");
 sentinels.add("192.168.92.128:26380");

 JedisSentinelPool pool = new JedisSentinelPool(masterName, sentinels); //初始化过程做了很多工作
 Jedis jedis = pool.getResource();
 jedis.set("key1", "value1");
 pool.close();

Redis哨兵系统是怎么实现自动故障转移的？

1.认定主节点主观下线

因为每隔2s，哨兵节点会给主节点发送PING命令，如果在一定时间间隔内，都没有收到回复，那么哨兵节点就认为主节点主观下线。

2.认定主节点客观下线

哨兵节点认定主节点主观下线后，会向其他哨兵节点发送sentinel is-master-down-by-addr命令，获取其他哨兵节点对该主节点的状态，当认定主节点下线的哨兵数量达到一定数值时，就认定主节点客观下线。

3.进行领导者哨兵选举

认定主节点客观下线后,各个哨兵之间相互通信，选举出一个领导者哨兵，由它来对主节点进行故障转移操作。

选举使用的是Raft算法，基本思路是所有哨兵节点A会先其他哨兵节点，发送命令，申请成为该哨兵节点B的领导者，如果B还没有同意过其他哨兵节点，那么就同意A成为领导者，最终得票超过半数以上的哨兵节点会赢得选举，如果本次投票，没有选举出领导者哨兵，那么就开始新一轮的选举，直到选举出哨兵节点（实际开发中，最先判定主节点客观下线的哨兵节点，一般就能成为领导者。）

4.领导者哨兵进行故障转移

领导者哨兵节点首先会从从节点中选出一个节点作为新的主节点。选择的规则是：

1.首先排除一些不健康的节点。（下线的，断线的，最近5s没有回复哨兵节点的INFO命令的，与旧的主服务器断开连接时间较长的）

2.然后根据优先级，复制偏移量，runid最小，来选出一个从节点作为主节点。

向这个从节点发送slaveof no one命令，让其成为主节点，通过slaveof 命令让其他从节点成为它的从节点，将已下线的主节点更新为新的主节点的从节点。