面试必问的 Redis：数据结构和基础概念

微信搜索【程序员囧辉】，关注这个坚持分享技术干货的程序员。

​前言

在 Java 后端的面试中，redis 应该是目前所有框架/中间件中被问到频率最高的，至少也是之一。

就算把范围扩大到整个 Java 后端面试知识体系，面试中出现频率比 redis 高的也不多，可能就那么几个：HashMap、线程池之类的。 

由于比较重要，知识点也比较多，所以这边预计分为多篇来呈现。

除了本文之外，主要还有两个方向，一个围绕高可用，主要是持久化、主从复制、哨兵、集群模式等。

另一个围绕 redis 的实践，主要是分布式锁、缓存穿透、缓存雪崩、缓存击穿等。

正文

redis 是单线程还是多线程

这个问题应该已经看到过无数次了，最近 redis 6 出来之后又被翻出来了。

redis 4.0 之前，redis 是完全单线程的。

redis 4.0 时，redis 引入了多线程，但是额外的线程只是用于后台处理，例如：删除对象，核心流程还是完全单线程的。这也是为什么有些人说 4.0 是单线程的，因为他们指的是核心流程是单线程的。

这边的核心流程指的是 redis 正常处理客户端请求的流程，通常包括：接收命令、解析命令、执行命令、返回结果等。

而在最近，redis 6.0 版本又一次引入了多线程概念，与 4.0 不同的是，这次的多线程会涉及到上述的核心流程。

redis 6.0 中，多线程主要用于网络 I/O 阶段，也就是接收命令和写回结果阶段，而在执行命令阶段，还是由单线程串行执行。由于执行时还是串行，因此无需考虑并发安全问题。

值得注意的时，redis 中的多线程组不会同时存在“读”和“写”，这个多线程组只会同时“读”或者同时“写”。

redis 6.0 加入多线程 I/O 之后，处理命令的核心流程如下:

1、当有读事件到来时，主线程将该客户端连接放到全局等待读队列

2、读取数据：1）主线程将等待读队列的客户端连接通过轮询调度算法分配给 I/O 线程处理；2）同时主线程也会自己负责处理一个客户端连接的读事件；3）当主线程处理完该连接的读事件后，会自旋等待所有 I/O 线程处理完毕

3、命令执行：主线程按照事件被加入全局等待读队列的顺序（这边保证了执行顺序是正确的），串行执行客户端命令，然后将客户端连接放到全局等待写队列

4、写回结果：跟等待读队列处理类似，主线程将等待写队列的客户端连接使用轮询调度算法分配给 I/O 线程处理，同时自己也会处理一个，当主线程处理完毕后，会自旋等待所有 I/O 线程处理完毕，最后清空队列。

大致流程图如下：

相关源码在 networking.c，核心的方法是：

IOThreadMain、handleClientsWithPendingReadsUsingThreads、

handleClientsWithPendingWritesUsingThreads

为什么 redis 是单线程

在 redis 6.0 之前，redis 的核心操作是单线程的。

因为 redis 是完全基于内存操作的，通常情况下CPU不会是redis的瓶颈，redis 的瓶颈最有可能是机器内存的大小或者网络带宽。

既然CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了，因为如果使用多线程的话会更复杂，同时需要引入上下文切换、加锁等等，会带来额外的性能消耗。

而随着近些年互联网的不断发展，大家对于缓存的性能要求也越来越高了，因此 redis 也开始在逐渐往多线程方向发展。

最近的 6.0 版本就对核心流程引入了多线程，主要用于解决 redis 在网络 I/O 上的性能瓶颈。而对于核心的命令执行阶段，目前还是单线程的。

redis 为什么使用单进程、单线程也很快

1、基于内存的操作

2、使用了 I/O 多路复用模型，select、epoll 等，基于 reactor 模式开发了自己的网络事件处理器

3、单线程可以避免不必要的上下文切换和竞争条件，减少了这方面的性能消耗。

4、以上这三点是 redis 性能高的主要原因，其他的还有一些小优