Redis 单线程模型

1、Redis的单线程

主要是指Redis的网络IO和键值对的读写是由一个线程来完成的，这也是Redis对外提供键值存储服务的主要流程。

但是Redis的其他功能，比如持久化、异步删除、集群数据同步等，其实是由额外的线程执行的。

所以，严格上来说，Redis并不是单线程的。

 

2、Redis高性能的原因

 

1. Redis大部分操作是在内存上完成的，同时采用了高效的数据结构，例如哈希表和跳表。

2. Redis采用了多路复用机制，使其在网络IO操作中能并发处理大量的客户请求，实现高吞吐量。

    

3、基本IO模型和阻塞点

例如处理一个Get请求的过程：

监听客户端请求（bind/listen）-->和客户端建立连接(accept)-->从Socket中读取请求(recv) --> 解析客户端发送请求(parse) --> 根据请求类型读取键值数据(get)-->给客户端返回结果（向Socket中写回数据send）

 

潜在的阻塞点：accept()和recv()

当Redis监听到一个客户端连接请求，但是一直没有成功建立连接，则会阻塞在accept()这个函数这里，导致其他客户端无法和Redis建立连接。

当Redis从一个客户端通过Recv()读取数据时，如果数据一直没有到到，Redis也会一直阻塞在Recv()

解决方式:socket网络模型本身支持非阻塞模式

4、非阻塞模式

主要体现在三个关键函数的调用上。

在 Socket模型中，不同的操作调用后会返回不同的套接字类型。

socket()方法返回主动套接字

然后调用listen()方法，将主动套接字转化为监听套接字，此时可以监听来自客户端的连接请求。

最后调用accept()方法，接收到达的客户端连接，并返回已连接套接字。

调用方法	返回套接字类型	非阻塞模式	效果
socket()	主动套接字
listen()	监听套接字	可设置	accept()非阻塞
accept()	已连接套接字	可设置	send()/recv()非阻塞

所谓非阻塞值的是Redis线程不用一直在阻塞点一直等待，可以返回处理其他操作。

但是，总得有机制继续在监听套接字上等待后续连接请求，并在有新的请求时，通知Redis。

同理，也需要有机制继续监听已连接套接字，并在数据到达时，通知Redis。

解决方式：多路复用I/O模型

4、多路复用IO模型

在Redis 只运行单线程的情况下，该机制允许内核中，同时存在多个监听套接字和已连接套接字。

内核会一直监听这些套接字上的连接请求或数据请求，一旦有请求到达，就会通知Redis线程处理，这就实现了一个Redis线程处理多个IO流的效果。

同时基于事件回调机制，针对不同事件的发生，调动相应的处理函数。并且事件会放到一个事件队列中，Redis单线程对该事件队列不断进行处理。提升响应性能。

5、Redis基本IO模型潜在的性能瓶颈

1、任意一个请求在server中一旦发生耗时，都会影响整个server的性能，也就是说，后面的请求都要等前面这个耗时请求处理完成后，自己才能被处理到。耗时的操作包括以下几种：

a、操作bigkey：写入一个bigkey在分配内存时需要消耗更多的时间，同样，删除bigkey释放内存同样会产生耗时；

b、使用复杂度过高的命令：例如SORT/SUNION/ZUNIONSTORE，或者O(N)命令，但是N很大，例如lrange key 0 -1一次查询全量数据；

c、大量key集中过期：Redis的过期机制也是在主线程中执行的，大量key集中过期会导致处理一个请求时，耗时都在删除过期key，耗时变长；

d、淘汰策略：淘汰策略也是在主线程执行的，当内存超过Redis内存上限后，每次写入都需要淘汰一些key，也会造成耗时变长；

e、AOF刷盘开启always机制：每次写入都需要把这个操作刷到磁盘，写磁盘的速度远比写内存慢，会拖慢Redis的性能；

f、主从全量同步生成RDB：虽然采用fork子进程生成数据快照，但fork这一瞬间也是会阻塞整个线程的，实例越大，阻塞时间越久；

2、并发量非常大时，单线程读写客户端IO数据存在性能瓶颈，虽然采用IO多路复用机制，但是读写客户端数据依旧是同步IO，只能单线程依次读取客户端的数据，无法利用到CPU多核。

针对问题1，一方面需要业务人员去规避，一方面Redis在4.0推出了lazy-free机制，把bigkey释放内存的耗时操作放在了异步线程中执行，降低对主线程的影响。

针对问题2，Redis在6.0推出了多线程，可以在高并发场景下利用CPU多核多线程读写客户端数据，进一步提升server性能，当然，只是针对客户端的读写是并行的，每个命令的真正操作依旧是单线程的

参考文档：https://time.geekbang.org/column/article/270474