【建议收藏】Redis知识干货汇总

为了让大家更好的学习redis相关的知识，我这里总结一下核心的面试知识点，大家来一起学习。

问：redis是单线程吗？是否有线程安全问题？

redis是使用单线程模型来处理客户端的请求，只是使用多线程来处理数据的读写和协议解析，执行命令还是使用单线程，不会有线程安全的问题。 redis 在 4.0 的时候引入了多线程来做大缓存的清除处理工作，主要是体现在大数据的异步删除功能上，例如 unlink key、flushdb async、flushall async 等，先清除 key ，接着异步清除对应的 value。 在 redis 6.0 之前的网络模型都是标准的单线程 reactor 模型。在 6.0 开始引入了一个非标准的多线程 reactor 模型，sub-reactor 此时会使用 socket 读取 client 请求，并处理命令的解析，然后具体写还是在主线程上执行。

问：redis集群架构（4种）

单机模式 优点：1、部署简单。2、数据一致性高 缺点：1、内存容量有限 2、处理能力有限 3、无法高可用。 主从模式 优点：1、可靠性得到一定保障，当节点出问题，可由其他节点来提供。2、提升了读能力，分散主节点的读压力 缺点：1、主节点的写能力和存储能力受单机限制。2、主节点宕机，切换从节点需要业务方手动切换，进行人工干预。 哨兵模式 优点：1、基于主从模式，主从可以自动切换。 缺点：1、节点的承载能力有限，写能力和存储能力都有限。 redis cluser模式 优点：高可用、可扩展性、分布式、支持容错，去中心化的集群方案。

问：redis常用的数据结构和应用场景

常用数据结构：

string，hash，list，set，sorted set，geospatial，hyperloglog，bitmaps

string(字符串)

简介： string类型是redis 中最基本、最常用的数据类型。string类型是二进制安全的，意思是 redis 的string可以包含任何数据。string 类型的值最大能存储 512MB。

string字符串的内存分配机制： 当字符串的长度小于1MB时，每次扩容都是加倍现有的空间。 如果字符串长度超过1MB时，每次扩容时只会扩展 1MB 的空间。

使用命令： get、set、incr、decr、mget、del、expire 、incrby

应用场景： 单值缓存 对象缓存 分布式锁 共享Session 累加器 限速

redis字符串数据结构，capacity 和 len两个属性都是泛型，为更合理的使用内存，不同长度的字符串采用不同的数据类型表示，且在创建字符串的时候 len 会和 capacity 一样大，不产生冗余的空间。

struct SDS{
 T capacity;       //数组容量
 T len;            //实际长度
 byte flages;  //标志位,低三位表示类型
 byte[] content;   //数组内容
}

list(列表)

简介： list链表（redis使用双端链表实现的list），是有序的，value可以重复，可以通过下标取出对应的value值，左右两边都能进行插入和删除数据。

list底层实现机制： redis3.2之前，当数据量较少的时候它的底层存储结构为一块连续内存，称之为ziplist(压缩列表)，它将所有的元素紧挨着一起存储，分配的是一块连续的内存；当数据量较多的时候将会变成quicklist(快速链表)结构。 redis3.2之后，采用的一种叫quicklist的数据结构来存储list，列表的底层都quicklist实现。

常用命令： lpush、rpush、lrange、pop、bpop

应用场景： 消息队列 栈 文章列表

hash(哈希表)

简介： 哈希类型是指一个键值对的存储结构。

hash底层实现： ziplist（压缩列表）：当哈希类型元素个数小于hash-max-ziplist-entries配置（默认512个）同时所有值都小于hash-max-ziplist-value配置（默认64字节）时使用。ziplist使用更加紧凑的结构实现多个元素的连续存储，所以比hashtable更加节省内存。hashtable（哈希表）：当ziplist不能满足要求时，会使用hashtable。

常用命令： hget、hset、hgetall、hincr、hincrby

应用场景： 多条件缓存 购物车功能 存储对象

set(集合)

简介： Set就是一个集合，集合的概念就是一堆不重复值的组合。利用redis提供的Set数据结构，可以存储一些集合性的数据。一个集合最多可以存储2^32-1个元素。

常用命令： sadd、smembers、sismemeber、scard、spop、srem

应用场景： 好友、关注、粉丝、感兴趣的人集合 去重

sort set(有序集合)

简介： 有序集合和集合一样，不能有重复元素。但是可以排序，它给每个元素设置一个score作为排序的依据。最多可以存储2^32-1个元素。

常用命令： zadd、zrange、zrevrange、zcard、zrank、zrangebyscore、zrem、zscore

应用场景： 成绩排行榜，游戏排行榜， 用Sorted Sets来做带权重的队列 限流

geospatial

简介： redis 在 3.2 推出 Geo 类型，该功能可以推算出地理位置信息，两地之间的距离。

hyperloglog

简介： 基数：数学上集合的元素个数，是不能重复的。这个数据结构常用于统计网站的 UV。

bitmap

简介： bitmap 就是通过最小的单位 bit 来进行0或者1的设置，表示某个元素对应的值或者状态。一个 bit 的值，或者是0，或者是1；也就是说一个 bit 能存储的最多信息是2。bitmap 常用于统计用户信息比如活跃粉丝和不活跃粉丝、登录和未登录、是否打卡等。

问：聊聊redis分布式锁的使用和注意问题

分布式锁：控制分布式系统不同进程共同访问共享资源的一种锁的实现。 redis实现分布式锁可以通过setnx，setnx+expire，set EX PX NX来实现。 如果用setnx来实现分布式锁需要del配合一起使用，setnx设置成功会返回1，如果系统用完了就需要把整个锁删除，由于某个原因没有删除锁，其他的系统就不能获取到此分布式锁，这样会容易造成死锁，锁永远得不到释放。 如果用setnx+expire，当我们设置锁并且expire设置了过期时间，如果在setnx的时候，expire缺失败了，这样也会出现死锁问题，锁得不到释放。 当使用set EX NX 结合使用保证setnx+expire会是一个事务去执行，这样肯定不会死锁，但带来了可能的超时问题，如果分布式系统任务在有效期内没有完成，这样会造成其它分布式系统或线程乘虚而入，为了避免这个问题，redis分布式锁不要用于较长时间的任务。 为了解决分布式锁的超时问题，我们通过语言层面来解决，实现一个线程或者系统如果获取了锁之后,可以再次对其请求加锁，也就是实现分布式锁的可重入性特征。

问：聊聊redis的sorted set的底层实现

redis使用跳跃表作为有序集合键的底层实现。

结构体如下：

typedef struct zskiplistNode {
   robj *obj;  /*成员对象*/
   double score;   /*分值*/
   struct zskiplistNode *backward; /*后退指针*/
   struct zskiplistLevel { /*层*/
       struct zskiplistNode *forward;  /*前进指针*/
       unsigned int span;  /*跨度*/
   } level[];
} zskiplistNode;

1、层 level 跳跃表节点的level数组可以包含多个元素，每个元素都包含一个指向其他节点的指针，程序可以通过这些层来加快访问其他节点的速度，一般来说，层的数量越多，访问其他节点的速度就越快。

每次创建一个新跳跃表节点的时候，程序根据幂次定律(power law，越大的数出现的概率越小)随机生成一个介于1和32之间的值作为level数组的大小，这个大小就是层的“高度”。

2、前进指针 forward，每个层都有一个指向表尾方向的前进指针(level[i].forward属性)，用于从表头向表尾方向访问节点。3、跨度 level，层的跨度(level[i].span属性)用于记录两个节点之间的距离：两个节点之间的跨度越大，它们相距得就越远。指向NULL的所有前进指针的跨度都为0，因为它们没有连向任何节点。

4、后退指针 backward,节点的后退指针(backward属性)用于从表尾向表头方向访问节点：跟可以一次跳过多个节点的前进指针不同，因为每个节点只有一个后退指针，所以每次只能后退至前一个节点。

5、分值和成员：节点的分值(score属性)是一个double类型的浮点数，跳跃表中的所有节点都按分值从小到大来排序。节点的成员对象(obj属性)是一个指针，它指向一个字符串对象，而字符串对象则保存着一个SDS值。

在同一个跳跃表中，各个节点保存的成员对象必须是唯一的，但是多个节点保存的分值却可以是相同的：分至相同的节点将按照成员对象在字典中的大小来进行排序，成员对象较小的节点会排在前面(靠近表头的方向)，而成员对象较大的节点则会排在后面(靠近表尾的方向)。

跳跃表：zskiplist结构的定义

typedef struct zskiplist {
   struct zskiplistNode *header, *tail;    //header指向跳跃表的表头节点，tail指向跳跃表的表尾节点
   unsigned long length;   //记录跳跃表的长度，也即是，跳跃表目前包含节点的数量(表头节点不计算在内)
   int level;  //记录目前跳跃表内，层数最大的那个节点的层数(表头节点的层数不计算在内)
} zskiplist;

跳跃表通过多个跳跃表节点就可以组成。header和tail指针分别指向跳跃表的表头和表尾节点，通过这两个指针，程序定位表头节点和表尾节点的复杂度为0(1)。通过使用length属性来记录节点的数量，程序可以在0(1)复杂度内返回跳跃表的长度。

通过使用length属性来记录节点的数量，程序可以在0(1)复杂度内返回跳跃表的长度。

level属性则用于在0(1)复杂度内获取跳跃表中层高最大的那个节点的层数量

跳跃表是有序集合的底层实现之一。

redis的跳跃表实现由zskiplist和zskiplistNode两个结构组成，其中zskiplist 用于保存跳跃表信息（比如表头节点、表尾节点、长度），而zskiplistNode则用于表 示用跃表节点。

问：聊聊redis中的多路复用模型

I/O 模型

1. BIO（同步阻塞）
2. NIO（同步非阻塞（多路复用））
3. AIO（异步非阻塞）

NIO（同步非阻塞（多路复用）） 常见的事件轮询 API 有 select、poll、epoll，它们是操作系统提供给用户线程的 API，用于取代用户线程轮询。如果是用户线程轮询就要涉及用户态和内核态的频繁切换，这部分开销是巨大的。 select select() 的机制中提供一种 fd_set 的数据结构，实际上是一个 long 类型的数组，每一个数组元素都能与一打开的文件句柄（不管是 Socket 句柄,还是其他文件或命名管道或设备句柄）建立联系，当调用 select() 时，由内核根据 IO 状态修改 fd_set 的内容，由此来通知执行了 select() 的进程哪一 socket 或文件可读写。 使用 select() 最大的优势是可以在一个线程内同时处理多个 socket 的 IO 请求。用户可以注册多个 socket，然后不断地调用 select() 读取被激活的 socket，即可达到在同一个线程内同时处理多个 IO 请求的目的。但 select 存在三个问题：一是为了减少数据拷贝带来的性能损坏，内核对被监控的 fd_set 集合大小做了限制，并且这个是通过宏控制的，大小不可改变(限制为 1024)；二是每次调用 select()，都需要把 fd_set 集合从用户态拷贝到内核态，如果 fd_set 集合很大时，那这个开销很大；三是每次调用 select() 都需要在内核遍历传递进来的所有 fd_set，如果 fd_set 集合很大时，那这个开销也很大。 poll poll 的机制与 select 类似，与 select 在本质上没有多大差别，管理多个描述符也是进行轮询，根据描述符的状态进行处理，只是 poll 没有最大文件描述符数量的限制。 select epoll 在 Linux 2.6 内核正式提出，是基于事件驱动的 I/O 方式，相对于 select 来说，epoll 没有描述符个数限制，使用一个文件描述符管理多个描述符，将用户关心的文件描述符的事件存放到内核的一个事件表中，这样在用户空间和内核空间的 copy 只需一次。 为什么redis采用单线程IO多路复用 IO多路复用为单线程处理多线程任务提供了思路，但并不是所有程序的可以保持高效的。redis把数据存放在内存中，而且操作逻辑简单，CPU运算速度比内存IO更是快了几个数量级，这让redis的瓶颈不会出现在CPU，在到达CPU瓶颈之前网络带宽将先成为瓶颈，因此提高 CPU利用率并不能有效提升redis效率。单线程的设计避免了线程的上下文切换，而且单线程设计的安全性也避免了锁，这些因素决定了 redis 采用单线程 IO 多路复用。

问：讲讲redis数据持久化方式

redis作为一个键值对内存数据库(NoSQL)，数据都存储在内存当中,为了避免内存中数据丢失，redis提供了对持久化的支持，我们可以选择不同的方式将数据从内存中保存到硬盘当中，使数据可以持久化保存。redis提供了RDB和AOF两种不同的数据持久化方式。redis不允许save和bgsave命令同时执行。当RDB与AOF两种方式都开启时，redis会优先使用AOF日志来恢复数据，因为AOF保存的文件比RDB文件更完整。

RDB

RDB是一种快照存储持久化方式，具体就是将redis某一时刻的内存数据保存到硬盘的文件当中，默认保存的文件名为dump.rdb，而在redis服务器启动时，会重新加载dump.rdb文件的数据到内存当中恢复数据。

开启RDB持久化方式

开启RDB持久化方式很简单，客户端可以通过向redis服务器发送save或bgsave命令让服务器生成rdb文件，或者通过服务器配置文件指定触发RDB条件。

save

save命令是一个同步操作。当客户端向服务器发送save命令请求进行持久化时，服务器会阻塞save命令之后的其他客户端的请求，直到数据同步完成。如果数据量太大，同步数据会执行很久，而这期间redis服务器也无法接收其他请求，所以，最好不要在生产环境使用save命令。

bgsave

bgsave命令是一个异步操作。当客户端发服务发出bgsave命令时，redis服务器主进程会forks一个子进程来数据同步问题，在将数据保存到rdb文件之后，子进程会退出。所以，与save命令相比，redis服务器在处理bgsave采用子线程进行IO写入，而主进程仍然可以接收其他请求，但forks子进程是同步的，所以forks子进程时，一样不能接收其他请求。这意味着，如果forks一个子进程花费的时间太久(一般是很快的)，bgsave命令仍然有阻塞其他客户的请求的情况发生。

AOF(Append-only file)

与RDB存储某个时刻的快照不同，AOF持久化方式会记录客户端对服务器的每一次写操作命令，并将这些写操作以redis协议追加保存到以后缀为aof文件末尾，在redis服务器重启时，会加载并运行aof文件的命令，以达到恢复数据的目的。

开启AOF持久化方式

AOF的持久化流程：命令写入->append->AOF缓冲器->sync->AOF文件 AOF文件会rewrite AOF文件，redis重启的时候会load AOF文件。

# 开启aof机制
appendonly yes

# aof文件名
appendfilename "appendonly.aof"

# 写入策略,always表示每个写操作都保存到aof文件中,也可以是everysec或no
appendfsync always

# 默认不重写aof文件
no-appendfsync-on-rewrite no

# 保存目录
dir ~/redis/

aof三种写入策略

1. always 客户端的每一个写操作都保存到aof文件当，这种策略很安全，但是每个写请注都有IO操作，所以也很慢。
2. everysec appendfsync的默认写入策略，每秒写入一次aof文件，因此，最多可能会丢失1s的数据。
3. no redis服务器不负责写入aof，而是交由操作系统来处理什么时候写入aof文件。更快，但也是最不安全的选择，不推荐使用。

AOF的优点

AOF只是追加日志文件，因此对服务器性能影响较小，速度比RDB要快，消耗的内存较少。

AOF的缺点

AOF方式生成的日志文件太大，即使通过AFO重写，文件体积仍然很大。恢复数据的速度比RDB慢。

问：讲讲redis cluster的集群方案，节点如何通信？

redis集群方案基于分而治之的思想。redis中数据都是以Key-Value形式存储的，而不同Key的数据之间是相互独立的。因此可以将Key按照某种规则划分成多个分区，将不同分区的数据存放在不同的节点上。这个方案类似数据结构中哈希表的结构。在redis集群的实现中，使用哈希算法（公式是CRC16(Key) mod 16383）将Key映射到0~16383范围的整数。这样每个整数对应存储了若干个Key-Value数据，这样一个整数对应的抽象存储称为一个槽（slot）。每个redis cluster的节点——准确讲是master节点——负责一定范围的槽，所有节点组成的集群覆盖了0~16383整个范围的槽。 redis cluster节点通信 不同节点存储的数据相互独立，这些节点仍然需要相互通信以同步节点状态信息。redis集群采用P2P的Gossip协议，节点之间不断地通信交换信息，最终所有节点的状态都会达成一致。 redis Cluster 的每个缓存节点都会开通一个独立的 TCP 通道，用于和其他节点通讯。 节点间进行消息通信时会选择不同的消息类型、不同的发送频率和时机等。消息类型主要有以下5种：

1. meet消息：在节点互相握手阶段，当节点收到客户端的cluster meet命令时，会向新加入的节点发送meet消息，请求该节点加入当前集群。新节点在收到meet消息后会回复一个pong消息。
2. ping消息：集群里每个节点会在每秒钟选择向一部分节点发送ping消息，接收到此消息的节点会回复一个pong消息。ping消息内容包含本节点和其他节点的状态信息，以此达到状态同步。需要注意的是，选择发送ping的节点按照规则会随机找5个节点，在其中选择最久没有通信的一个节点，即在扫描节点列表的时候会选择最近一次收到pong消息的时间大于cluster_node_timeout/2的所有节点，这样做是为了防止这些节点长时间没有更新。
3. pong消息：pong消息包含自身的状态数据，在接收到ping或meet消息时会回复pong消息，也会主动向集群广播pong消息，如果遇到故障而在故障恢复后新的主节点会广播pong消息。这样其他节点可以获知该节点的最新信息。
4. fail消息：当一个主节点判断另一个主节点进入fail（失败）状态时，会向集群广播这一fail消息。接收到这一消息的节点会将该消息保存起来。
5. publish消息：节点收到publish命令后会先执行该命令，然后向集群广播这一条消息，接收到这一消息的节点也会执行该publish命令。

问：redis过期删除策略和内存淘汰机制

redis过期删除策略 当内存没占满时，在redis中过期的键是通过定时删除，惰性删除和定期删除来进行优化的。 定时删除 创建一个定时器，当key设置有过期时间，且过期时间到达时，由定时器任务立即执行对键的删除操作 优点：节约内存，到时就删除，快速释放掉不必要的内存占用 缺点：CPU压力很大，无论CPU此时负载量多高，均占用CPU，会影响redis服务器响应时间和指令吞吐量 用处理器性能换取存储空间（拿时间换空间） 惰性删除 数据到达过期时间，不做处理。等下次访问该数据时，我们需要判断如果未过期，返回数据发现已过期，删除，返回不存在 优点：节约CPU性能，发现必须删除的时候才 删除缺点：内存压力很大，出现长期占用内存的数据 总结：用存储空间换取处理器性能（拿时间换空间） 定期删除 定期删除，redis服务器启动初始化时，读取配置server.hz的值，默认为10。每秒执行server.hz次serverCorn()->databaseCorn()->activeExpireCycle()。其中activeExpireCycle()对每个Expires[*]逐一检测，每次执行时间为250ms/server.hz 对某个Expires[*]检测时，随机挑选几个key检测规则如下：

1. 如果key超时，删除key
2. 如果一轮中删除key的数量>W*25%，循环该过程(重点抽查)
3. 如果一轮中删除key的数量
4. 其中W取值=ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP的属性值

redis的del和unlink redis服务自身对key的删除，可以分为同步删除和异步删除。使用DEL命令会触发同步删除。如果使用unlink命令，redis服务会先计算删除key的成本，从而更智能地做出同步删除或异步删除的选择。注意，只有4.0版本后，才有unlink命令。 redis的del操作需要注意问题 如果Key是一个有很多元素的复杂类型，这个过程可能会堵塞一下redis服务自身，从而影响用户的访问。 内存淘汰机制 当内存使用量超过了maxmemory配置的限制时，redis可以使用以下策略来淘汰数据： 放弃数据淘汰 no-enviction：禁止数据淘汰，会引发OOM(Out Of Memroy)。redis4.0默认策略 检测全库数据(所有数据集server.db[i].dict)

1. allkeys-lru：挑选最近最少使用的数据淘汰
2. allkeys-lfu：挑选最近使用次数最少的数据淘汰
3. allkeys-random：任意选择数据淘汰

检测易失数据(会过期的数据集server.db[i].expries)

1. volatile-lru：挑选最近最少使用的数据淘汰
2. volatile-lfu：挑选最近使用次数最少的数据淘汰
3. volatile-random：任意选择数据淘汰
4. volatile-ttl：挑选即将过期的数据淘汰

问：有遇到redis大key的问题吗？

一般redis的大key也就是value bytes > 10kb 则，这类的key算大key。 过大的 Value 会引发数据倾斜、热点Key、实例流量或 CPU 性能被占满等问题，应从设计源头上避免此类问题带来的性能影响。 如何分析大key –-bigkeys 、memory 命令 和 Rdbtools 工具 分析统计实例存在的 大 key 如何优雅的删除大 key 大 key 问题，主动删除无条件使用 unlink 异步，被动删除时配置 lazyfree 惰性删除。 总结： 根本上解决大 key 问题要从开始时就避免使用大 key。

问：缓存穿透、缓存击穿、缓存雪崩解决方案？

缓存穿透 描述：访问一个缓存和数据库都不存在的key，此时会直接打到数据库上，并且查不到数据，没法写缓存，所以下一次同样会打到数据库上。此时，缓存起不到作用，请求每次都会走到数据库，流量大时数据库可能会被打挂。此时缓存就好像被“穿透”了一样，起不到任何作用。 解决方案 1、接口校验。在正常业务流程中可能会存在少量访问不存在 key 的情况，但是一般不会出现大量的情况，所以这种场景最大的可能性是遭受了非法攻击。可以在最外层先做一层校验：用户鉴权、数据合法性校验等，例如商品查询中，商品的ID是正整数，则可以直接对非正整数直接过滤等等。 2、缓存空值。当访问缓存和DB都没有查询到值时，可以将空值写进缓存，但是设置较短的过期时间，该时间需要根据产品业务特性来设置。 3、布隆过滤器。使用布隆过滤器存储所有可能访问的 key，不存在的 key 直接被过滤，存在的 key 则再进一步查询缓存和数据库。 缓存击穿 描述：某一个热点 key，在缓存过期的一瞬间，同时有大量的请求打进来，由于此时缓存过期了，所以请求最终都会走到数据库，造成瞬时数据库请求量大、压力骤增，甚至可能打垮数据库。 解决方案： 1、加互斥锁。在并发的多个请求中，只有第一个请求线程能拿到锁并执行数据库查询操作，其他的线程拿不到锁就阻塞等着，等到第一个线程将数据写入缓存后，直接走缓存。 2、热点数据不过期。直接将缓存设置为不过期，然后由定时任务去异步加载数据，更新缓存。 缓存雪崩 描述：大量的热点 key 设置了相同的过期时间，导在缓存在同一时刻全部失效，造成瞬时数据库请求量大、压力骤增，引起雪崩，甚至导致数据库被打挂。缓存雪崩其实有点像“升级版的缓存击穿”，缓存击穿是一个热点 key，缓存雪崩是一组热点 key。 解决方案： 1、过期时间打散。既然是大量缓存集中失效，那最容易想到就是让他们不集中生效。可以给缓存的过期时间时加上一个随机值时间，使得每个 key 的过期时间分布开来，不会集中在同一时刻失效。 2、热点数据不过期。该方式和缓存击穿一样，也是要着重考虑刷新的时间间隔和数据异常如何处理的情况。 3、加互斥锁。该方式和缓存击穿一样，按 key 维度加锁，对于同一个 key，只允许一个线程去计算，其他线程原地阻塞等待第一个线程的计算结果，然后直接走缓存即可。

问：如何使用redis做消息队列？

list结构作为队列，rpush生产消息，lpop消费消息，需要自己实现阻塞。blpop没有消息会阻塞，等到消息到来。