Redis的线程机制与IO多路复用

一、Redis底层存在多个线程

单线程是指Redis 的**键值对读写（执行sql语句）**是由一个线程来完成的。

• 主进程中的主线程：负责读，写，删除操作，以及数据更新后的写AOF日志操作；
• 主进程中的子线程：负责数据的延迟删除子线程；
• 子进程中的子线程：负责RDB以及主从同步的子线程。

二、IO网络模型与Reids中的IO网络

网络I/O模型执行流程：

listen/bind — accept(建立连接，会阻塞) — recv(接收数据，会阻塞) — parse(解析数据) — write(操作数据) — send(发送数据)；

以上存在两处环节导致IO阻塞，影响性能。因此有以下解决方法

A） 为了优化accept建立连接的环节

• 使用线程池：一个线程建立一个socket实例连接客户端与服务端，并且有了线程池省去了新建和销毁线程的开销；
• 使用连接池：当某个客户端与服务端的传输任务完成后不断开连接，其他线程复用他们的连接，减少客户端与服务端建立连接的开销（MySQL的德鲁伊连接池）。

B） 为了优化recv接收数据环节—IO多路复用

1. 阻塞与非阻塞（解决接收数据前的耗时问题）：
   客户端向服务端发起请求，建立连接，之后双方会收发数据，但是如果一方没有成功发送数据，另一方的线程就会阻塞。这里采用select()等多路复用模式，集中到一个线程去监听多个连接上对方的数据是否准备完毕，如果select收到对方线程准备发送数据的信号，就会通知用户进程调用recv方法去接收连接上输送的数据（recv本身也可以长期监听连接对方的数据是否有发送，但是recv的资源开销比较大只能一对一监听，select多路复用开销小，可以一对多监听）。

2. 同步与异步（解决接收数据时的耗时问题）：
   这里用户进程首先要负责建立连接，然后负责recv收发数据，第五步接收数据时用户无法进行其他操作，所以其实这里还是阻塞了（同步synchronous，也就是服务端与客户端一起收发数据）；如果用户进程只负责建立连接，对于recv环节可以由服务端自动发给客户端，客户端线程不需要等待接收数据，可以去做其他事情就叫异步，客户端始终没有阻塞等待的环节（异步asynchronous，用户进程不需要等待数据的传输）。

Redis的网络IO

对应于Redis中，就是在第四步时选择Redis中相应的操作，成为回调（此步是Redis的耗时操作，没有采用异步操作），进行数据的增删改查，之前的连接、轮询不会占用Redis的IO主线程。

三、影响Redis耗时的操作

1. 对bigkey的写入删除操作；
2. sql语句复杂（Redis使用的是同步IO，高并发时此处会阻塞主线程，6.0后使用多线程机制执行sql语句）；
3. 同时删除大量key；
4. AOF设置为高频率写入磁盘；
5. 不合理的key淘汰机制（内存满了后要先删除部分旧的key才能写入新的key，高版本Redis优化后采用了异步线程来执行淘汰）。

参考文章：

https://time.geekbang.org/column/article/270474

https://blog.csdn.net/zhoudaxia/article/details/8974779?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522162899335316780366541875%2522%252C%2522scm%2522%253A%252220140713.130102334…%2522%257D&request_id=162899335316780366541875&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2_allsobaiduend~default-2-8974779.pc_search_download_positive&utm_term=%E7%BD%91%E7%BB%9CIO&spm=1018.2226.3001.4187