一、为什么Redis是单线程的

1️⃣官方答案
因为 Redis 是基于内存的操作，CPU 不是 Redis 的瓶颈，Redis 的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且 CPU 不会成为瓶颈，那就顺理成章地采用单线程的方案了。

2️⃣性能指标
关于 Redis 的性能，官方网站也有，普通笔记本轻松处理每秒几十万的请求。

3️⃣详细原因
①不需要各种锁的性能消耗
Redis 的数据结构并不全是简单的 Key-Value，还有 list，hash 等复杂的结构。这些结构有可能会进行很细粒度的操作，比如在很长的列表后面添加一个元素，在 hash 当中添加或者删除一个对象。这些操作可能就需要加非常多的锁，导致的结果是同步开销大大增加。
总之，在单线程的情况下，代码更清晰，处理逻辑更简单，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗，不存在多进程或者多线程导致的切换而消耗 CPU。
②单线程多进程集群方案
单线程的威力实际上非常强大，每核心效率也非常高。多线程自然是可以比单线程有更高的性能上限，但是在今天的计算环境中，即使是单机多线程的上限也往往不能满足需要了，需要进一步摸索的是多服务器集群化的方案，这些方案中多线程的技术照样是用不上的。所以单线程、多进程的集群不失为一个时髦的解决方案。
③CPU 消耗
采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU。但是如果 CPU 成为 Redis 瓶颈，或者不想让服务器其他 CPU 核闲置，那怎么办？
可以考虑多起几个 Redis 进程，Redis 是 key-value 数据库，不是关系数据库，数据之间没有约束。只要客户端分清哪些 key 放在哪个 Redis 进程上就可以了。

二、Redis的单线程理解

Redis 客户端对服务端的每次调用都经历了发送命令，执行命令，返回结果三个过程。其中执行命令阶段，由于 Redis 是单线程来处理命令的，所有到达服务端的命令都不会立刻执行，所有的命令都会进入一个队列中，然后逐个执行，并且多个客户端发送的命令的执行顺序是不确定的，但是可以确定的是不会有两条命令被同时执行，不会产生并发问题，这就是 Redis 的单线程基本模型。

Redis 服务器通过 socket (套接字)与客户端或其他 Redis 服务器进行连接，而文件事件就是服务器对 socket 操作的抽象。服务器与客户端或其他服务器的通信会产生相应的文件事件，而服务器通过监听并处理这些事件来完成一系列网络通信操作。

Redis 基于 Reactor 模式开发了自己的网络事件处理器——文件事件处理器，文件事件处理器使用 I/O 多路复用程序来同时监听多个 socket，并根据 socket 目前执行的任务来为 socket 关联不同的事件处理器。当被监听的 socket 准备好执行连接应答、读取、写入、关闭等操作时，与操作相对应的文件事件就会产生，这时文件事件处理器就会调用 socket 之前已关联好的事件处理器来处理这些事件。

文件事件处理器的构成：

注意：其中 I/O 多路复用程序通过队列向文件事件分派器传送 socket。

三、I/O多路复用技术

Redis 采用网络 I/O 多路复用技术，来保证在多连接的时候系统的高吞吐量。关于 I/O 多路复用(又被称为“事件驱动”)，首先要理解的是，操作系统为你提供了一个功能，当你的某个 socket 可读或者可写的时候，它可以给你一个通知。这样当配合非阻塞的 socket 使用时，只有当系统通知我哪个描述符可读了，我才去执行 read 操作，可以保证每次 read 都能读到有效数据而不做纯返回-1和 EAGAIN 的无用功，写操作类似。

操作系统的这个功能是通过 select/poll/epoll/kqueue 之类的系统调用函数来实现，这些函数都可以同时监视多个描述符的读写就绪状况，这样，多个描述符的 I/O 操作都能在一个线程内并发交替地顺序完成，这就叫 I/O 多路复用。多路---指的是多个 socket 连接，复用---指的是复用同一个 Redis 处理线程。多路复用主要有三种技术：select，poll，epoll。epoll 是最新的也是目前最好的多路复用技术。

采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求(尽量减少网络 I/O 的时间消耗)，且 Redis 在内存中操作数据的速度非常快，也就是说内存内的操作不会成为影响 Redis 性能的瓶颈，基于这两点 Redis 具有很高的吞吐量。

I/O多路复用机制

打个比方：小王在S城开了一家快递店，负责同城快送服务。小王因为资金限制，雇佣了一批快递员，然后小王发现资金不够了，只够买一辆车送快递。

【经营方式一】
客户每送来一份快递，小王就让一个快递员盯着，然后快递员开车去送快递。慢慢的小王就发现了这种经营方式存在下述问题：

• 几十个快递员基本上时间都花在了抢车上了，大部分快递员都处在闲置状态，谁抢到了车，谁就能去送快递。
• 随着快递的增多，快递员也越来越多，小王发现快递店里越来越挤，没办法雇佣新的快递员了。
• 快递员之间的协调很花时间。

【经营方式二】
小王只雇佣一个快递员。然后呢，客户送来的快递，小王按送达地点标注好，然后依次放在一个地方。最后，那个快递员依次的去取快递，一次拿一个，然后开着车去送快递，送好了就回来拿下一个快递。

【对比】
上述两种经营方式对比，是不是明显觉得第二种，效率更高，更好呢。在上述比喻中：

• 每个快递员------------------>每个线程
• 每个快递-------------------->每个socket(I/O流)
• 快递的送达地点-------------->socket的不同状态
• 客户送快递请求-------------->来自客户端的请求
• 小王的经营方式-------------->服务端运行的代码
• 一辆车---------------------->CPU的核数

于是有如下结论：
1、经营方式一就是传统的并发模型，每个I/O流(快递)都有一个新的线程(快递员)管理。
2、经营方式二就是I/O多路复用。只有单个线程(一个快递员)，通过跟踪每个I/O流的状态(每个快递的送达地点)，来管理多个I/O流。

类比到真实的redis线程模型，如图：

如图，简单来说，就是redis-client在操作的时候，会产生具有不同事件类型的socket。在服务端，有一段I/O多路复用程序，将其置入队列之中。然后，文件事件分派器，依次去队列中取，转发到不同的事件处理器中。需要说明的是，这个I/O多路复用机制，redis还提供了select、epoll、evport、kqueue等多路复用函数库。

四、单线程的Redis为何高并发快

Redis 利用队列技术将并发访问变为串行访问，消除了传统数据库串行控制的开销。

1️⃣Redis 的高并发和快速原因

1. Redis 是基于内存的，内存的读写速度非常快。
2. Redis 是单线程的，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗。
3. Redis 使用多路复用技术，可以处理并发的连接。非阻塞 IO 部实现采用 epoll，采用了 epoll+自己实现的简单的事件框架。epoll 中的读、写、关闭、连接都转化成了事件，然后利用 epoll 的多路复用特性，绝不在 IO 上浪费一点时间。
4. 数据结构简单，对数据操作也简单，Redis 中的数据结构是专门进行设计的。
5. Redis 直接自己构建了 VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求；

2️⃣单进程单线程弊端
无法发挥多核 CPU 性能，不过可以通过在单机开多个 Redis 实例来完善。

3️⃣Redis高并发总结

1. Redis 是纯内存数据库，一般都是简单的存取操作，线程占用的时间很多，时间的花费主要集中在 IO 上，所以读取速度快。
2. 再说一下 IO，Redis 使用的是非阻塞 IO，IO 多路复用，使用了单线程来轮询描述符，将数据库的开、关、读、写都转换成了事件，减少了线程切换时上下文的切换和竞争。
3. Redis 采用了单线程的模型，保证了每个操作的原子性，也减少了线程的上下文切换和竞争。
4. 另外，数据结构也帮了不少忙，Redis 全程使用 hash 结构，读取速度快，还有一些特殊的数据结构，对数据存储进行了优化，如压缩表，对短数据进行压缩存储，再如，跳表，使用有序的数据结构加快读取的速度。
5. 还有一点，Redis 采用自己实现的事件分离器，效率比较高，内部采用非阻塞的执行方式，吞吐能力比较大。

五、常见疑问解答

1️⃣为什么不采用多进程或多线程处理？

①多线程处理可能涉及到锁。
②多线程处理会涉及到线程切换而消耗 CPU。

2️⃣单线程处理的缺点？

①耗时的命令会导致并发的下降，不只是读并发，写并发也会下降。
②无法发挥多核 CPU 性能，不过可以通过在单机开多个 Redis 实例来完善。

3️⃣Redis不存在线程安全问题？

Redis 采用了线程封闭的方式，把任务封闭在一个线程，自然避免了线程安全问题，不过对于需要依赖多个 Redis 操作(即多个 Redis 操作命令)的复合操作来说，依然需要锁，而且有可能是分布式锁。