Redis基础 -线程模型

Redis是一个事件驱动的、基于内存网络数据库服务器，其内部的数据存贮在内存之中，所以读写性能非常好。同时出于对数据安全性的角度考虑，引入了AOF/RDN等不同的持久化手段，将内存中的数据持久化到磁盘中。

4.0之前：Redis是单线程模型

Redis的事件处理模型是单线程的，它所收到的请求多是I/O密集型，而不是CPU密集型，因为即使引入了多线程来处理请求，并不会很显著的调高性能，反而会增大系统的复杂度和稳定性。

Redis内部有一个基于Reactor模式的事件处理模型，这个模型也是Redis的核心网络模型，这套事件处理模型对应的是Redis中的文件事件处理器，由于文件事件处理器是单线程运行的，其在单线程的事件循环中不断的处理事件，并最终给客户端响应，所以我们一般也说Redis是单线程的。
文件事件处理器主要有四个部分组成：

1、多个Socket套接字连接：Redis客户端与处理器采用socket套接字进行通信

2、IO多路复用程序：里面封装了select/poll/epoll等主流的多路复用函数，组成了一个多路复用函数库，在程序编译过程中，Redis会根据性能选择一个最优的多路复用函数用于多路复用程序。

3、文件事件分配器：文件事件是对socket中发生的IO事件的抽象，分配器根据不同的文件事件为其分配不同的处理器。

4、事件处理器：本质上是一个函数，其执行逻辑就是：根据接收到的请求进行执行相应的处理逻辑。常见的事件处理器有：连接应答处理器、命令读取处理器、命令响应处理器、主从复制处理器。

Redis 基于 Reactor 模式开发了自己的网络事件处理器：这个处理器被称为文件事件处理器（file event handler）。

1、Redis服务器同时与多个客户端建立连接，即在操作系统内核中存在多个已连接socket用于通信，由多路复用程序负责监督这些socket。

2、当由IO事件发生时，操作系统内核会多路复用程序进行通知，多路复用程序根据发生的IO事件类型，将其抽象为不同的文件事件，而后交由文件事件分配器为其分配不同的事件处理器进行处理。

4.0之后：引入多线程处理异步任务

Redis 在 v4.0 版本的时候就已经引入了的多线程来做一些异步操作，此举主要针对的是那些非常耗时的命令，通过将这些命令的执行进行异步化，避免阻塞单线程的事件循环。

        我们知道 Redis 的 DEL 命令是用来删除键值对，它是一个阻塞的命令，大多数情况下你要删除的 key 里存的值不会特别多，最多也就几十上百个对象，所以可以很快执行完，但是如果你要删的是一个超大的键值对，里面有几百万个对象，那么这条命令可能会阻塞至少好几秒，又因为事件循环是单线程的，所以会阻塞后面的其他事件，导致吞吐量下降。
        在 Redis v4.0 之后增加了一些的非阻塞命令如 UNLINK、FLUSHALL ASYNC、FLUSHDB ASYNC。
        UNLINK 命令其实就是 DEL 的异步版本，它不会同步删除数据，而只是把 key 从 keyspace 中暂时移除掉，然后将任务添加到一个异步队列，最后由后台线程去删除，并不会堵塞主线程。不过这里需要考虑一种情况是如果用 UNLINK 去删除一个很小的 key，用异步的方式去做反而开销更大，所以它会先计算一个开销的阀值，只有当这个值大于 64 才会使用异步的方式去删除 key，对于基本的数据类型如 List、Set、Hash 这些，阀值就是其中存储的对象数量。

6.0之后：引入多线程处理网络IO

Redis6.0 引入多线程主要是为了提高网络 IO 读写性能，因为这个算是 Redis 中的一个性能瓶颈（Redis 的瓶颈主要受限于内存和网络）。

虽然，Redis6.0 引入了多线程，但是 Redis 的多线程只是在网络数据的读写这类耗时操作上使用了，执行命令仍然是单线程顺序执行。因此，你也不需要担心线程安全问题。

Redis 的瓶颈并不在 CPU，而在内存和网络IO。内存不够的话，可以加内存或者做数据结构优化和其他优化等，但网络IO的性能优化才是大头，网络 IO 的读写在 Redis 整个执行期间占用了大部分的时间，如果把网络处理这部分做成多线程处理方式，那对整个 Redis 的性能会有很大的提升。