【Java开发岗：Redis篇】

点击：【第一章：Java开发岗：基础篇】

计算机基础问题、HashMap、Fail-safe机制/Fail-fast机制、Synchronized、ThreadLocal、AQS、线程池、JVM内存模型、内存屏障、class文件结构、类加载 机制、双亲委派、垃圾回收算法、垃圾回收器、空间分配担保策略、安全点、JIT技术、可达性分析、强软弱虚引用、gc的过程、三色标记、跨代引用、 逃逸分析、 内存泄漏与溢出、JVM线上调优、CPU飙高系统反应慢怎么排查。

点击：【第二章：Java开发岗：MySQL篇】

隔离级别、ACID底层实现原理、 一致性非锁定读（MVCC的原理）、BufferPool缓存机制、filesort过程、 离散读、ICP优化、全文检索、 行锁、表锁、间隙锁、死锁、主键自增长实现原理、索引数据结构、SQL优化、索引失效的几种情况、聚集索引、辅助索引、覆盖索引、联合索引、redo log、bin log、undolog、分布式事务、SQL的执行流程、重做日志刷盘策略、有MySQL调优、分库分表、主从复制、读写分离、高可用。

点击：【第三章：Java开发岗：Redis篇】

多路复用模式、单线程模型、简单字符串、链表、字典、跳跃表、压缩列表、encoding属性编码、持久化、布隆过滤器、分布式寻址算法、过期策略、内存淘汰策略 、Redis与数据库的数据一致性、Redis分布式锁、热点数据缓存、哨兵模式、集群模式、多级缓存架构、并发竞争、主从架构、集群架构及高可用、缓存雪崩、 缓存穿透、缓存失效。

点击：【第四章：Java开发岗：MQ篇】

RabbitMQ、RockerMQ、Kafka 三种消息中间件出现的消息可靠投递、消息丢失、消息顺序性、消息延迟、过期失效、消息队列满了、消息高可用等问题的解决方案。RabbitMQ的工作模式，RocketMQ的消息类型，Kafka消费模式、主题/分区/日志、核心总控制器以及它的选举机制、Partition副本选举Leader机制、消费者消费消息的offset记录机制、消费者Rebalance机制、Rebalance分区分配策略、Rebalance过程、 producer发布消息机制、HW与LEO、日志分段存储、十亿消息数据线上环境规划、JVM参数设置。

点击：【第五章：Java开发岗：Spring篇】

SpringBean生命周期、Spring循环依赖、Spring容器启动执行流程、Spring事务底层实现原理、Spring IOC容器加载过程、Spring AOP底层实现原理、Spring的自动装配、Spring Boot自动装配、Spring Boot启动过程、SpringMVC执行流程、Mybatis的缓存机制。

点击：【第六章：Java开发岗：SpringCould篇】

微服务构建、客户端负载均衡、服务治理、服务容错保护、声明式服务调用、API网关服务、分布式配置中心、消息总线、消息驱动、分布式服务追踪、分布式事务、流量控制。

点击：【第七章：Java开发岗：项目篇】

简历上面的项目经历怎么写(项目介绍、负责模块、使用技术)，面试项目实战（秒杀下单设计、权限设计、红包雨设计）

---

系列文章：每篇文章字数都是大几万，保证质量，文章以备战面试为背景，薪资参考坐标：上海；每个地方，每个时间段薪资待遇都不一样，文章仅做面试参考，具体能否谈到理想的薪资取决于面试表现、平时的积累、市场行情、机遇。
提示：系列文章还未全部完成，后续的文章，会慢慢补充进去的。

这里总结一下35k的Java开发岗需要掌握的面试题，帮助大家快速复习，突破面试瓶颈。本章主讲Redis知识点，知识点有：多路复用模式、单线程模型、简单字符串、链表、字典、跳跃表、压缩列表、encoding属性编码、持久化、布隆过滤器、分布式寻址算法、过期策略、内存淘汰策略 、Redis与数据库的数据一致性、Redis分布式锁、热点数据 缓存、哨兵模式、集群模式、多级缓存架构、并发竞争、主从架构、集群架构及高可用、缓存雪崩、 缓存穿透、缓存失效。大致估算可以讲八小时左右，作为备战面试的Redis知识点还是很不错的。35k薪资参考的坐标：上海，参考时间：2022年8月。

多路复用

redis的多路复用模式

redis使用模型有：select、poll、epoll。这里简单讲二种。

应用对外提供服务的过程

一个应用程序, 想对外提供服务, 一般都是通过建立套接字监听端口来实现, 也就是socket。
应用对外提供服务的过程：

1. 创建套接字
2. 绑定端口号
3. 开始监听
4. 当监听到连接时, 调用系统read去读取内容，但是读取操作是阻塞的。

select

问题：如果主线程处理read，就不能接收其他连接了, 所以只能开新的线程去处理这个事情。而且read操作是调用系统函数, 需要进行进程的切换, 从用户进程切换到系统进程，连接少还好，连接多的话，无疑降低了性能。

解决方案：用户线程批量将要查询的连接发给操作系统，这个过程只发生一次进程的切换，用户线程告诉操作系统，需要哪些数据, 它遍历查找，然后将结果返回给用户线程，这就是select。

操作系统接收到一组文件描述符，然后批量处理这些文件描述符，有顺序的循环检查有没有数据，然后返回结果。无论是监听端口还是建立了连接，程序拿到的都是一个文件描述符，将这些文件描述符批量查询就是了。

epoll

问题：有10万个连接，其中有数据的只有一个，那就回有9999次无效的操作，每次查询都要把所有的都传过去, 10万个就要传10万。

解决方案：直接知道哪些连接是有数据的，然后操作系统通知用户线程，那个连接是可以直接拿到数据的，用户线程就直接通过这个连接去读数据就好了，不需要遍历，这就是epoll。

建立一个需要回调的连接， 将需要监听的文件描述符都扔给操作系统，当有新数据到达时，会直接返回给用户线程。用户线程将监听的列表交给操作系统维护，这样当有新数据来的时候，操作系统知道这是你要的，等你下次来拿的时候，直接给你了，少去了上面的遍历。

多路复用的定义

“多路”指的是多个网络连接，“复用”指的是复用同一个线程。

采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络IO的时间消耗）。

多路复用的举例

redis 需要处理 3 个 IO 请求，同时把 3 个请求的结果返回给客户端，所以总共需要处理 6 个 IO 事件， 由于 Redis服务端对于命令的处理是单线程的，同一时间只能处理一个 IO 事件。于是 redis 需要在合适的时间暂停对某个 IO 事件的处理，转而去处理另一个 IO 事件， 这样 redis 就好比一个开关，当开关拨到哪个 IO 事件这个电路上，就处理哪个 IO 事件，其他 IO 事件就暂停处理了。这就是IO多路复用技术。用一句话总结就是，一个客户端建立好连接后，就可以立刻等待新的客户端连接，而不用阻塞在原客户端的 read 请求上。

多路复用的实现

select, poll, epoll 都是I/O多路复用的具体的实现。epoll性能比其他几者要好。redis中的I/O多路复用的所有功能通过包装常见的select、epoll、evport和kqueue这些I/O多路复用函数库来实现的。 redis的io模型主要是基于epoll实现的，不过它也提供了 select和poll的实现，默认采用epoll。

过程一：数据未就绪

多个客户端并发请求时，用户线程发起请求的时候，首先会将socket监听列表添加到select中，让select调用操作系统的API，这个过程就是从用户态到内核态，由于当前请求是交给了操作系统去处理，现在的用户线程这时候就空闲了，可以重新接收新的客户端请求。

操作系统等待select调用，当数据到达时，select函数被激活，操作系统将select函数的结果socket监听结果为可读，返回给用户线程，告诉用户线程这个连接可以读取数据了，这个时候用户线程才正式发起read请求，读取数据，这个读取数据的过程也是非阻塞的。

过程二：数据就绪

read 函数的效果是，如果没有数据到达时（到达网卡并拷贝到了内核缓冲区），立刻返回一个错误值（-1），而不是阻塞地等待。只有当操作系统告诉用户线程数据已经准备就绪的时候，数据从内核缓冲区拷贝到用户缓冲区才通知用户进程调用完成，返回结果，这个过程是阻塞的。

对于用户线程来说，它可以注册多个socket监听，然后不断地调用select读取，操作系统找到用户线程需要的连接，这个连接里面监听到有用户线程所需要的数据，就会激活socket把结果返回给用户线程。
​

单线程模型

为什么redis使用单线程模型还能保证高性能？

第一个是因为redis 是纯内存操作，内存的响应时长是 100 纳秒左右，这是 redis 的 QPS 过万的重要基础。

第二个是因为redis 的核心是基于非阻塞的IO多路复用机制，单线程模型避免了线程切换和竞态产生的消耗，解决了多线程的切换性能损耗问题。

第三个是因为redis底层使用C语言实现，一般来说，C 语言实现的程序"距离"操作系统更近，执行速度相对会更快。

你是如何理解redis单线程模型的？

Redis 里面的单线程主要是 Redis 的网络 IO 和键值对读写，它是由一个线程来完成的，但是 Redis 的其他功能， 比如说持久化、异步删除、集群数据同步等等，这些其实是由额外的线程执行的，这里的单线程主要是Redis 对外提供键值存储服务来说的。

主要流程是这样的：redis 会将每个客户端都关联一个指令队列，客户端的指令通过队列来按顺序处理，先到先处理,一个客户端指令队列中的指令是按顺序执行的。 redis 的每个客户端都关联一个响应队列，通过响应队列有顺序地将指令的返回结果返回给客户端，并且redis 同一时间每次都只能处理一个客户端队列中的指令或者响应。
​

Redis底层数据结构

简单字符串

先简单了解一下C语言是怎么处理字符串的：

在C语言中，字符串结束的标识是空字符，也就是’’，这会有一个问题，就是字符串的内容可能包括空字符串，这个时候是不是就没办法正确存取字符串的内容了，它有可能中途读取一半就完了。

除此之外，它还不记录字符串的长度，这也会有一系列问题，

如果需要获取字符串的长度通过遍历计数来获取的，这会导致它的时间复杂度会比较高。

如果需要修改字符串，就要重新分配内存，不重新分配的话，字符串长度增大，超出给定的长度，这个时候会造成内存缓冲区溢出，字符串长度减小还会造成内存泄露。

如果需要对两个字符串进行拼接，是通过调用strcat函数来实现的，如果没有给它分配足够长度的内存空间，就会直接导致缓冲区溢出。

既然C语言处理字符串有这么多的弊端，那么Redis它是怎么处理字符串的呢？

Redis专门创建了一种数据结构SDS，什么意思呢？simple dynamic string，简单字符串。

官方代码：

struct sdshdr{

int len;

int free;

char buf[];

}

这个对象有三个属性：

• len表示字符串的长度
• free表示还有多少长度剩余，就是下面buf数组中还有多少字符串未使用的字节数量
• buf[]表示存储的字符串

问题一：这种数据结构有什么优势呢？跟C语言相比，改进了哪些问题？

长度和内存重新分配问题，C语言是不记录长度，而SDS它有len属性和free属性。

len记录了字符串的长度，直接取值就可以了，不像C语言需要遍历。 如果需要对字符串进行修改的话，也不需要像C语言一样，直接重新分配内存，

它可以通过len 属性检查内存空间是不是需要进行扩展内存，如果字符串长度增加，长度超过了len，就会增加相应的内存，接着修改。

如果字符串长度缩短了，它也不会立马就重新分配内存，而是有一个free属性记录下来，等你后面什么时候用了，重新计算或者分配内存。

结尾标识问题，C语言是以空字符串结尾标识的，而SDS是以len长度作为结尾标识的，避免了C语言无法正确读取字符串的问题。

链表

Redis的list类型的键值对底层数据结构是由链表构成的，那么链表是什么呢？

它是由一连串节点组成，没有顺序，不是连续的，每个节点由数据和一或两个用来指向上一个或下一个节点位置的链接组成，在每一个节点里存到下一个节点的指针，通过链表中的指针链接次序可以实现逻辑顺序。

链表也分好几种：单向链表、双端链表、双向链表、有序链表以及有迭代器的链表

单向链表：用户的操作（添加、删除、遍历）只能从链表头开始。向一个方向遍历，查找一个节点的时候从第一个节点开始访问下一个节点，一直访问到需要的位置，最后一个节点存储地址的部分指向空值。

双端链表：双端链表相对于单端链表多了一个特性：对最后一个链接点的引用

双向链表：单端链表只能从链表头开始正向遍历，双向链表可以逆向遍历，每个节点需要保存前一个节点和后一个节点的引用

有序链表：插入元素时，将插入的元素与头结点及其后面的结点比较，找到合适的位置插入。

有迭代器的链表：单链表的基本操作中，大部分要用到依次遍历单链表中的每一个元素。当你新增一个对单链表的操作并需要使用遍历时，你就得重新写一个for循环而实现遍历。所以将迭代（遍历）作为一种基本的ADT（抽象数据类型）操作。链表中用于处理遍历、访问和更新的方法封装到一个新的迭代器类中。

跳跃表

跳跃表：跳跃表基于有序链表的扩展，在链表上建索引，每两个结点提取一个结点到上一级，我们把抽出来的那一级叫作索引，每个跳跃表节点的层高都是1至32之间的随机数。

举例说明：

比如给一个长度为7的有序链表，节点值依次是1->3->4->5。取出所有值为奇数的节点作为关键节点（索引），这个时候要插入一个值是2的新节点，就不需要将节点一个个比较，只要比较1,3,5，确定了值在1和3之间，就可以快速插入。

加一层索引之后，查找一个结点需要遍历的结点个数减少了，虽然增加了50%的额外空间，但是查找效率提高了，同理再加一级索引，这种链表加多级索引的结构，就是跳跃表。

索引是占内存的，原始链表中存储的可能是大的对象，索引结点只要存储关键值和几个指针，并不需要存储对象，当节点本身比较大或者元素数量比较多的时候，优势必然会被放大，而缺点则可以忽略。

问题：当大量的新节点通过逐层比较，最终插入到原链表之后，上层的索引节点会慢慢的不够用，那么这个时候要怎么选取一部分节点提到上一层呢？

抛硬币法：随机决定新节点是否选拔，每向上提拔一层的几率是50%。

原因：跳跃表的删除和添加节点是无法预测的，不能保证索引绝对分步均匀，不过可以让大体趋于均匀。

插入节点的工作流程：跳跃表插入操作的时间复杂度是O（logN），空间复杂度是 O（N）。

• 第一步：新节点和上层索引节点逐个比较，找到原链表的插入位置，时间复杂度为O（logN）
• 第二步：把索引插入到原链表，时间复杂度为O（1）
• 第三步：随机决定新节点是否提升为上一级索引，结果为"正面"则提升，继续抛硬币，结果为"反面"则停止，时间复杂度为O（logN）

删除节点的工作流程：跳跃表删除操作的时间复杂度是O（logN）

• 第一步：自上而下，查找第一次出现节点的索引，并逐层找到每一层对应的节点。时间复杂度为O（logN）
• 第二步：删除每一层查找到的节点，如果该层只剩下1个节点，删除整个一层（原链表除外）。时间复杂度为O（logN）

跳跃表由zskiplistNode和skiplist两个结构组成，zskiplistNode用于表示跳跃表节点，zskiplist用于保存跳跃表节点的相关信息，比如节点的数量，以及指向表头节点和表尾节点的指针等等。

字典

字典，顾名思义，通过字典（牛津字典等）前面的目录快速定位到所要查找的单词。

在C 语言中没有这种数据结构，所以这种数据结构是Redis自己创造的，字典中的键都是唯一的，通过键可以对值来进行查询或更改。

底层是通过哈希表实现的，而哈希表又基于数组，类似于key-value的结构形式进行存储的，它的值通过哈希函数映射为数组的下标。

那什么是哈希函数呢？不急，我们慢慢道来。

前面我们讲了通过数组的方式存储值，那么数组的值和数组的下标怎么建立关联关系呢？或者说，我们怎么通过数组的下标找到数组的值呢？

在学习 ASCII 编码的时候，我们知道，a可以用97这个数值表示，b可以用98这个数值表示，以此类推，我们就可以通过单个字母用数字表达。

有了字母，那么一个单词由多个字母组成，它又该如何表达呢？

假设我有一本字典，它有10000个单词，我其中一个单词就是ab，使用ASCII编码进行表达。

ab = 97 + 98 = 195
那么存储在数组中的下标为195，这就是字母表达的基本原理，但是如果只是这样还是远远不够的，因为会出现一个数组存储多个单词的情况。

举例说明：假设有个单词有 10 个字母，那么字典的某个单词为 zzzzzzzzzz ，转换为数字：zzzzzzzzzz = 26*10 = 260。

补充说明：这个时候会发现我一本字典里10000个单词，在260这个范围内肯定是不够存储10000个单词的，10000/260=39（38.4补一位），一个数组项它要存储39个单词。

解决方案：为了保证数值的唯一，让每个数组都能够只存储一个单词，进行升级， 将单词表示的数拆开，27 的幂乘以这些位数，有26个可能的字符，以及空格，一共27个。

ab = 97乘以27的一次幂加上98乘以27的零次幂 = 27*97 + 98 = 2717。解决了数组存储多个单词的问题，又引出新的问题数组分配大空间太多了。

举例说明：假设有个单词有 10 个字母，那么字典的某个单词为 zzzzzzzzzz ，转换为数字：zzzzzzzzzz = 26的9次幂 = 7000000000000

补充说明：数组中只有小部分存放了单词，其他空间都是空着的

解决方案：将巨大的整数范围压缩到可接受的数组范围内，可以通过取余解决，一个整数被另一个整数除后的余数。

举例说明：假设要把从0-99的数字（用large表示），压缩为从0-9的数字（用number表示），后者有10个数，所以变量range 的值为10，这个转换的表达式为：

补充说明：number = large % range。当一个整数被 10 整除时，余数是在0-9之间，把从0-99的数压缩为从0-9的数，压缩率为 10 :1。

使用哈希函数向数组插入数据后，这个数组就是哈希表，它的值就是通过上面这种方式映射到数组的下标上的。

这也就是哈希函数的工作模式，它把一个大范围的数字哈希转化成一个小范围的数字，这个小范围的数对应着数组的下标。

但是这种工作模式会有一点问题：把大的数字范围压缩到小的数字范围，会有几个不同的单词哈希化到同一个数组下标，这就是所谓的哈希冲突。

问题：那么如何解决哈希冲突呢？

开放地址法：指定的数组范围大小是存储数据的两倍，有一半的空间是空的。

当冲突产生时，通过（线性探测、二次探测以及再哈希法）方法找到数组的一个空位，把单词填入，不用哈希函数得到数组的下标。

线性探测中，如果哈希函数计算的原始下标是x, 线性探测就是x+1, x+2, x+3, 以此类推，而在二次探测中，探测的过程是x+1,
x+4, x+9, x+16。这二种方式都会有聚集情况。

什么是聚集呢？当哈希表快要满的时候，每插入新的数据，都要频繁的探测插入位置，很多位置都被前面插入的数据所占用了，这称为聚集。

再哈希法：依赖关键字的探测序列，把关键字用不同的哈希函数再做一遍哈希化，用这个结果作为步长，步长在整个探测中是不变的，不过不同的关键字使用不同的步长。

链地址法：数组的每个数据项都创建一个子链表或子数组，那么数组内不直接存放单词，当产生冲突时，新的数据项直接存放到这个数组下标表示的链表中。

整数集合：顾名思义，用来保存整数值类型的集合，保证元素不会重复。

定义：

typedef struct intset{

//编码方式

uint32_t encoding;

//集合包含的元素数量

uint32_t length;

//保存元素的数组

int8_t contents[];

}intset;

contents数组声明为int8_t类型，但是contents数组并不保存任何int8_t类型的值，真正类型由encoding决定。比如：

• encoding属性的值为INTSET_ENC_INT16，contents是int16_6类型的数组，数组里的每个项是int16_t类型的是整数值。
• encoding属性的值为INTSET_ENC_INT32，contents是int32_t类型的数组，数组里的每个项是int32_t类型的整数值。
• encoding属性的值为INTSET_ENC_INT64，contents是int64_t类型的数组，数组里的每个项是int64_t的整数值。

新增的元素类型比原集合元素类型的长度大的时候，根据新元素类型增加整数集合底层数组的容量，给新元素分配空间，

将底层数组现有的所有元素都转成与新元素相同类型的元素，把转换后的元素放到正确的位置，整个元素顺序是有序的，能极大地节省内存。

压缩列表

压缩列表，它是特殊编码的连续内存块组成的顺序型数据结构，压缩列表有任意多个节点（entry），每个节点有一个字节数组或者一个整数值。

压缩列表不是用某种算法对数据进行压缩，它将数据按照一定规则编码，放在一块连续的内存区域，目的是节省内存。

压缩列表包含以下：
zlbytes：记录整个压缩列表占用的内存字节数。
zltail：记录压缩列表表尾节点距离压缩列表的初始地址有多少字节。
zllen：记录压缩列表包含的节点数量。
zlend：用来标记压缩列表的末端。
entryX：列表的节点，包含

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

总结：
简单字符串：SDS作为redis专门为字符串存取开发的数据结构，有获取字符串长度快，杜绝了缓存区的溢出，减少了修改字符串长度时所需的内存重分配次数，二进制安全，兼容部分C函数
链表：用作列表键、发布与订阅、慢查询、监视器等功能实现。
字典：用哈希表实现，字典有两个哈希表，一个正常使用，另一个用于rehash时使用，链地址法解决哈希冲突。
跳跃表：表中的节点按照分值大小进行排序。
整数集合：底层由数组构成，升级特性能尽可能的节省内存。
压缩列表：顺序型数据结构。
​

Redis五大数据类型的应用场景

各数据类型应用场景

• 工作中有很多场景经常用到redis， 比如在使用String类型的时候，字符串的长度不能超过512M，可以set存储单个值，也可以把对象转成json字符串存储；还有我们经常说到的分布式锁，就是通过setnx实现的，返回结果是1就说明获取锁成功，返回0就是获取锁失败，这个值已经被设置过。又或者是网站访问次数，需要有一个计数器统计访问次数，就可以通过incr实现。

• 除了字符串类型，还有hash类型，它比string类型操作消耗内存和cpu更小，更节约空间。像我之前做过的电商项目里面，购物车实现场景可以通过hset添加商品，hlen获取商品总数，hdel删除商品，hgetall获取购物车所有商品。另外如果缓存对象的话，修改多个字段就不需要像String类型那样，取出值进行类型转换，然后设值进行类型转换，把它转成字符串缓存进行了。

• 还有列表list这种类型，是简单的字符串列表，按照插入顺序排序，可以添加一个元素到列表的头部或者尾部，它的底层实际上是个链表结构。这种类型更多的是用在文章发布上面，类似微博消息和微信公众号文章，在我之前的项目里面也有用到，比如说我关注了二个媒体，这二个媒体先后发了新闻，我就可以看到先发新闻那家媒体的文章，它可以通过lpush+rpop队列这种数据结构实现先进先出，当然也可以通过lpush+lpop实现栈这种数据结构来到达先进后出的功能。

• 然后就是集合set，底层是字典实现的，查找元素特别快，另外set 数据类型不允许重复，利用这两个特性我们可以进行全局去重，比如在用户注册模块，判断用户名是否注册。可以通过sadd、smembers等命令实现微信抽奖小程序，微信微博点赞，收藏，标签功能。还可以利用交集、并集、差集的特性实现微博微信的关注模型，交集和并集很好理解，差集可以解释一下，就是用第一个集合减去其他集合的并集，剩下的元素，就是差集。举个微博关注模型的例子，我关注了张三和李四，张三关注了李四和王五，李四关注了我和王五。
  我进入了张三的主页
  查看共同关注的人（李四），取出我关注的人和张三关注的人，二个集合取交集得出结果是李四，就是通过SINTER交集实现的。
  查看我可能认识的人（王五），取出我关注的人和张三关注的人，二个集合取并集得出结果是（张三，李四，王五），拿我关注的人（张三，李四）减去并集里的元素，剩下的王五就是我可能认识的人，可以通过并集和差集实现。
  查看我关注的人也关注了他（王五），取出我关注的人他们关注的人，（李四，王五）（我，王五）的交集，就是王五。

• 最后就是有序集合zset，有序的集合，可以做范围查找，比如说排行榜，展示当日排行前十。

Redis五大数据类型实现原理

对于五大数据类型（String,list,Hash,Set,Zset）实现原理，Redis在底层用到了多种数据结构，通过数据结构来实现键值对，将数据结构创建了一个对象redisObject，根据对象的类型type，为对象设置多种不同的数据结构，对象可以执行特定的命令。

本章主要涉及到的知识点有：

• redisObject的属性
• 五大数据类型编码

注意：本章内容每一小节可单独学习，无论先后。

redisObject属性

学完本章中，读者需要回答：
1．Redis底层数据结构如何实现？
2．Redis是如何回收内存？
Redis的一个键值对，有两个对象，一个是键对象，一个是值对象，键总是一个字符串对象，而值可以是字符串、列表、集合等对象，Redis中的值对象都是由 redisObject 结构来表示：

typedef struct redisObject{
     //表示类型：string,list,hash,set,zset
     unsigned type:4;
     //编码：比如字符串的编码有int编码，embstr编码，raw编码
     unsigned encoding:4;
     //指向底层数据结构的指针，prt是个指针变量，存放地址，指向数据存储的位置
     void *ptr;
     //引用计数，类似java里的引用计数
     int refcount;
     //记录最后一次被程序访问的时间
     unsigned lru:22;
}robj

type属性

redisObject 对象的type属性记录了对象的类型（string,list,hash,set,zset），可以通过type key命令来判断对象类型，从而区分redis中key-value的类型

127.0.0.1:6379> set testString testValue
OK
127.0.0.1:6379> lpush testList testValue1 testValue2 testValue3
(integer) 3
127.0.0.1:6379> hmset testhash 1:testvalue 2:testvalue2
OK
127.0.0.1:6379> sadd testset testvalue
(integer) 1
127.0.0.1:6379> zadd testzset 1 testvalue
(integer) 1
127.0.0.1:6379> type testString
string
127.0.0.1:6379> type testList
list
127.0.0.1:6379> type testhash
hash
127.0.0.1:6379> type testset
set
127.0.0.1:6379> type testzset
zset

prt和encoding属性

redisObject 对象的 prt 指针，存放数据的地址，指向对象底层的数据结构，通过它可以找到数据的位置。

refcount 属性

由于C语言跟贴近操作系统，直接跟操作系统交互，命令执行响应比较快，所以Redis选择C语言进行编写可以提高性能，但是C 语言不具备自动回收内存功能，于是乎Redis自己构建了一个内存回收机制。
创建一个新对象，redisObject 对象中的refcount属性就会加1，对象被一个新程序使用，调用incrRefCount函数进行加 1，如果有对象不再被应用程序使用了，那么它就会调用decrRefCount函数进行减 1，当对象的引用计数值为 0 的时候，那么这个对象所占用的内存就会被释放。
从这里可以看出来，这其实就是Java虚拟机中引用计数的内存回收机制，在Java中这种回收机制不被使用，因为它不能解决循环引用的问题。
循环引用举例：A引用B，B引用C，C引用A。

Redis通过在配置文件中修改相关的配置，来达到解决循环引用的问题，在Redis的配置文件里，Windows的配置文件是redis.windows.conf,Linux系统的配置文件是redis.conf。
在配置文件中有一个配置：maxmemory-policy，当内存使用达到最大值时，redis使用的清楚策略，默认配置是noeviction

1）volatile-lru 删除已有的过期时间的key
2）allkeys-lru 删除所有的key
3）volatile-random 已有过期时间的key 随机删除
4）allkeys-random 随机删除key
5）volatile-ttl 删除即将过期的key
6）noeviction 不删除任何key，只是返回一个写错误，这个是默认选项 对于整数值的字符串对象（例如：1,2,3这种的）可实现内存共享。

问题：什么是内存共享？
定义：键不同，值相同。
举例：输入命令set key1 1024,键为 key1，值为1024的字符串对象，接着输入命令 set key2 1024 ，键为 key2，值为1024 的字符串对象。这个时候，有二个不同的键，一个相同的值。
实现原理：键的值，指针指向一个有值的对象，被共享的值对象引用refcount 加 1。
局限性：判断两个对象是否相等需要消耗运算的额外的时间。整数值，判断操作复杂度低；普通字符串，判断复杂度相比较而已是高的；哈希、列表、集合和有序集合，判断的复杂度更高，所以内存共享只适用于整数值的字符串。

lru 属性

Lru属性是redisObject 记录对象最后一次被命令程序访问的时间，用来辅助lru算法删除过期内存的。
在Redis 配置文件中有三个配置，最大内存配置 maxmemory，触发数据淘汰后的淘汰策略 maxmemory_policy，随机采样的精度maxmemory_samples。

当有条件符合配置文件中三个配置的时候，继续往Redis中加key时，会触发执行 lru 策略，进行内存清除。最近最少使用，lru算法根据数据的历史访问记录进行数据淘汰。

Lru策略的运行原理是数据插入到链表头部，当缓存数据被访问之后，数据会移到链表头，链表满的时候，链表尾部的数据会被丢弃。

redis配置中的淘汰策略（maxmemory_policy）对应的值：

• Noeviction：缓存里的数据超过maxmemory值，这个时候如果客户端正在执行命令，会让内存分配，给客户端返回错误响应
• allkeys-lru： 所有的key都用LRU进行淘汰。
• volatile-lru： LRU策略淘汰已经设置过过期时间的键。
• allkeys-random：随机淘汰使用的。
• key volatile-random：随机淘汰已设置过过期时间的key
• volatile-ttl：只回收设置了过期时间的key

从redis缓存中淘汰数据，我们的需求是淘汰一些不可能被使用的数据，保留有些以后可能会频繁访问的数据，频繁访问的数据，将来被访问的可能性大很多，所以redis它记录每个数据的最后一次访问时间（lru记录的时间），通过当前时间减去键值对象lru记录的时间，最后可以计算出最少空闲时间，最少空闲时间的数据是最有可能被访问到，这就是LRU淘汰策略的设计思想，是不是很棒。
举例说明：
A数据每10s访问一次，B数据每5s访问一次，C数据每50s访问一次，|代表计算空闲时间的截止点。

预测被访问的概率是B > A > C。

过期key的删除策略有两种：
惰性删除：每次获取键时，都检查键是否过期，过期的话，就删除该键；未过期，就返回该键。
定期删除：每隔一段时间，进行一次检查，删除里面的过期键。

encoding属性

数据结构由 encoding 属性，也就是编码，由它来决定,可以通过object encoding key命令查看一个值对象的编码。

127.0.0.1:6379> object encoding testString
"embstr"
127.0.0.1:6379> object encoding testList
"quicklist"
127.0.0.1:6379> object encoding testhash
"ziplist"
127.0.0.1:6379> object encoding testset
"hashtable"
127.0.0.1:6379> object encoding testzset
"ziplist"

String类型编码

我们最常使用的redis的一个数据类型就是String类型，实现单值缓存，分布式锁，计数器，分布式系统全局序列号等等功能。

它的底层编码分为三种，int，raw或者embstr。

int编码：存储整数值(例如：1,2,3)，当 int 编码保存的值不再是整数值，又或者值的大小超过了long的范围，会自动转化成raw。例如：(1,2,3)->(a,b,c)
embstr编码：存储短字符串。
它只分配一次内存空间，redisObject和sds是连续的内存，查询效率会快很多，也正是因为redisObject和sds是连续在一起，伴随了一些缺点：当字符串增加的时候，它长度会增加，这个时候又需要重新分配内存，导致的结果就是整个redisObject和sds都需要重新分配空间，这样是会影响性能的，所以redis用embstr实现一次分配而后,只允许读，如果修改数据，那么它就会转成raw编码，不再用embstr编码了。
raw编码：用来存储长字符串。
它可以分配两次内存空间，一个是redisObject，一个是sds，二个内存空间不是连续的内存空间。和embstr编码相比，它创建的时候会多分配一次空间，删除时多释放一次空间。
版本区别：
embstr编码版本之间的区别：在redis3.2版本之前，用来存储39字节以内的数据，在这之后用来存储44字节以内的数据。
raw编码版本之间的区别：和embstr相反，redis3.2版本之前，可用来存储超过39字节的数据，3.2版本之后，它可以存储超过44字节的数据。
问题一：为什么是39字节？
从上面可以得知，embstr是一块连续的内存区域，由redisObject和sdshdr组成。
embstr最多占64字节场景：
redisObject占16个字节

struct RedisObject {
    int4 type; // 4bits,不同的redis对象会有不同的数据类型(string、list、hash等)，type记录类型，会用到4bits。
    int4 encoding; // 4bits,存储编码形式，用4bits。
    int24 lru; // 24bits,用24bits记录对象的LRU信息
    int32 refcount; // 4bytes = 32bits,引用计数器，用到32bits
    void *ptr; // 8bytes，64-bit system,指针指向对象的具体内容，需要64bits
}

计算： 4 + 4 + 24 + 32 + 64 = 128bits = 16bytes
sdshdr占48字节

struct sdshdr {
    unsigned int len;//4个字节
    unsigned int free;//4个字节
    char buf[];//假设buf里面是39个字节
};

if (ptr) {
        memcpy(sh->buf,ptr,len);
        sh->buf[len] = '\0';//一个字节

sdshdr的大小为8+39+1=48
那么一个embstr最多占64字节：16+48（4+4+1+39）=64

从2.4版本开始，redis用jemalloc内存分配器，比glibc的malloc要好一些，省内存，jemalloc会分配8，16，32，64等类型字节的内存。
embstr最小为33字节场景：
从上面我们可以得知redisObject占16个字节，现在buf中取8字节。

struct sdshdr {
    unsigned int len;//4个字节
    unsigned int free;//4个字节
    char buf[];//假设buf里面是8个字节
};

if (ptr) {
        memcpy(sh->buf,ptr,len);
        sh->buf[len] = '\0';//一个字节

sdshdr的大小为4+4+8+1=17
计算得出：16+17(4+4+1+8)=33
8,16,32都比33字节小，所以最小分配64字节。
通过对比：
16+17(4+4+1+8)=33
16+48（4+4+1+39）=64
当字符数大于8时，会分配64字节。当字符数小于39时，会分配64字节。这个默认39就是这样来的。

问题二：为什么分界值由39字节会变成44字节？
被暴打的回答是：REDIS_ENCODING_EMBSTR_SIZE_LIMIT值被换成了44了。

##define REDIS_ENCODING_EMBSTR_SIZE_LIMIT 39
##define REDIS_ENCODING_EMBSTR_SIZE_LIMIT 44

正经的回答是：
每个sds都有一个sdshdr，里面的len和free记录了这个sds的长度和空闲空间。

struct sdshdr {
    unsigned int len;
    unsigned int free;

用的unsigned int可以表示很大的范围，短的sds空间被浪费了(unsigned int len和unsigned int free 8个字节)
commit之后，unsigned int 变成了uint8_t,uint16_t,uint32_t

struct __attribute__ ((__packed__)) sdshdr8 {
    uint8_t len; /* used */
    uint8_t alloc; /* excluding the header and null terminator */
    char flags; /* 2 lsb of type, and 6 msb of refcount */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr16 {
    uint16_t len; /* used */
    uint16_t alloc; /* excluding the header and null terminator */
    char flags; /* 2 lsb of type, and 6 msb of refcount */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr32 {
    uint32_t len; /* used */
    uint32_t alloc; /* excluding the header and null terminator */
    char flags; /* 2 lsb of type, and 6 msb of refcount */
    char buf[];
};
struct __attribute__ ((__packed__)) sdshdr64 {
    uint64_t len; /* used */
    uint64_t alloc; /* excluding the header and null terminator */
    char flags; /* 2 lsb of type, and 6 msb of refcount */

除此之外还将原来的sdshdr改成了sdshdr16，sdshdr32，sdshdr64

sizes = sdscatprintf(sizes,"sdshdr:%d", (int)sizeof(struct sdshdr));
改成了
sizes = sdscatprintf(sizes,"sdshdr8:%d", (int)sizeof(struct sdshdr8));
sizes = sdscatprintf(sizes,"sdshdr16:%d", (int)sizeof(struct sdshdr16));
sizes = sdscatprintf(sizes,"sdshdr32:%d", (int)sizeof(struct sdshdr32));
sizes = sdscatprintf(sizes,"sdshdr64:%d", (int)sizeof(struct sdshdr64));

unsigned int占四个字节
uint8_t 占1个字节
Char 占一个字节
我们通过计算可以得出为什么优化之后会多出5个字节了，短字符串的embstr用最小的sdshdr8。
sdsdr8 = uint8_t _ 2 + char = 1_2+1 = 3
sdshdr = unsigned int _ 2 = 4 _ 2 = 8
这么一算是不是少了五个字节了，所以3.2版本更新之后，由于优化小sds的内存使用，使得原本39个字节可以多使用5个字节，这就变成了44字节了。
问题三：Redis字符串最大长度是多少？
512M，查看源码可知。

static int checkStringLength(redisClient *c, long long size) {
    if (size > 512*1024*1024) {
        addReplyError(c,"string exceeds maximum allowed size (512MB)");
        return REDIS_ERR;
    }
    return REDIS_OK;
}

List集合对象编码

List类型可以实现栈，队列，阻塞队列等数据结构，底层是个链表结构，它的底层编码分二种：ziplist(压缩列表) 和 linkedlist(双端链表)。
超过配置的数量或者最大的元素超过临界值时，符合配置的值，触发机制会选择不同的编码。
列表保存元素个数小于512个，每个元素长度小于64字节的时候触发机制会使用ziplist（压缩列表）编码，否则使用linkedlist（双端链表）。
在redis.conf(linux系统)或者redis.windows.conf(windows系统)对应的配置：

list-max-ziplist-entries 512
list-max-ziplist-value 64

通过修改配置这二个配置，设置触发条件选择编码。比如我修改列表保存元素个数小于1024个并且每个元素长度小于128字节时使用ziplist（压缩列表）编码，否则使用linkedlist（双端链表）。修改配置如下：

list-max-ziplist-entries 1024
list-max-ziplist-value 128

list列表的编码，3.2之前最开始的时候是用ziplist压缩列表，当列表保存元素个数超过512个，每个元素长度超过64字节就会切换编码，改用linkedlist双端链表，ziplist会有级联更新的情况，时间复杂度高，除此之外链表需要维护额外的前后节点，占用内存，所以元素个数到达一定数量就不能再用ziplist了。

新版本的Redis对列表的数据结构进行了改造，使用quicklist代替了原有的数据几个，quicklist是ziplist和linkedlist的混合体，它让每段ziplist连接起来，对ziplist进行LZF算法压缩，默认每个ziplist长度8KB。

ziplist压缩列表是由一些连续的内存块组成的，有顺序的存储结构，是一种专门节约内存而开发的顺序型数据结构。在物理内存固定不变的情况下，随着内存慢慢增加会出现内存不够用的情况，这种情况可以通过调整配置文件中的二个参数，让list类型的对象尽可能的用压缩列表编码，从而达到节约内存的效果，但是也要均衡一下编码和解码对性能的影响，如果有一个几十万的列表长度进行列表压缩的话，在查询和插入的时候，进行编解码会对性能造成特别大的损耗。

如果有不可避免的长列表的存储的话，需要在代码层面配合降低redis存储的内存，在存储redis的key的时候，在保证唯一性和可读性的时候，尽量简化redis的key，可以比较直接的节约redis空间的一个作用，还有就是对长列表进行拆分，比如说有一万条数据，压缩列表的保存元素的个数配置的是2048，我们就可以将一万条数据拆分成五个列表进行缓存，将它的元素个数控制在压缩列表配置的2048以内，当然这么做需要对列表的key进行一定的控制，当要进行查询的时候，可以精准的查询到key存储的数据。

这是对元素个数的一个控制，元素的长度也类似，将每个大的元素，拆分成小的元素，保证不超过配置文件里面每个元素大小，符合压缩列表的条件就可以了，核心目标就是保证这二个参数在压缩列表以内，不让它转成双端列表，并且在编解码的过程中，性能也能得到均衡，达到节约内存的目的。

除了上面的优化可以进行内存优化以外，还可以看我们缓存的数据，是不是可以打包成二进制位和字节进行存储，比如用户的位置信息，以上海市黄浦区举例说明，可以把上海市，黄浦区弄到我们的数组或者list里面，然后只需要存储上海市的一个索引0和黄浦区的一个索引1，直接将01存储到redis里面即可，当我们从缓存拿出这个01信息去数组或者list里面取到真正的一个消息。

Hash对象编码

Hash类型比string类型消耗内存和cpu更小。Hash的编码有二种 ziplist编码 或者 hashtable。
超过指定的值，最大的元素超过临界值时，符合配置的值，触发机制选择不同的编码。列表保存元素个数小于512个，每个元素长度小于64字节的时候，使用ziplist（压缩列表）编码，否则使用hashtable 。
配置文件中可以通过修改set-max-intset-entries 1024达到改变列表保存元素个数小于1024个，原理类似。
hashtable 编码是字典作为底层实现，字典的键是字符串对象，值则全部设置为 null。在上面的字典也有详细介绍。

Set集合对象编码

Set类型可以实现抽奖小程序，点赞，收藏，加标签，关注模型等功能。Set的编码有二种intset 或者 hashtable。
超过指定的值，最大的元素超过临界值时，符合配置条件，触发机制选择不同的编码。集合对象中所有元素都是整数，对象元素数量不超过512时，使用intset编码，否则使用hashtable。原理大致和上面的类型相同。
列表保存元素个数的配置也是通过set-max-intset-entries进行修改的。
intset 编码用整数集合作为底层实现，hashtable编码可以类比HashMap的实现，HashTable类中存储的实际数据是Entry对象，数据结构与HashMap是相同的。

Zset有序集合对象编码

Zset适合做排序以及范围查询等功能，比如实现实现排行榜等。有序集合的编码有二种 ziplist 或者 skiplist。
保存的元素数量小于128，存储的所有元素长度小于64字节的时候，使用ziplist编码，否则用skiplist编码。修改配置如下：

zset-max-ziplist-entries 128
zset-max-ziplist-value 64

ziplist 编码底层是用压缩列表实现的，集合元素是两个紧挨在一起的压缩列表节点来保存，第一个节点保存元素的成员，第二个节点保存元素的分值。 压缩列表的集合元素按照设置的分值从小到大的顺序进行排列，小的放置在靠近表头的位置，大的放置在靠近表尾的位置。
skiplist 编码的有序集合对象使用 zet 结构作为底层实现，一个 zset 结构同时包含一个字典和一个跳跃表。

当不满足这二个条件的时候，skiplist编码，skiplist编码的有序集合对象使用zet 结构作为底层实现，一个 zset 结构同时包含一个字典和一个跳跃表，字典的键保存元素的值，字典的值则保存元素的分值；跳跃表由zskiplistNode和skiplist两个结构，跳跃表skiplist中的object属性保存元素的成员，score 属性保存元素的分值。这两种数据结构会通过指针来共享相同元素的成员和分值，所以不会产生重复成员和分值，造成内存的浪费。

问题：为什么需要二种数据结构？
假如我们单独使用字典，虽然能直接通过字典的值查找成员的分值，但是因为字典是以无序的方式来保存集合元素，所以每次进行范围操作的时候都要进行排序；
假如我们单独使用跳跃表来实现，虽然能执行范围操作，但是查找操作就会变慢，所以Redis使用了两种数据结构来共同实现有序集合。

除了这二个属性之外，还有层属性，跳跃表基于有序链表的，在链表上建索引，每两个结点提取一个结点到上一级，我们把抽出来的那一级叫作索引，每个跳跃表节点的层高都是1至32之间的随机数。

比如有一个有序链表，节点值依次是1->3->4->5。取出所有值为奇数的节点作为索引，这个时候要插入一个值是2的新节点，就不需要将节点一个个比较，只要比较1,3,5，确定了值在1和3之间，就可以快速插入，加一层索引之后，查找一个结点需要遍历的结点个数减少了，虽然增加了50%的额外空间，但是查找效率提高了。

当大量的新节点通过逐层比较，最终插入到原链表之后，上层的索引节点会慢慢的不够用，由于跳跃表的删除和添加节点是无法预测的，不能保证索引绝对分步均匀，所以通过抛硬币法：随机决定新节点是否选拔，每向上提拔一层的几率是50%，让大体趋于均匀。
​

Redis持久化

面试题：Redis 的持久化有哪几种方式？不同的持久化机制都有什么优缺点？持久化机制具体底层是如何实现的？save与bgsave？

持久化主要是做灾难恢复、数据恢复，高可用。比如你 redis 整个挂了，然后 redis 就不可用了，我们要做的事情就是让 redis 变得可用，尽快变得可用。 重启 redis，尽快让它堆外提供服务，如果没做数据备份，这时候 redis 启动了，也不可用啊，数据都没了。把 redis 持久化做好， 那么即使 redis 故障了，也可以通过备份数据，快速恢复，一旦恢复立即对外提供服务。

redis持久化有三种方式：RDB，AOF，（RDB和AOF）混合持久化

默认情况下， Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中，也就是RDB快照。

RDB 持久化机制，是对 redis 中的数据执行周期性的持久化。

AOF 持久化机制，是对每条写入命令作为日志，重启的时候，可以通过回放日志中的写入指令来重新构建整个数据集。

不同的持久化机制都有什么优缺点？

RDB持久化

RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中 redis 的数据。 redis 主进程只需要 fork一个子进程，让子进程执行磁盘 IO 操作来进行 RDB持久化，对外提供的读写服务，影响非常小。但是如果数据文件特别大，可能会导致对客户端提供的服务暂停数秒。 RDB 数据文件来重启和恢复 redis 进程更快 RDB会丢失某一时间段的数据，一般来说，RDB 数据快照文件，都是每隔 5分钟，或者更长时间生成一次，这个时候就得接受一旦 redis 进程宕机，那么会丢失最近 5 分钟的数据。

AOF持久化

AOF 可以更好的保护数据不丢失，一般 AOF 每隔 1 秒，通过一个后台线程执行一次fsync操作，最多丢失 1 秒钟的数据。 AOF日志文件以 append-only 模式写入，所以没有任何磁盘寻址的开销，写入性能很高，而且文件不容易破损。 AOF 日志文件即使过大的时候，可以进行后台重写操作，也不会影响客户端的读写。在重写的时候，会进行压缩，创建出一份最小恢复数据的日志出来。在创建新日志文件的时候，老的日志文件还是照常写入。新日志文件创建完成以后，再去读的时候，交换新老日志文件就可以了。某人不小心用 flushall 命令清空了所有数据，只要这个时候后台重写命令还没有发生，那么就可以立即拷贝 AOF 文件，将最后一 flushall 命令给删了，然后再将该 AOF 文件放回去，就可以通过恢复机制，自动恢复所有数据。 AOF 日志文件通常比 RDB数据快照文件更大。 支持的写 QPS 会比 RDB 支持的写 QPS 低，因为 AOF 一般会配置成每秒 fsync一次日志文件，当然，每秒一次 fsync，性能也还是很高的。

混合持久化

仅仅使用 RDB，会导致丢失很多数据 仅仅使用 AOF，速度慢，支持的QPS低，性能不高 开启开启两种持久化方式，用 AOF 来保证数据不丢失，作为数据恢复的第一选择; 在 AOF 文件都丢失或损坏不可用的时候，还可以使用 RDB 来进行快速的数据恢复。

持久化底层实现原理

持久化机制具体底层是如何实现的？

RDB持久化底层实现原理

RDB持久化可以通过配置与手动执行命令生成RDB文件。 可以对 Redis 进行设置， 让它在“ N 秒内数据集至少有 M个改动”这一条件被满足时， 自动保存一次数据集。比如说设置让 Redis 在满足“ 60 秒内有至少有 1000 个键被改动”，自动保存一次数据集。通过 save 60 1000 命令生成RDB快照，关闭RDB只需要将所有的save保存策略注释掉即可。手动执行命令生成RDB快照，进入redis客户端执行命令save或bgsave可以生成dump.rdb文件，每次命令执行都会将所有redis内存快照到一个新的rdb文件里，并覆盖原有rdb快照文件。

AOF持久化底层实现原理

AOF持久化可以通过配置与手动执行命令生成RDB文件。 通过配置# appendonly yes 开启AOF持久化， 每当 Redis 执行一个改变数据集的命令时， 这个命令就会被追加到 AOF 文件的末尾，当 Redis 重新启动时， 程序就可以通过重新执行 AOF 文件中的命令来达到重建数据集的目的，配置 Redis 多久才将数据 fsync 到磁盘一次，默认的措施为每秒 fsync 一次。AOF文件里可能有太多没用指令，所以AOF会定期根据内存的最新数据重新生成aof文件，可以通过配置文件达到64M才会自动重写，也可以配置aof文件自上一次重写后文件大小增长了100%则再次触发重写 手动执行命令bgrewriteaof重写AOF，AOF重写redis会fork出一个子进程去做(与bgsave命令类似)，不会对redis正常命令处理有太多影响。

混合持久化底层实现原理

通过配置# aof-use-rdb-preamble yes 开启混合持久化，开启了混合持久化，AOF在重写时，不再是单纯将内存数据转换为RESP命令写入AOF文件，而是将重写这一刻之前的内存做RDB快照处理，并且将RDB快照内容和增量的AOF修改内存数据的命令存在一起，都写入新的AOF文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改名，覆盖原有的AOF文件，完成新旧两个AOF文件的替换。于是在 Redis 重启的时候，可以先加载 RDB 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，因此重启效率大幅得到提升。

save与bgsave

bgsave 子进程是由主线程 fork 生成的，可以共享主线程的所有内存数据。bgsave 子进程运行后，开始读取主线程的内存数据，并把它们写入 RDB 文件。此时，如果主线程对这些数据也都是读操作，那么，主线程和 bgsave 子进程相互不影响。但是，如果主线程要修改一块数据，那么，这块数据就会被复制一份，生成该数据的副本。然后，bgsave 子进程会把这个副本数据写入 RDB 文件，而在这个过程中，主线程仍然可以直接修改原来的数据。 save 它是同步阻塞的，会阻塞客户端命令和redis其它命令，和bgsave相比不会消耗额外内存。

缓存雪崩

一个系统，高峰期请求为5000次/秒，4000次走了缓存，只有1000次落到了数据库上，数据库每秒1000的并发是一个正常的指标，完全可以正常工作，但如果缓存宕机了，或者缓存设置了相同的过期时间，导致缓存在同一时刻同时失效，每秒5000次的请求会全部落到数据库上，数据库立马就死掉了，因为数据库一秒最多抗2000个请求，如果DBA重启数据库，立马又会被新的请求打死了，这就是缓存雪崩。

解决方案：

事前：redis高可用，主从+哨兵，redis cluster，避免全盘崩溃 事中：本地ehcache缓存 + hystrix限流&降级，避免MySQL被打死

事后：redis持久化RDB+AOF，快速恢复缓存数据 缓存的失效时间设置为随机值，避免同时失效

缓存穿透

客户端每秒发送5000个请求，其中4000个为黑客的恶意攻击，即在数据库中也查不到。举个例子，用户id为正数，黑客构造的用户id为负数，如果黑客每秒一直发送这4000个请求，缓存就不起作用，数据库也很快被打死。

解决方案：

对请求参数进行校验，不合理直接返回 查询不到的数据也放到缓存，value为空，如 set -999 “” 使用布隆过滤器，快速判断key是否在数据库中存在，不存在直接返回

缓存击穿

设置了过期时间的key，承载着高并发，是一种热点数据。从这个key过期到重新从MySQL加载数据放到缓存的一段时间，大量的请求有可能把数据库打死。缓存雪崩是指大量缓存失效，缓存击穿是指热点数据的缓存失效。

解决方案：

设置key永远不过期，或者快过期时，通过另一个异步线程重新设置key 当从缓存拿到的数据为null，重新从数据库加载数据的过程上分布式锁。
​

布隆过滤器

需求

①、原本有10亿个号码，现在又来了10万个号码，要快速准确判断这10万个号码是否在10亿个号码库中？ 解决办法一：将10亿个号码存入数据库中，进行数据库查询，准确性有了，但是速度会比较慢。 解决办法二：将10亿号码放入内存中，比如Redis缓存中，这里我们算一下占用内存大小：10亿*8字节=8GB，通过内存查询，准确性和速度都有了，但是大约8gb的内存空间，挺浪费内存空间的。
②、接触过爬虫的，应该有这么一个需求，需要爬虫的网站千千万万，对于一个新的网站url，我们如何判断这个url我们是否已经爬过了？ 解决办法还是上面的两种，很显然，都不太好。
③、同理还有垃圾邮箱的过滤 大数据量集合，如何准确快速的判断某个数据是否在大数据量集合中，并且不占用内存。

布隆过滤器定义

一种数据结构，是由一串很长的二进制向量组成，可以将其看成一个二进制数组。既然是二进制，那么里面存放的不是0，就是1，但是初始默认值都是0。将布隆过滤器看成一个容器，那么如何向布隆过滤器中添加一个数据呢？数组是从0开始计数的，当要向布隆过滤器中添加一个元素key时，我们通过多个hash函数，算出一个值，然后将这个值所在的方格置为1。

布隆过滤器判断数据是否存在？

将这个新的数据通过自定义的几个哈希函数，分别算出各个值，然后看其对应的地方是否都是1，如果存在一个不是1的情况，那么我们可以说，该新数据一定不存在于这个布隆过滤器中。多个不同的数据通过hash函数算出来的结果是会有重复的，所以会存在某个位置是别的数据通过hash函数置为的1。布隆过滤器可以判断某个数据一定不存在，但是无法判断一定存在。

布隆过滤器优缺点

优点：二进制组成的数组，占用内存极少，并且插入和查询速度都足够快。
缺点：随着数据的增加，误判率会增加，无法判断数据一定存在，无法删除数据。

布隆过滤器的实现

1. guava 工具包提供了布隆过滤器的实现。
2. Redis 实现布隆过滤器的底层就是通过 bitmap数据结构实现的，计算机以二进制位作为底层存储的基础单位，一个字节等于8位，可以通过修改二进制某个位置上的0或者1达到修改值的目的。比如：将big改为cig，"b"的二进制表示为0110 0010，我们将第7位（从0开始）设置为1，那0110 0011表示的就是字符“c”，所以最后的字符 “big”变成了“cig”。

Redis分布式寻址算法

在集群模式下，Redis 的 key 是如何寻址的？分布式寻址都有哪些算法？了解一致性 hash 算法吗？如何动态增加和删除一个节点？

hash 算法（大量缓存重建） 一致性 hash 算法（自动缓存迁移）+ 虚拟节点（自动负载均衡） Redis cluster 的 hash slot 算法

hash 算法

来了一个 key，首先计算 hash 值，然后对节点数取模，接着打在不同的 master 节点上。缺点也很明显：某一个 master 节点宕机，所有请求过来，都会基于最新的剩余 master 节点数去取模，尝试去库中取数据进行缓存。这会导致大部分的请求过来，全部无法拿到有效的缓存，导致大量的流量涌入数据库。

一致性 hash 算法

将整个 hash 值空间组织成一个虚拟的圆环，整个空间按顺时针方向组织，下一步将各个 master 节点（使用服务器的 ip 或主机名）进行 hash。来了一个 key，首先计算 hash 值，并确定此数据在环上的位置，从此位置沿环顺时针“行走”，遇到的第一个 master 节点就是 key 所在位置，这样就能确定每个节点在其哈希环上的位置。在一致性哈希算法中，如果一个节点挂了，受影响的数据仅仅是此节点到环空间前一个节点（沿着逆时针方向行走遇到的第一个节点）之间的数据，其它不受影响。增加一个节点也同理。 虚拟节点：一致性哈希算法在节点太少时，容易因为节点分布不均匀而造成缓存热点的问题。为了解决这种热点问题，一致性 hash 算法引入了虚拟节点机制，即对每一个节点计算多个 hash，每个计算结果位置都放置一个虚拟节点。这样就实现了数据的均匀分布，负载均衡。

hash slot 算法

Redis cluster 有固定的 16384 个 hash slot，slot是槽的概念（理解为数据管理和迁移的基本单位），所有的键根据哈希函数映射到 0~16383 整数槽内，每个节点负责维护一部分槽以及槽所映射的键值数据。 公式：slot = CRC16（key）& 16384。解释：对每个 key 计算 CRC16 值，然后对 16384 取模，可以获取 key 对应的 hash slot。hash slot可以像磁盘分区一样自由分配槽位，在配置文件里可以指定，也可以让redis自己选择分配，结果均匀，这种结构很容易添加或者删除节点。如果增加一个节点，就需要从节点已有的节点 获得部分槽分配到新的节点 上。如果想移除已有的一个节点，需要将节点中的槽移到其他节点上，然后将没有任何槽的节点从集群中移除就可以了。由于缓存的key hash结果是和slot绑定的，而不是和服务器节点绑定，所以节点的更替只需要迁移slot即可平滑过渡。从一个节点将哈希槽移动到另一个节点并不会停止服务，所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态。
​

Redis过期策略

Redis采用的过期策略
惰性删除+定期删除

惰性删除流程

在进行get或setnx等操作时，先检查key是否过期，若过期，删除key，然后执行相应操作；若没过期，直接执行相应操作

定期删除流程

对指定个数个库的每一个库随机删除小于等于指定个数个过期key，遍历每个数据库（就是redis.conf中配置的"database"数量，默认为16），检查当前库中的指定个数个key（默认是每个库检查20个key，注意相当于该循环执行20次，循环体时下边的描述），如果当前库中没有一个key设置了过期时间，直接执行下一个库的遍历，随机获取一个设置了过期时间的key，检查该key是否过期，如果过期，删除key，判断定期删除操作是否已经达到指定时长，若已经达到，直接退出定期删除。

问题：定期删除漏掉了很多过期 key，然后你也没及时去查，也就没走惰性删除，此时会怎么样？如果大量过期 key 堆积在内存里，导致 Redis 内存块耗尽了，怎么解决呢？走内存淘汰机制。
​

内存淘汰机制

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

默认就是如果满的话就拒绝抛异常，正常一般用LFU和LRU二种。LFU是基于梯形数组，每个数组上面就挂了一个Counter，Counter是用来统计它的服务次数的，通过访问次数来进行升级，LFU的LRU字段里面高16位存储一个分钟数级别的时间戳，低8位存储的是一个Counter访问计数。和LRU相比，LFU避免了LRU基于最近一段时间的访问没有访问数据，突然访问变成热点数据，导致内存淘汰，没有真正意义上达到冷数据的淘汰。

RDB对过期key的处理

过期key对RDB没有任何影响，从内存数据库持久化数据到RDB文件：持久化key之前，会检查是否过期，过期的key不进入RDB文件 从RDB文件恢复数据到内存数据库：数据载入数据库之前，会对key先进行过期检查，如果过期，不导入数据库（主库情况）

AOF对过期key的处理

过期key对AOF没有任何影响 从内存数据库持久化数据到AOF文件：当key过期后，还没有被删除，此时进行执行持久化操作（该key是不会进入aof文件的，因为没有发生修改命令）当key过期后，在发生删除操作时，程序会向aof文件追加一条del命令（在将来的以aof文件恢复数据的时候该过期的键就会被删掉） AOF重写：重写时，会先判断key是否过期，已过期的key不会重写到aof文件。
​

Redis与数据库的数据一致性

关于redis与数据库的数据一致性，业界使用最多的是数据同步问题（双删策略）

双删策略

先更新数据库，再更新缓存；

同时有请求A和请求B进行更新操作，那么会出现：

1. 线程A更新了数据库；
2. 线程B更新了数据库；
3. 线程B更新了缓存；
4. 线程A更新了缓存；

缺点

这就出现请求A更新缓存应该比请求B更新缓存早才对，但是因为网络等原因，B却比A更早更新了缓存。这就导致了脏数据，因此不考虑！
如果你是一个写数据库场景比较多，而读数据场景比较少的业务需求，采用这种方案就会导致，数据压根还没读到，缓存就被频繁的更新，浪费性能。
如果你写入数据库的值，并不是直接写入缓存的，而是要经过一系列复杂的计算再写入缓存。那么，每次写入数据库后，都再次计算写入缓存的值，无疑是浪费性能的。显然，删除缓存更为适合。

先删除缓存，再更新数据库；

同时有一个请求A进行更新操作，另一个请求B进行查询操作。那么会出现如下情形:
（1）请求A进行写操作，删除缓存；
（2）请求B查询发现缓存不存在；
（3）请求B去数据库查询得到旧值；
（4）请求B将旧值写入缓存；
（5）请求A将新值写入数据库；

导致数据不一致的情形出现，如果不采用给缓存设置过期时间策略，该数据永远都是脏数据。

延时双删策略

解决方案：延时双删策略

（1）先淘汰缓存；
（2）再写数据库（这两步和原来一样）；
（3）休眠1秒，再次淘汰缓存；

这么做，可以将1秒内所造成的缓存脏数据，再次删除！这个一秒如何得出来的呢？评估自己的项目的读数据业务逻辑的耗时，在读数据业务逻辑的耗时基础上，加几百ms即可，确保读请求结束，写请求可以删除读请求造成的缓存脏数据。

MySQL的读写分离架构中

一个请求A进行更新操作，另一个请求B进行查询操作。

（1）请求A进行写操作，删除缓存；
（2）请求A将数据写入数据库了；
（3）请求B查询缓存发现，缓存没有值；
（4）请求B去从库查询，这时，还没有完成主从同步，因此查询到的是旧值；
（5）请求B将旧值写入缓存；
（6）数据库完成主从同步，从库变为新值； 导致数据不一致，解决方案使用双删延时策略。只是，睡眠时间修改为在主从同步的延时时间基础上，加几百ms。

采用这种同步淘汰策略，吞吐量降低怎么办？ ok，那就将第二次删除作为异步的。自己起一个线程，异步删除。这样，写的请求就不用沉睡一段时间后了，再返回。这么做，加大吞吐量。

异步延时删除策略

先更新数据库，再删除缓存； 一个请求A做查询操作，一个请求B做更新操作，那么会有如下情形产生：

（1）缓存刚好失效；
（2）请求A查询数据库，得一个旧值；
（3）请求B将新值写入数据库；
（4）请求B删除缓存；
（5）请求A将查到的旧值写入缓存；

问题：会发生脏数据，但是几率不大，因为步骤（3）的写数据库操作比步骤（2）的读数据库操作耗时更短，才有可能使得步骤（4）先于步骤（5）。可是，大家想想，数据库的读操作的速度远快于写操作的（不然做读写分离干嘛，做读写分离的意义就是因为读操作比较快，耗资源少），因此步骤（3）耗时比步骤（2）更短，这一情形很难出现。

如何解决脏数据呢？给缓存设有效时间是一种方案。其次，采用策略2（先删除缓存，再更新数据库）里给出的异步延时删除策略，保证读请求完成以后，再进行删除操作。

第二次删除，如果删除失败怎么办？ 这是个非常好的问题，因为第二次删除失败，就会出现如下情形。还是有两个请求，一个请求A进行更新操作，另一个请求B进行查询操作，为了方便，假设是单库： （1）请求A进行写操作，删除缓存； （2）请求B查询发现缓存不存在； （3）请求B去数据库查询得到旧值； （4）请求B将旧值写入缓存； （5）请求A将新值写入数据库； （6）请求A试图去删除请求B写入对缓存值，结果失败了；ok,这也就是说。如果第二次删除缓存失败，会再次出现缓存和数据库不一致的问题。

解决方案一

（1）更新数据库数据；
（2）缓存因为种种问题删除失败；
（3）将需要删除的key发送至消息队列；
（4）自己消费消息，获得需要删除的key；
（5）继续重试删除操作，直到成功； 缺点：对业务线代码造成大量的侵入

解决方案二： 启动一个订阅程序去订阅数据库的binlog，获得需要操作的数据。在应用程序中，另起一段程序，获得这个订阅程序传来的信息，进行删除缓存操作。
（1）更新数据库数据；
（2）数据库会将操作信息写入binlog日志当中；
（3）订阅程序提取出所需要的数据以及key；
（4）另起一段非业务代码，获得该信息；
（5）尝试删除缓存操作，发现删除失败；
（6）将这些信息发送至消息队列；
（7）重新从消息队列中获得该数据，重试操作；

订阅binlog程序在mysql中有现成的中间件叫canal，可以完成订阅binlog日志的功能。重试机制，采用的是消息队列的方式。如果对一致性要求不是很高，直接在程序中另起一个线程，每隔一段时间去重试。
​

Redis分布式锁底层实现

如何实现

redis使用setnx作为分布式锁，在多线程环境下面，只有一个线程会拿到这把锁，拿到锁的线程执行业务代码，执行业务代码需要一点时间，所以这段时间拒绝了很多等待获取锁的请求，直到有锁的线程最后释放掉锁，其他线程才能获取锁，这个就是redis的分布式锁的使用。

使用redis锁会有很多异常情况，如何处理这些异常呢

1.redis服务挂掉了，抛出异常了，锁不会被释放掉，新的请求无法进来，出现死锁问题

添加try finally处理

2.服务器果宕机了，导致锁不能被释放的现象

设置超时时间

3.锁的过期时间比业务执行时间短，会存在多个线程拥有同一把锁的现象

如果有一个线程执行需要15s，过期时间只有10s，当执行到10s时第二个线程进来拿到这把锁，会出现多个线程拿到同一把锁执行。

续期超时时间，当一个线程执行5s后对超时时间续期10s，续期设置可以借助redission工具，加锁成功，后台新开一个线程，每隔10秒检查是否还持有锁，如果持有则延长锁的时间，如果加锁失败一直循环（自旋）加锁。

4.锁的过期时间比业务执行时间短，锁永久失效

如果有一个线程执行需要15s，过期时间只有10s，当执行到10s时第二个线程进来拿到这把锁，会出现多个线程拿到同一把锁执行，在第一个线程执行完时会释放掉第二个线程的锁，以此类推，导致锁的永久失效。

给每个线程都设置一个唯一标识，避免出现程序执行的时间超过设置的过期时间，导致其他线程删除了自己的锁，只允许自己删除自己线程的锁

Redis热点数据缓存

热点数据缓存

当前key是一个热点key（例如一个热门的娱乐新闻），并发量非常大重建缓存不能在短时间完成，可能是一个复杂计算，例如复杂的SQL、多次IO、多个依赖等在缓存失效的瞬间，有大量线程来重建缓存，造成后端负载加大，甚至可能会让应用崩溃。

互斥锁（mutex）

解决方案一：互斥锁（mutex）
只允许一个线程重建缓存，其他线程等待重建缓存的线程执行完，重新从缓存获取数据。

    1）从Redis获取数据，如果值不为空，则直接返回值；否则执行下面的2.1）和2.2）步骤    2.1）如果set（nx和ex）结果为true，说明此时没有其他线程重建缓存， 那么当前线程执行缓存构建逻辑    2.2）如果set（nx和ex）结果为false，说明此时已经有其他线程正在执 行构建缓存的工作，那么当前线程将休息指定时间（例如这里是50毫秒，取决于构建缓存的速度）后，重新执行函数，直到获取到数据。

优缺点：如果构建缓存过程出现问题或者时间较长，可能会存在死锁和线程池阻塞的风险，但是这种方法能够较好地降低后端存储负载，并在一致性上做得比较好。

永远不过期

解决方案二：永远不过期

从缓存层面来看，确实没有设置过期时间，所以不会出现热点key过期 后产生的问题，也就是“物理”不过期。从功能层面来看，为每个value设置一个逻辑过期时间，当发现超过逻 辑过期时间后，会使用单独的线程去构建缓存。

优缺点：由于没有设置真正的过期时间，实际上已经不存在热点key产生的一系列危害，但是会存在数据不一致的情况，同时代码复杂度会增大。
问题：怎么知道哪些数据是热点数据？因为本地缓存资源有限，不可能把所有的商品数据进行缓存，它只会缓存热点的数据。那怎么知道数据是热点数据呢？

利用redis4.x自身特性，LFU机制发现热点数据。实现很简单，只要把redis内存淘汰机制设置为allkeys-lfu或者volatile-lfu方式，再执行./redis-cli --hotkeys会返回访问频率高的key，并从高到底的排序,在设置key时，需要把商品id带上，这样就是知道是哪些商品了。

高并发

单机的 Redis，能够承载的 QPS大概就在上万到几万不等。对于缓存来说，一般都是用来支撑读高并发的。因此架构做成主从(master-slave)架构，一主多从，主负责写，并且将数据复制到其它的slave 节点，从节点负责读。所有的读请求全部走从节点。这样也可以很轻松实现水平扩容，支撑读高并发。

高可用

Redis哨兵集群实现高可用，哨兵是一个分布式系统,你可以在一个架构中运行多个哨兵进程,这些进程使用流言协议来接收关于主节点是否下线的信息,并使用投票协议来决定是否执行自动故障迁移,以及选择哪个备节点作为新的主节点。每个哨兵会向其它哨兵、主节点、备节点定时发送消息,以确认对方是否”活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂.若“哨兵群”中的多数哨兵,都报告某一主节点没响应,系统才认为该主节点"彻底死亡",通过算法,从剩下的备节点中,选一台提升为主节点,然后自动修改相关配置。

哨兵机制

哨兵是一个分布式系统，你可以在一个架构中运行多个哨兵进程，这些进程使用流言协议来接收关于主节点是否下线的信息，并使用投票协议来决定是否执行自动故障迁移，以及选择哪个备节点作为新的主节点。每个哨兵会向其它哨兵、主节点、备节点定时发送消息，以确认对方是否”活”着，如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂。

若“哨兵群”中的多数哨兵，都报告某一主节点没响应，系统才认为该主节点"彻底死亡"，通过算法，从剩下的备节点中，选一台提升为主节点，然后自动修改相关配置。可以通过修改sentinel.conf配置文件，配置主节点名称，IP，端口号，选举次数，主服务器的密码，心跳检测毫秒数，做多少个节点等。

Redis 哨兵主备切换的数据丢失问题

异步复制导致的数据丢失

master->slave 的复制是异步的，所以可能有部分数据还没复制到 slave，master 就宕机了，此时这部分数据就丢失了。 脑裂导致的数据丢失：某个 master 所在机器突然脱离了正常的网络，跟其他 slave 机器不能连接，但是实际上 master还运行着。此时哨兵可能就会认为 master 宕机了，然后开启选举，将其他 slave 切换成了 master。这个时候，集群里就会有两个master ，也就是所谓的脑裂。 此时虽然某个 slave 被切换成了 master，但是可能 client 还没来得及切换到新的master，还继续向旧 master 写数据。因此旧 master 再次恢复的时候，会被作为一个 slave 挂到新的 master上去，自己的数据会清空，重新从新的 master 复制数据。而新的 master 并没有后来 client写入的数据，因此，这部分数据也就丢失了

解决方案：

进行配置：min-slaves-to-write 1 min-slaves-max-lag 10

通过配置至少有 1 个 slave，数据复制和同步的延迟不能超过 10 秒，超过了master 就不会再接收任何请求了。

减少异步复制数据的丢失

一旦 slave 复制数据和 ack 延时太长，就认为可能 master 宕机后损失的数据太多了，那么就拒绝写请求，这样可以把 master宕机时由于部分数据未同步到 slave 导致的数据丢失降低的可控范围内。 减少脑裂的数据丢失：如果一个 master 出现了脑裂，跟其他slave 丢了连接，如果不能继续给指定数量的slave 发送数据，而且 slave 超过10 秒没有给自己ack消息，那么就直接拒绝客户端的写请求。因此在脑裂场景下，最多就丢失10 秒的数据。

集群模式

数据量很少的情况下，比如你的缓存一般就几个 G，单机就足够了，可以使用 replication，一个 master 多个 slaves，要几个 slave 跟你要求的读吞吐量有关，然后自己搭建一个 sentinel 集群去保证 Redis 主从架构的高可用性。

海量数据+高并发+高可用的场景的情况下，使用Redis cluster ，自动将数据进行分片，每个 master 上放一部分数据，它支撑 N个 Redis master node，每个 master node 都可以挂载多个 slave node。 这样整个 Redis就可以横向扩容了，如果你要支撑更大数据量的缓存，那就横向扩容更多的 master 节点，每个 master节点就能存放更多的数据了。而且部分 master 不可用时，还是可以继续工作的。

在 Redis cluster 架构下，使用cluster bus 进行节点间通信，用来进行故障检测、配置更新、故障转移授权。cluster bus 用了一种二进制的协议， gossip 协议，用于节点间进行高效的数据交换，占用更少的网络带宽和处理时间。

集群协议

集群元数据的维护：集中式、Gossip 协议

集中式

集中式是将集群元数据（节点信息、故障等等）几种存储在某个节点上。集中式元数据集中存储的一个典型代表，就是大数据领域的 storm。它是分布式的大数据实时计算引擎，是集中式的元数据存储的结构，底层基于zookeeper对所有元数据进行存储维护。集中式的好处在于，元数据的读取和更新，时效性非常好，一旦元数据出现了变更，就立即更新到集中式的存储中，其它节点读取的时候就可以感知到；不好在于，所有的元数据的更新压力全部集中在一个地方，可能会导致元数据的存储有压力。

gossip 协议

gossip 协议，所有节点都持有一份元数据，不同的节点如果出现了元数据的变更，就不断将元数据发送给其它的节点，让其它节点也进行元数据的变更。gossip好处在于，元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续打到所有节点上去更新，降低了压力；不好在于，元数据的更新有延时，可能导致集群中的一些操作会有一些滞后。

在 Redis cluster 架构下，每个节点都有一个专门用于节点间通信的端口，就是自己提供服务的端口号+10000，每个 Redis 要放开两个端口号，比如 7001，那么用于节点间通信的就是 17001 端口，17001端口号是用来进行节点间通信的，也就是 cluster bus 的东西。每个节点每隔一段时间都会往另外几个节点发送 ping 消息，同时其它几个节点接收到 ping 之后返回 pong 。

多级缓存架构

并发竞争

Redis 的并发竞争问题是什么？如何解决这个问题？了解 Redis 事务的 CAS 方案吗？

多客户端同时并发写一个 key，可能本来应该先到的数据后到了，导致数据版本错了；或者是多客户端同时获取一个 key，修改值之后再写回去，只要顺序错了，数据就错了。

CAS 类的乐观锁方案：某个时刻，多个系统实例都去更新某个 key。可以基于 zookeeper 实现分布式锁。每个系统通过 zookeeper 获取分布式锁，确保同一时间，只能有一个系统实例在操作某个 key，别人都不允许读和写。

你要写入缓存的数据，都是从 mysql 里查出来的，都得写入 mysql 中，写入 mysql 中的时候必须保存一个时间戳，从 mysql 查出来的时候，时间戳也查出来。每次要写之前，先判断一下当前这个 value 的时间戳是否比缓存里的 value 的时间戳要新。如果是的话，那么可以写，否则，就不能用旧的数据覆盖新的数据。

Redis cluster 的高可用与主备切换原理

如果一个节点认为另外一个节点宕机，这是属于主观宕机。如果多个节点都认为另外一个节点宕机了，那么就是客观宕机，跟哨兵的原理几乎一样，sdown，odown。流程为：如果一个节点认为某个节点pfail 了，那么会在 gossip ping 消息中， ping 给其他节点，如果超过半数的节点都认为 pfail 了，那么就会变成fail 。 每个从节点，都根据自己对 master 复制数据的 offset，来设置一个选举时间，offset越大（复制数据越多）的从节点，选举时间越靠前，优先进行选举。所有的 master node 开始 slave 选举投票，给要进行选举的slave 进行投票，如果大部分 master node （N/2 + 1） 都投票给了某个从节点，那么选举通过，那个从节点可以切换成master。从节点执行主备切换，从节点切换为主节点。

主从架构下的数据同步

主从复制/数据同步

master会启动一个后台线程，开始生成一份RDB快照文件，同时还会将从客户端收到的所有写命令缓存在内存中。RDB文件生成完毕之后，master会将这个RDB发送给slave，slave会先写入本地磁盘，然后再从本地磁盘加载到内存中。然后master会将内存中缓存的写命令发送给slave，slave也会同步这些数据。

主从架构下的数据部分复制（断点续传）

当redis是主从架构时，主节点同步数据到从节点进行持久化，这个过程可能会因为网络/IO等原因，导致连接中断，当主节点和从节点断开重连后，一般都会对整份数据进行复制，这个过程是比较浪费性能的。从redis2.8版本开始，redis改用可以支持部分数据复制的命令去主节点同步数据，主节点会在内存中创建一个复制数据用的缓存队列，缓存最近一段时间的数据，主节点和它所有的从节点都维护复制的数据下标和主节点的进程id，当网络连接断开后，从节点会请求主节点继续进行数据同步，从记录数据的下标开始同步数据。如果主节点进程id变化了，或者从节点数据下标太旧，不在主节点的缓存队列里，会进行一次全量数据的复制。

数据丢失发生的场景以及解决方案

• 异步复制导致的数据丢失：主节点到从节点的复制是异步的，主节点有部分数据还没复制到从节点，主节点就宕机了。
• 脑裂导致的数据丢失：脑裂导致的数据丢失：某个 主节点 所在机器突然脱离了正常的网络，跟其他从节点机器不能连接，但是实际上 主节点还运行着，这个时候哨兵可能就会认为 主节点 宕机了，然后开启选举，将其他从节点切换成了 主节点，集群里就会有两个主节点 ，也就是所谓的脑裂。虽然某个从节点被切换成了 主节点，但是可能 client 还没来得及切换到新的主节点，还继续向旧的主节点写数据，当旧的主节点再次恢复的时候，会被作为一个从节点挂到新的 主节点上去，自己的数据会清空，从新的主节点复制数据，新的主节点并没有后来 client写入的数据，这部分数据也就丢失了。

解决方案：

• 针对异步复制导致的数据丢失，可以通过控制复制数据的时长和ack的时间来控制，一旦从节点复制数据和 ack 延时太长，就认为可能主节点宕机后损失的数据太多了，那么就拒绝写请求，这样可以把主节点宕机时由于部分数据未同步到从节点导致的数据丢失降低的可控范围内。
• 针对脑裂导致的数据丢失：如果一个主节点出现了脑裂，跟其他从节点断了连接，如果不能继续给从节点发送数据，而且从节点超过10 秒没有给自己ack消息，那么就直接拒绝客户端的写请求，这样即便在脑裂场景下，最多就丢失10 秒的数据。在redis的配置文件里面有二个参数，min-slaves-to-write 3表示连接到master的最少slave数量，min-slaves-max-lag 10表示slave连接到master的最大延迟时间，通过这二个参数可以把数据丢失控制在承受范围以内。

主从/哨兵/集群区别

主从架构

主数据库可以进行读写操作，当写操作导致数据变化的时候，会自动将数据同步给从数据库，从数据库一般是只读的，接受主数据库同步过来的数据。

哨兵

当主数据库遇到异常中断服务后，需要通过手动的方式选择一个从数据库来升格为主数据库，让系统能够继续提供服务，难以实现自动化。 Redis 2.8中提供了哨兵工具来实现自动化的系统监控和故障恢复功能，哨兵的作用就是监控redis主、从数据库是否正常运行，主数据库出现故障，自动将从数据库转换为主数据库。

集群

即使使用哨兵，redis每个实例也是全量存储，每个redis存储的内容都是完整的数据，浪费内存，有木桶效应。为了最大化利用内存，可以采用集群，就是分布式存储，每台redis存储不同的内容，Redis集群共有16384个槽，每个redis分得一些槽，客户端请求的key，根据公式，计算出映射到哪个分片上。

高可用/哨兵集群/主备切换

Redis哨兵集群实现高可用，哨兵是一个分布式系统，可以在一个架构中运行多个哨兵进程，这些进程使用流言协议来接收关于主节点是否下线的信息，并使用投票协议来决定是否进行自动故障迁移，选择哪个备节点作为新的主节点。每个哨兵会向其它哨兵、主节点、备节点定时发送消息，以确认对方是否”活”着，如果发现对方在指定时间内未回应，则暂时认为对方已挂。若“哨兵群”中的多数哨兵，都报告某一主节点没响应，系统才认为该主节点"彻底死亡"，通过算法，从剩下的备节点中，选一台提升为主节点，然后自动修改相关配置，比如主节点名称，IP，端口号，选举次数，主服务器的密码，心跳检测毫秒数，做多少个节点等。