Redis系列四-Redis的线程 IO 模型

Posted java知路

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Redis系列四-Redis的线程 IO 模型相关的知识,希望对你有一定的参考价值。

既然Redis是单线程的工作模式,如何处理那么多的并发客户端连接?

Redis 是个单线程程序!这点必须铭记。也许你会怀疑高并发的 Redis 中间件怎么可能是单线程。很抱歉,它就是单线程,你的怀疑暴露了你基础知识的不足。莫要瞧不起单线程,除了 Redis 之外,Node.js 也是单线程,nginx 也是单线程,但是它们都是服务器高性能的典范。

优势使用不当就会变成劣势。redis单线程很快,因为它所有的数据都在内存中,所有的运算都是内存级别的运算。正因为 Redis 是单线程,所以要小心使用 Redis 指令,对于那些时间复杂度为 O(n) 级别的指令,一定要谨慎使用,一不小心就可能会导致 Redis 卡顿。

要理解它的高并发,首先要非阻塞 IO多路复用这些词汇

阻塞IO 非阻塞IO
当我们调用套接字的读写方法,默认它们是阻塞的。当用户线程发出IO请求之后,内核会去查看数据是否就绪,如果没有就绪就会等待数据就绪,而用户线程就会处于阻塞状态,用户线程交出CPU。当数据就绪之后,内核会将数据拷贝到用户线程,并返回结果给用户线程,用户线程才解除block状态。

用户线程需要不断地询问内核数据是否就绪,也就说非阻塞IO不会交出CPU,而会一直占用CPU。

非阻塞 IO 在套接字对象上提供了一个选项Non_Blocking,当这个选项打开时,读写方法不会阻塞,而是能读多少读多少,能写多少写多少。能读/写多少取决于内核为套接字分配的读/写缓冲区内部的数据字节数,读方法和写方法都会通过返回值来告知程序实际读写了多少字节。

事件轮询(多路复用)

Q1:谁去轮训的询问socket状态的问题,用户线程效率不高

Q2:用户线程该读/写多少何时才应该继续(线程如何得到通知)

事件轮询 API(它是Java 语言里面的 NIO 技术) 就是用来解决这2类问题的,首先它由内核轮训取代了用户线程轮训,并由内核通知,最简单的事件轮询 API 是select函数,它是操作系统提供给用户程序的 API。输入是读写描述符列表read_fds & write_fds,输出是与之对应的可读可写事件。同时还提供了一个timeout参数,如果没有任何事件到来,那么就最多等待timeout时间,线程处于阻塞状态。一旦期间有任何事件到来,就可以立即返回。时间过了之后还是没有任何事件到来,也会立即返回。拿到事件后,线程就可以继续挨个处理相应的事件。处理完了继续过来轮询。于是线程就进入了一个死循环,我们把这个死循环称为事件循环,一个循环为一个周期。

因为我们通过select系统调用同时处理多个通道描述符的读写事件,因此我们将这类系统调用称为多路复用 API。现代操作系统的多路复用 API 已经不再使用select系统调用,而改用epoll(linux)kqueue(freebsd & macosx),因为 select 系统调用的性能在描述符特别多时性能会非常差。它们使用起来可能在形式上略有差异,但是本质上都是差不多的,都可以使用下面面的伪代码逻辑进行理解。

while(true){
    read_events, write_events = select(read_fds, write_fds, timeout)
    for event in read_events:
        handle_read(event.fd)
    for event in write_events:
        handle_write(event.fd)
    handle_others()  # 处理其它事情,如定时任务等
}

服务器套接字serversocket对象的读操作是指调用accept接受客户端新连接。何时有新连接到来,也是通过select系统调用的读事件来得到通知的。

服务端

redis server就是通过blocking_keys(指令队列)和ready_keys(响应队列)两个数据结构来实现的阻塞操作。但整个阻塞并没有阻塞EventLoop本身,从而实现命令的快速响应。算是一个典型的空间换时间的设计思路。

指令队列

Redis 会将每个客户端套接字都关联一个指令队列。客户端的指令通过队列来排队进行顺序处理,先到先服务。

响应队列

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

定时任务

服务器处理要响应 IO 事件外,还要处理其它事情。比如定时任务就是非常重要的一件事。如果线程阻塞在 select 系统调用上,定时任务将无法得到准时调度。那 Redis 是如何解决这个问题的呢?Redis 的定时任务会记录在一个称为最小堆的数据结构中。这个堆中,最快要执行的任务排在堆的最上方。在每个循环周期,Redis 都会将最小堆里面已经到点的任务立即进行处理。处理完毕后,将最快要执行的任务还需要的时间记录下来,这个时间就是select系统调用的timeout参数。因为 Redis 知道未来timeout时间内,没有其它定时任务需要处理,所以可以安心睡眠timeout的时间。

客户端

分两种I/O模型来阐述:阻塞I/O(BIO)和非阻塞I/O(NIO),Jedis是BIO。

BinaryJedis 中一个blpop请求会向redis发起两次I/O请求,一次向redis发送BLPOP key命令,一次从对应的链接管道(channel)中读取数据。由于BIO的特性当channel中没有数据时会一直阻塞,直到有新数据为止。这样就实现了客户端的阻塞效果。
注意:这里的链接是被独享的,不然会有数据干扰。


以上是关于Redis系列四-Redis的线程 IO 模型的主要内容,如果未能解决你的问题,请参考以下文章

Redis线程模型的前世今生

Redis深度历险:核心原理和技术实现(原理篇)

Redis深度历险:核心原理和技术实现(原理篇)

深入Redis线程IO模型

面试者推荐 |Redis面试专题「常见问答系列」透析Redis常见技术相关的问题1~10题(进阶)

Redis线程IO模型的秘密知多少