Redis的线程I/O模型

背景

• redis 是单线程的，为什么redis要采用单线程，而不采用多线程呢？
• redis 是基于内存进行存储数据的，所以CPU不是redis的瓶颈。
• 我们一般为什么要使用多线程呢？并发处理，提高处理的效率。且我们的系统一般搜需要去进行IO读取存储在磁盘的数据（数据库，本地本文件等）才进行处理的，所以单线程的话极其容易阻塞，会导致服务吞吐量很低。
• 但是redis并不会，redis是基于内存的，所有的运算都是内存级别的运算。那既然说到这里了，那这开个多线程那岂不是更快？？？？ 多线程的存在也有他的问题，只是redis在这多线程和单线程的使用有一个权衡，最终单线程是一个好的选择（个人理解）
• 多线程带来的问题：
  1. 代码复杂
  2. 并发安全问题
  3. 上下文线程切换的性能问题等。
• redis既然采用了单线程，他是如何将单线程的性能发挥到极致呢？那我们得看看redis的线程IO模型是如何设计的呢？

Redis的线程的IO模型

非阻塞IO

IO过程

1. 当客户端向服务端发起一个I/O链接的时候，然后服务端就会起一个线程来监听有没有文件过来，如果是阻塞IO的话，就会一直在哪里阻塞而不会返回，直到有数据进来，而我们说的非阻塞I/O就会直接返回，然后这个线程也就可以干别的事情了。但是非阻塞IO有一个很明显的问题，他不知道什么时候会有数据，数据何时回来？我想的是做一个长轮训吧，那要是由几百万个客户端，那redis的CPU也算是有瓶颈了，一些空轮训（导致性能做了无用功）。

IO多路复用

1. 事件轮询API就是用来解决这个问题的，最简单的事件轮询API是select函数，它是操作系统提供给用户程序的API。输入是读写描述符列表read_fds&write_fds，输出是与之对应的可读可写事件。同时还提供了一个timeout参数，如果没有任何事件到来，那么就最多等待timeout时间，线程处于阻塞状态。一旦期间有任何事件到来，就可以立即返回。时间过了之后还是没有任何事件到来，也会立即返回。拿到事件后，线程就可以继续挨个处理相应的事件。处理完了继续过来轮询。于是线程就进入了一个死循环，我们把这个死循环称为事件循环，一个循环为一个周期。不同的操作系统也拥有的事件轮训API也不一样，这里的select（）也是比较原始的多路复用API，后期优化的有epollo等。。。（https://segmentfault.com/a/1190000003063859）

在这里插入图片描述

指令队列

1. redis正是因为是单线程，所以他自己有一个指令队列，用来存放所有用户的指令，也算是很公平的方式。谁先到谁来。

响应队列

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

总结

• redis 是单线程采用的是I/O多路复用线程模型。
• 通过指令队列和响应队列可以让redis指令有序不乱的执行。

参考

• 《redis 深度历险》