参考：

  1. Redis 多线程网络模型全面揭秘 - 知乎 (zhihu.com)

引言

Redis 6.0 之前单线程指的是 Redis 只有一个线程干活么？

非也，Redis 在处理客户端的请求时，包括获取 (socket 读)、解析、执行、内容返回 (socket 写) 等都由一个顺序串行的主线程处理，这就是所谓的「单线程」。

其中执行命令阶段，由于 Redis 是单线程来处理命令的，所有每一条到达服务端的命令不会立刻执行，所有的命令都会进入一个 Socket 队列中，当 socket 可读则交给单线程事件分发器逐个被执行。
image-20240320233220462

追求性能的极致：Redis6.0的多线程模型（附面试题）-CSDN博客

==此外，有些命令操作可以用后台线程或子进程执行（比如数据删除、快照生成、AOF 重写）。==

Redis 6.0之前的单线程工作流程

  1. Redis 服务器启动，开启主线程事件循环（Event Loop），注册 acceptTcpHandler 连接应答处理器到用户配置的监听端口对应的文件描述符，等待新连接到来；
  2. 客户端和服务端建立网络连接；
  3. acceptTcpHandler 被调用，主线程使用 AE 的 API 将 readQueryFromClient 命令读取处理器绑定到新连接对应的文件描述符上，并初始化一个 client 绑定这个客户端连接；
  4. 客户端发送请求命令，触发读就绪事件，主线程调用 readQueryFromClient 通过 socket 读取客户端发送过来的命令存入 client->querybuf 读入缓冲区；
  5. 接着调用 processInputBuffer，在其中使用 processInlineBuffer 或者 processMultibulkBuffer 根据 Redis 协议解析命令，最后调用 processCommand 执行命令；
  6. 根据请求命令的类型（SET, GET, DEL, EXEC 等），分配相应的命令执行器去执行，最后调用 addReply 函数族的一系列函数将响应数据写入到对应 client 的写出缓冲区：client->buf 或者 client->reply ，client->buf 是首选的写出缓冲区，固定大小 16KB，一般来说可以缓冲足够多的响应数据，但是如果客户端在时间窗口内需要响应的数据非常大，那么则会自动切换到 client->reply 链表上去，使用链表理论上能够保存无限大的数据（受限于机器的物理内存），最后把 client 添加进一个 LIFO 队列 clients_pending_write；
  7. 在事件循环（Event Loop）中，主线程执行 beforeSleep --> handleClientsWithPendingWrites，遍历 clients_pending_write 队列，调用 writeToClient 把 client 的写出缓冲区里的数据回写到客户端，如果写出缓冲区还有数据遗留，则注册 sendReplyToClient 命令回复处理器到该连接的写就绪事件，等待客户端可写时在事件循环中再继续回写残余的响应数据。

那 Redis 6.0 为啥要引入多线程呀？

读写网络的 read/write 系统调用占用了Redis 执行期间大部分CPU 时间，瓶颈主要在于网络的 IO 消耗, 优化主要有两个方向:

  • 提高网络 IO 性能，典型的实现比如使用 DPDK 来替代内核网络栈的方式。
  • 使用多线程充分利用多核，提高网络请求读写的并行度，典型的实现比如 Memcached。

添加对用户态网络协议栈的支持，需要修改 Redis 源码中和网络相关的部分（例如修改所有的网络收发请求函数），这会带来很多开发工作量。

而且新增代码还可能引入新 Bug，导致系统不稳定。

所以，Redis 采用多个 IO 线程来处理网络请求，提高网络请求处理的并行度。

==注意==：Redis 多 IO 线程模型只用来处理网络读写请求，对于 Redis 的读写命令，依然是单线程处理。

主线程和IO线程怎么协作完成请求处理的

流程图一：
image-20240320234536076
流程图二：
image-20240322094338020

  1. Redis 服务器启动，开启主线程事件循环（Event Loop），注册 acceptTcpHandler 连接应答处理器到用户配置的监听端口对应的文件描述符，等待新连接到来；
  2. 客户端和服务端建立网络连接；
  3. acceptTcpHandler 被调用，主线程使用 AE 的 API 将 readQueryFromClient 命令读取处理器绑定到新连接对应的文件描述符上，并初始化一个 client 绑定这个客户端连接；
  4. 客户端发送请求命令，触发读就绪事件，服务端主线程不会通过 socket 去读取客户端的请求命令，而是先将 client 放入一个 LIFO 队列 clients_pending_read；
  5. 在事件循环（Event Loop）中，主线程执行 beforeSleep -->handleClientsWithPendingReadsUsingThreads，利用 Round-Robin 轮询负载均衡策略，把 clients_pending_read队列中的连接均匀地分配给 I/O 线程各自的本地 FIFO 任务队列 io_threads_list[id] 和主线程自己，I/O 线程通过 socket 读取客户端的请求命令，存入 client->querybuf 并解析第一个命令，但不执行命令，主线程忙轮询，等待所有 I/O 线程完成读取任务；
  6. 主线程和所有 I/O 线程都完成了读取任务，主线程结束忙轮询，遍历 clients_pending_read 队列，执行所有客户端连接的请求命令，先调用 processCommandAndResetClient 执行第一条已经解析好的命令，然后调用 processInputBuffer 解析并执行客户端连接的所有命令，在其中使用 processInlineBuffer 或者 processMultibulkBuffer 根据 Redis 协议解析命令，最后调用 processCommand 执行命令；
  7. 根据请求命令的类型（SET, GET, DEL, EXEC 等），分配相应的命令执行器去执行，最后调用 addReply 函数族的一系列函数将响应数据写入到对应 client 的写出缓冲区：client->buf 或者 client->reply ，client->buf 是首选的写出缓冲区，固定大小 16KB，一般来说可以缓冲足够多的响应数据，但是如果客户端在时间窗口内需要响应的数据非常大，那么则会自动切换到 client->reply 链表上去，使用链表理论上能够保存无限大的数据（受限于机器的物理内存），最后把 client 添加进一个 LIFO 队列 clients_pending_write；
  8. 在事件循环（Event Loop）中，主线程执行 beforeSleep --> handleClientsWithPendingWritesUsingThreads，利用 Round-Robin 轮询负载均衡策略，把 clients_pending_write 队列中的连接均匀地分配给 I/O 线程各自的本地 FIFO 任务队列 io_threads_list[id] 和主线程自己，I/O 线程通过调用 writeToClient 把 client 的写出缓冲区里的数据回写到客户端，主线程忙轮询，等待所有 I/O 线程完成写出任务；
  9. 主线程和所有 I/O 线程都完成了写出任务， 主线程结束忙轮询，遍历 clients_pending_write 队列，如果 client 的写出缓冲区还有数据遗留，则注册 sendReplyToClient 到该连接的写就绪事件，等待客户端可写时在事件循环中再继续回写残余的响应数据。

这里大部分逻辑和之前的单线程模型是一致的，变动的地方仅仅是把读取客户端请求命令和回写响应数据的逻辑异步化了，交给 I/O 线程去完成，这里需要特别注意的一点是：I/O 线程仅仅是读取和解析客户端命令而不会真正去执行命令，客户端命令的执行最终还是要在主线程上完成。

该设计有如下特点：
1、IO 线程要么同时在读 socket，要么同时在写，不会同时读或写
2、IO 线程只负责读写 socket 解析命令，不负责命令处理
3、一次有多少个IO线程执行操作由配置决定。

Redis6之前，主线程处理了accept事件，并将socket的读事件和写事件都注册到主线程这个多路复用器上，即主线程处理了所有的IO事件，之后再进行命令解析与执行并将处理完的消息写入到socket中，这些都是主线程做的。而Redis6之后加入了IO线程，采用了主从Reactor模型，此时主线程处理socket的accept事件，并将这些socket注册到IO线程的多路复用器上，之后IO线程负责读事件并将根据RESP协议解析命令，等所有IO线程都解析完成后，主线程此时执行队列中的命令，并把处理结果放入socket中(此时还未发给客户端)，之后由IO线程统一发送到客户端。

Redis每一次的操作都是创建了一个新的连接，然后将命令发送过去等待返回，还是一个超长连接，持续不断的发送命令然后获得结果？Java中的Redis连接框架是如何实现的？

Redis 是一个高性能的键值对存储系统，它支持多种数据结构，如字符串、列表、集合、哈希表等。在与 Redis 交互时，可以选择使用短连接或长连接。

短连接（每次操作创建新连接）

在短连接模式下，每次执行操作时都会创建一个新的连接，命令发送后等待返回结果，然后关闭连接。这种方式适用于偶尔的操作，因为它每次建立连接都会有额外的开销。在 Java 中，如果使用 Jedis 客户端，可以通过 Jedis 类的 connect() 方法来创建连接，执行命令后使用 close() 方法关闭连接。

长连接（持续的连接，连续操作）

长连接模式下，客户端和 Redis 服务器之间建立一个持久的连接，可以持续不断地发送命令并获取结果，而不需要每次都重新建立连接。这种方式适用于频繁的操作，因为它减少了连接建立和关闭的开销。在 Jedis 客户端中，可以通过配置 pool 来管理连接池，从而复用连接。

数据库连接也是同理。