Redis 为什么是单线程？高并发响应快？

文章相关视频讲解：

网路io底层epoll，单线程redi，多线程memcached，多进程Nginx

epoll的网络模型，从redis，memcached到nginx

如何高效学习使用redis

为什么 redis 单线程却能支撑高并发?

纯内存操作 核心是基于非阻塞的 IO 多路复用机制 单线程反而避免了多线程的频繁上下文切换问题

一、Redis 的高并发和快速原因

1.redis 是基于内存的，内存的读写速度非常快（纯内存）; 数据存在内存中，数据结构用 HashMap，HashMap 的优势就是查找和操作的时间复杂度都是 O(1)。

2.redis 是单线程的，省去了很多上下文切换线程的时间（避免线程切换和竞态消耗）。

3.redis 使用 IO 多路复用技术（IO multiplexing, 解决对多个 I/O 监听时,一个 I/O 阻塞影响其他 I/O 的问题），可以处理并发的连接（非阻塞 IO）。

下面重点介绍单线程设计和 IO 多路复用核心设计快的原因。

二、为什么 Redis 是单线程的

2.1.官方答案

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

2.2.性能指标

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

2.3.详细原因

1）不需要各种锁的性能消耗

Redis 的数据结构并不全是简单的 Key-Value，还有 list，hash 等复杂的结构，这些结构有可能会进行很细粒度的操作，比如在很长的列表后面添加一个元素，在 hash 当中添加或者删除一个对象。这些操作可能就需要加非常多的锁，导致的结果是同步开销大大增加。

总之，在单线程的情况下，就不用去考虑各种锁的问题，不存在加锁、释放锁操作，没有因为可能出现死锁而导致的性能消耗。

2）单线程多进程集群方案

单线程的威力实际上非常强大，单核 cpu 效率也非常高，多线程自然是可以比单线程有更高的性能上限，但是在今天的计算环境中，即使是单机多线程的上限也往往不能满足需要了，需要进一步摸索的是多服务器集群化的方案，这些方案中多线程的技术照样是用不上的。

所以“单线程、多进程的集群”不失为一个时髦的解决方案。

3）CPU 消耗

采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU。

但是如果 CPU 成为 Redis 瓶颈，或者不想让服务器其他 CUP 核闲置，那怎么办？

可以考虑多起几个 Redis 进程，Redis 是 key-value 数据库，不是关系数据库，数据之间没有约束。只要客户端分清哪些 key 放在哪个 Redis 进程上就可以了。

三、Redis 单线程的优劣势

3.1.单进程单线程优势

代码更清晰，处理逻辑更简单。不用去考虑各种锁的问题，不存在加锁、释放锁操作，没有因为可能出现死锁而导致的性能消耗。不存在“多进程或者多线程导致的切换”而消耗 CPU。

3.2.单进程单线程弊端

无法发挥多核 CPU 性能，不过可以通过在单机开多个 Redis 实例来完善。

四、IO 多路复用技术（多路网络连接复用一个 IO 线程, 时分复用）

实际上所有的 I/O 设备都被抽象为了文件这个概念，一切皆文件，Everything isFile，磁盘、网络数据、终端，甚至进程间通信工具管道 pipe 等都被当做文件对待。

所有的 I/O 操作也都是通过文件读写来实现的，这一非常优雅的抽象可以让程序员使用一套接口就能实现所有 I/O 操作。

文章福利 Linux 后端开发网络底层原理知识学习提升 点击 学习资料 获取，完善技术栈，内容知识点包括 Linux，Nginx，ZeroMQ，MySQL，Redis，线程池，MongoDB，ZK，Linux 内核，CDN，P2P，epoll，Docker，TCP/IP，协程，DPDK 等等。

常用的 I/O 操作接口一般有以下几类：

打开文件，open改变读写位置，seek文件读写，read、write关闭文件，close

那么，什么是 IO 多路复用呢？

有了文件描述符，进程对文件一无所知，比如文件在磁盘的什么位置上、内存是如何管理文件的等等，这些信息属于操作系统，进程无需关心，操作系统只需要给进程一个文件描述符就足够了。因此我们来完善上述程序：

int fd = open(file_name);read(fd, buff);

文件描述符太多了怎么办经过了这么多的铺垫，终于到高性能、高并发这一主题了。从前几节我们知道，所有 I/O 操作都可以通过文件样的概念来进行，这当然包括网络通信。如果你是一个 web 服务器，当三次握手成功以后，我们通过调用 accept 同样会得到一个文件描述符，只不过这个文件描述符是用来进行网络通信的，通过读写该文件描述符你就可以同客户端通信。在这里为了概念上好理解，我们称之为链接描述符，通过这个描述符我们就可以读写客户端的数据了。

int conn_fd = accept(...);

server 的处理逻辑通常是读取客户端请求数据，然后执行某些特定逻辑：

if(read(conn_fd, request_buff) > 0) {    do_something(request_buff);}

是不是非常简单，然而世界终归是复杂的，也不是这么简单的。接下来就是比较复杂的了。

既然我们的主题是高并发，那么 server 端就不可能只和一个客户端通信，而是成千上万个客户端。这时你需要处理不再是一个描述符这么简单，而是有可能要处理成千上万个描述符。为了不让问题一上来就过于复杂，我们先简单化，假设只同时处理两个客户端的请求。有的同学可能会说，这还不简单，这样写不就行了：

if(read(socket_fd1, buff) > 0) { // 处理第一个    do_something();}if(read(socket_fd2, buff) > 0) {    do_something();

这是非常典型的阻塞式 I/O，如果读取第一个请求进程被阻塞而暂停运行，那么这时我们就无法处理第二个请求了，即使第二个请求的数据已经就位，这也就意味着所有其它客户端必须等待，而且通常情况下也不会只有两个客户端而是成千上万个，上万个连接也要这样串行处理吗。

聪明的你一定会想到使用多线程，为每个请求开启一个线程，这样一个线程被阻塞不会影响到其它线程了，注意，既然是高并发，那么我们要为成千上万个请求开启成千上万个线程吗，大量创建销毁线程会严重影响系统性能。那么这个问题该怎么解决呢？

不要打电话给我，有需要我会打给你

方式一：

我们主动通过 I/O 接口， 问内核： 这些文件描述符对应的外设是不是已经就绪了？

方式二：

一种更好的方法是，我们把这些文件描述符，一股脑扔给内核，并霸气的告诉内核：“我这里有 1 万个文件描述符，你替我监视着它们，有可以读写的文件描述符时你就告诉我，我好处理”。

而不是弱弱的问内核：“第一个文件描述可以读写了吗？第二个文件描述符可以读写吗？第三个文件描述符可以读写了吗？”这样应用程序就从“繁忙”的主动变为清闲的被动了，反正哪些设备 ok 了内核会通知我， 能偷懒我才不要那么勤奋。

你有 N 个不知道什么时候来水的水龙头需要接水，你根据某种信号一会儿拧这个龙头，一会儿拧那个龙头把水都接了就是多路复用（一个线程）。

所谓 I/O 多路复用

回到我们的主题。所谓 I/O 多路复用指的是这样一个过程：我们拿到了一堆文件描述符(不管是网络相关的、还是磁盘文件相关等等，任何文件描述符都可以)， 通过调用某个函数告诉内核：“这个函数你先不要返回，你替我监视着这些描述符，当这堆文件描述符中有可以进行 I/O 读写操作的时候你再返回”。

当调用的这个函数返回后，我们就能知道哪些文件描述符可以进行 I/O 操作了。

那么有哪些函数可以用来进行 I/O 多路复用呢？在 Linux 世界中有这样三种机制可以用来进行 I/O 多路复用：

selectpollepoll

Redis 采用网络 IO 多路复用技术，来保证在多连接的时候系统的高吞吐量。

多路: 指的是多个 socket 网络连接;复用: 指的是复用一个线程。多路复用主要有三种技术：select，poll，epoll。epoll 是最新的, 也是目前最好的多路复用技术。

采用多路 I/O 复用技术的好处：

其一，可以让单个线程高效处理多个连接请求（尽量减少网络 IO 的时间消耗）。

其二，Redis 在内存中操作数据的速度非常快（内存里的操作不会成为这里的性能瓶颈）。主要以上两点造就了 Redis 具有很高的吞吐量。

I/O multiplexing 这里面的 multiplexing 指的其实是在单个线程通过记录跟踪每一个 Sock(I/O 流)的状态(对应空管塔里面的 Fight progress strip 槽)来同时管理多个 I/O 流. 发明它的原因，是尽量多的提高服务器的吞吐能力。

是不是听起来好拗口? 看个图就懂了.

在同一个线程里面， 通过拨开关的方式，来同时传输多个 I/O 流， (学过 EE 的人现在可以站出来义正严辞说这个叫“时分复用”了）。

非阻塞 IO 与 epoll ( nginx、redis 和 NIO 等核心思想 )

非阻塞 IO 内部实现采用 epoll，采用了 epoll+自己实现的简单的事件框架。epoll 中的读、写、关闭、连接都转化成了事件，然后利用 epoll 的多路复用特性，绝不在 IO 上浪费一点时间。详细参考：

五、Redis 高并发快总结

1. Redis 是纯内存数据库，一般都是简单的存取操作，线程占用的时间很多，时间的花费主要集中在 IO 上，所以读取速度快。

2. 再说一下 IO，Redis 使用的是非阻塞 IO、IO 多路复用，使用了单线程来轮询描述符，将数据库的开、关、读、写都转换成了事件，减少了线程切换时上下文的切换和竞争。

3. Redis 采用了单线程的模型，保证了每个操作的原子性，也减少了线程的上下文切换和竞争。

4. 另外，数据结构也帮了不少忙。

Redis 全程使用 hash 结构，读取速度快，还有一些特殊的数据结构，对数据存储进行了优化，如压缩表，对短数据进行压缩存储，再如，跳表，使用有序的数据结构加快读取的速度。

1. 还有一点，Redis 采用自己实现的事件分离器，效率比较高，内部采用非阻塞的执行方式，吞吐能力比较大。

六、Redis 常见性能问题和解决方案：

(1) Master 最好不要做任何持久化工作，如 RDB 内存快照和 AOF 日志文件；(Master 写内存快照，save 命令调度 rdbSave 函数，会阻塞主线程的工作，当快照比较大时对性能影响是非常大的，会间断性暂停服务，所以 Master 最好不要写内存快照;AOF 文件过大会影响 Master 重启的恢复速度)

(2) 如果数据比较重要，某个 Slave 开启 AOF 备份数据，策略设置为每秒同步一次

(3) 为了主从复制的速度和连接的稳定性，Master 和 Slave 最好在同一个局域网内

(4) 尽量避免在压力很大的主库上增加从库

(5) 主从复制不要用图状结构，用单向链表结构更为稳定，即：Master <- Slave1 <- Slave2 <- Slave3...；这样的结构方便解决单点故障问题，实现 Slave 对 Master 的替换。如果 Master 挂了，可以立刻启用 Slave1 做 Master，其他不变。

文章福利 Linux 后端开发网络底层原理知识学习提升 点击 学习资料 获取，完善技术栈，内容知识点包括 Linux，Nginx，ZeroMQ，MySQL，Redis，线程池，MongoDB，ZK，Linux 内核，CDN，P2P，epoll，Docker，TCP/IP，协程，DPDK 等等。

七、Redis 的回收策略

• volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰

• volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰

• volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰

• allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰

• allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰

• no-enviction（驱逐）：禁止驱逐数据

注意这里的 6 种机制，

（1）volatile 和 allkeys 规定了，是对已设置过期时间的数据集淘汰数据，还是从全部数据集淘汰数据。

（2）后面的 lru、ttl 以及 random 是三种不同的淘汰策略，再加上一种 no-enviction 永不回收的策略。

使用策略规则：

1、如果数据呈现幂律分布，也就是一部分数据访问频率高，一部分数据访问频率低，则使用 allkeys-lru

2、如果数据呈现平等分布，也就是所有的数据访问频率都相同，则使用 allkeys-random

八. 五种 I/O 模型介绍

IO 多路复用是 5 种 I/O 模型中的第 3 种，对各种模型讲个故事，描述下区别：

故事情节为：老李去买火车票，三天后买到一张退票。参演人员（老李，黄牛，售票员，快递员），往返车站耗费 1 小时。

1.阻塞 I/O 模型

老李去火车站买票，排队三天买到一张退票。

耗费：在车站吃喝拉撒睡 3 天，其他事一件没干。

2.非阻塞 I/O 模型

老李去火车站买票，隔 12 小时去火车站问有没有退票，三天后买到一张票。

耗费：往返车站 6 次，路上 6 小时，其他时间做了好多事。

3.I/O 复用模型

select/poll

老李去火车站买票，委托黄牛，然后每隔 6 小时电话黄牛询问，黄牛三天内买到票，然后老李去火车站交钱领票。

耗费：往返车站 2 次，路上 2 小时，黄牛手续费 100 元，打电话 17 次

epoll

老李去火车站买票，委托黄牛，黄牛买到后即通知老李去领，然后老李去火车站交钱领票。

耗费：往返车站 2 次，路上 2 小时，黄牛手续费 100 元，无需打电话。

epoll ： 进程只要等待在 epoll 上，epoll 代替进程去各个文件描述符上等待，当哪个文件描述符可读或者可写的时候就告诉 epoll，epoll 用小本本认真记录下来然后唤醒大哥：“进程大哥，快醒醒，你要处理的文件描述符我都记下来了”。这样进程被唤醒后就无需自己从头到尾检查一遍，因为 epoll 都已经记下来了。因此我们可以看到，在这种机制下，实际上利用的就是“不要打电话给我，有需要我会打给你”，这就不需要一遍一遍像孙子一样问各个文件描述符了，而是翻身做主人当大爷了，“你们那个文件描述符可读或者可写了主动报上来”，这中机制实际上就是大名鼎鼎的 —— 事件驱动，event-driven。

简单说 epoll 和 select/poll 最大区别是：1.epoll 内部使用了 mmap 共享了用户和内核的部分空间，避免了数据的来回拷贝 2.epoll 基于事件驱动，epoll_ctl 注册事件，并注册 callback 回调函数，epoll_wait 只返回发生的事件，避免了像 select 和 poll 对事件的整个轮询操作。

nginx 中使用了 epoll，是基于事件驱动模型的。由一个或多个事件收集器来收集或者分发事件，epoll 就属于事件驱动模型的事件收集器，将注册过的事件中发生的事件收集起来，master 进程负责管理 worker 进程。

4.信号驱动 I/O 模型

老李去火车站买票，给售票员留下电话，有票后，售票员电话通知老李，然后老李去火车站交钱领票。

耗费：往返车站 2 次，路上 2 小时，免黄牛费 100 元，无需打电话

5.异步 I/O 模型

老李去火车站买票，给售票员留下电话，有票后，售票员电话通知老李并快递送票上门。

耗费：往返车站 1 次，路上 1 小时，免黄牛费 100 元，无需打电话。

1 同 2 的区别是：自己轮询 2 同 3 的区别是：委托黄牛 3 同 4 的区别是：电话代替黄牛 4 同 5 的区别是：电话通知是自取还是送票上门

九、事件驱动( event-driven )

Event Driven Architecture Code Demo:

int event_handler1(event *ev){  // Non-blocking}
int event_handler2(event *ev){  // Non-blocking}
int main(){  // Init I/O multiplexer  IOMultiplexer multiplexer;
  // Registe event to multiplexer  multiplexer.Add(ev1)  multiplexer.Add(ev2)
  // Run main loop  while(ture){    ev_list = multiplexer.wait() // Only blocked here
    for(ev:ev_list){      switch(ev){        case: ev1          event_handler1();          break;        case: ev2          event_handler2();          break;          }    }  }}

Linux Event Driven Architecture