理解Redis的线程 IO 模型

╰+攻爆jí腚メ 2022-04-05 02:59 275阅读 0赞

最近一位朋友问到：既然Redis是单线程的工作模式，如何处理那么多的并发客户端连接？

**Redis 是个单线程程序**！这点必须铭记。也许你会怀疑高并发的 Redis 中间件怎么可能是单线程。很抱歉，它就是单线程，你的怀疑暴露了你基础知识的不足。莫要瞧不起单线程，除了 Redis 之外，Node.js 也是单线程，Nginx 也是单线程，但是它们都是服务器高性能的典范。

**优势使用不当就会变成劣势**。redis单线程**很快**，因为它所有的数据都在内存中，所有的运算都是内存级别的运算。正因为 Redis 是单线程，所以要小心使用 Redis 指令，对于那些时间复杂度为 O(n) 级别的指令，一定要谨慎使用，一不小心就可能会导致 Redis 卡顿。

要理解它的高并发，首先要**非阻塞 IO**，**多路复用**这些词汇**。**

<table> 
 <tbody> 
  <tr> 
   <td style="width:338px;">阻塞IO</td> 
   <td style="width:561px;">非阻塞IO</td> 
  </tr> 
  <tr> 
   <td style="width:338px;">当我们调用套接字的读写方法，默认它们是阻塞的。当用户线程发出IO请求之后，<strong>内核会去查看数据是否就绪</strong>，如果没有就绪就会等待数据就绪，而用户线程就会处于阻塞状态，<strong>用户线程交出CPU</strong>。当数据就绪之后，<strong>内核会将数据拷贝到用户线程</strong>，并返回结果给用户线程，用户线程才解除block状态。</td> 
   <td style="width:561px;"> <p>用户线程需要不断地询问内核数据是否就绪，也就说非阻塞IO不会交出CPU，而会一直占用CPU。</p> <p>非阻塞 IO 在套接字对象上提供了一个选项<strong><code>Non_Blocking</code></strong>，当这个选项打开时，读写方法不会阻塞，而是能读多少读多少，能写多少写多少。能读/写多少取决于内核为套接字分配的读/写缓冲区内部的数据字节数，读方法和写方法都会通过返回值来告知程序实际读写了多少字节。</p> </td> 
  </tr> 
 </tbody> 
</table>

> **事件轮询(多路复用)**
> 
> Q1：谁去轮训的询问socket状态的问题，用户线程效率不高
> 
> Q2：用户线程该读/写多少何时才应该继续（线程如何得到通知）
> 
> 事件轮询 API（**它是Java 语言里面的 NIO 技术**） 就是用来解决这2类问题的，首先它由内核轮训取代了用户线程轮训，并由内核通知，最简单的事件轮询 API 是**`select`**函数，它是操作系统提供给用户程序的 API。输入是读写描述符列表**`read_fds & write_fds`**，输出是与之对应的可读可写事件。同时还提供了一个**`timeout`**参数，如果没有任何事件到来，那么就最多等待**`timeout`**时间，线程处于阻塞状态。一旦期间有任何事件到来，就可以立即返回。时间过了之后还是没有任何事件到来，也会立即返回。拿到事件后，线程就可以继续挨个处理相应的事件。处理完了继续过来轮询。于是线程就进入了一个死循环，我们把这个死循环称为事件循环，一个循环为一个周期。
> 
> ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70][]
> 
> 因为我们通过**`select`**系统调用同时处理多个通道描述符的读写事件，因此我们将这类系统调用称为**多路复用 API**。现代操作系统的多路复用 API 已经不再使用`select`系统调用，而改用**`epoll(linux)`**和**`kqueue(freebsd & macosx)`**，因为 select 系统调用的性能在描述符特别多时性能会非常差。它们使用起来可能在形式上略有差异，但是本质上都是差不多的，都可以使用下面面的伪代码逻辑进行理解。
> 
> *while(true)\{  
>     read\_events, write\_events = select(read\_fds, write\_fds, timeout)  
>     for event in read\_events:  
>         handle\_read(event.fd)  
>     for event in write\_events:  
>         handle\_write(event.fd)  
>     handle\_others()  \# 处理其它事情，如定时任务等  
> \}*
> 
> 服务器套接字**`serversocket`**对象的读操作是指调用**`accept`**接受客户端新连接。何时有新连接到来，也是通过**`select`**系统调用的读事件来得到通知的。

**服务端**

redis server就是通过blocking\_keys（指令队列）和ready\_keys（响应队列）两个数据结构来实现的阻塞操作。但整个阻塞并没有阻塞EventLoop本身，从而实现命令的快速响应。算是一个典型的空间换时间的设计思路。

**指令队列**

Redis 会将每个客户端套接字都关联一个指令队列。客户端的指令通过队列来排队进行顺序处理，先到先服务。

**响应队列**

Redis 同样也会为每个客户端套接字关联一个响应队列。Redis 服务器通过响应队列来将指令的返回结果回复给客户端。 如果队列为空，那么意味着连接暂时处于空闲状态，不需要去获取写事件，也就是可以将当前的客户端描述符从`write_fds`里面移出来。等到队列有数据了，再将描述符放进去。避免`select`系统调用立即返回写事件，结果发现没什么数据可以写。出这种情况的线程会飙高 CPU。

**定时任务**

服务器处理要响应 IO 事件外，还要处理其它事情。比如定时任务就是非常重要的一件事。如果线程阻塞在 select 系统调用上，定时任务将无法得到准时调度。那 Redis 是如何解决这个问题的呢？Redis 的定时任务会记录在一个称为`最小堆`的数据结构中。这个堆中，最快要执行的任务排在堆的最上方。在每个循环周期，Redis 都会将最小堆里面已经到点的任务立即进行处理。处理完毕后，将最快要执行的任务还需要的时间记录下来，这个时间就是`select`系统调用的`timeout`参数。因为 Redis 知道未来`timeout`时间内，没有其它定时任务需要处理，所以可以安心睡眠`timeout`的时间。

**客户端**

分两种I/O模型来阐述：阻塞I/O（BIO）和非阻塞I/O（NIO），Jedis是BIO。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70 1][]

BinaryJedis 中一个blpop请求会向redis发起两次I/O请求，一次向redis发送BLPOP key命令，一次从对应的链接管道（channel）中读取数据。由于BIO的特性当channel中没有数据时会一直阻塞，直到有新数据为止。这样就实现了客户端的阻塞效果。  
**注意：**这里的链接是被独享的，不然会有数据干扰。![88983770][]

参考链接：  
[redis.c源码][redis.c]  
[t\_list.c源码][t_list.c]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70]: /images/20220405/179e57b8bdf04f2ba1a6ae58893b8fa9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2l0c29mdGNoZW5mZWk_size_16_color_FFFFFF_t_70 1]: /images/20220405/8fe38f33751f43f6aaece002cbaedbba.png
[88983770]: /images/20220405/372e3b27d4324e11b3bd9de5cf33ef6f.png
[redis.c]: https://github.com/huangz1990/annotated_redis_source/blob/unstable/src/redis.c
[t_list.c]: https://github.com/huangz1990/annotated_redis_source/blob/unstable/src/t_list.c