背景

上回说到小枫在接受面试官的拷打，所幸第一个问题回答得还不错，因此面试官对于小枫的初步印象还行。我们接着来看看小枫是怎么和面试官继续过招的吧，他还能扛得住面试官几个连环炮呢？

面试官考察目的分析

面试官：Redis 了解吗？说说为什么单线程的 Redis 可以支持高并发访问？

面试官考察目的分析：

1、考察候选同学对于 Redis 原理的理解程度；

2、考察候选同学对于网络连接的理解程度；

面试题分析

面试官的问题中包含了两个关键词，一个是单线程一个是高并发访问，因此我们在回答问题的时候主要从两个方面出发，先解释清楚为什么 Redis 选择单线程的实现方式，再解释清楚为什么 Redis 能支持高并发访问。

小枫：（内心 OS：根据面试官的问题，决定从两方面来进行阐述，先整理下回答思路）

从 Redis 自身特性来说，Redis 是基于内存的数据库，所以数据处理速度非常快。另外它的底层使用了很多效率很高的数据结构，如哈希表和跳表等。另外 Redis 从狭义上面来说他是单线程的，网络请求解析与数据读写都是由主线程完成。因此它内部就省去了很多多线程访问共享数据资源的繁琐设计，同时也避免了频繁的线程上下文切换因此减少了多线程的系统开销。

从 IO 模型角度来说，Redis 使用的是 IO 多路复用模型，使得它可以在网络 IO 操作并发处理数十万的客户端网络连接，实现非常高的网络吞吐率。这也是 Redis 可以实现高并发访问的最主要的原因。

PS：关于 IO 模型可以参考以前的文章

一文说清BIO、NIO、AIO不同IO模型演进之路

面试官：刚才你提到了 IO 多路复用模型，能详细说下 Redis 的 IO 多路复用的原理吗？

小枫：（内心 OS：当时为了搞清楚这个问题，还特意扒了 Redis 源码来看，对于一个 Java 程序猿来说，看 c 真的头晕啊）

好的。首先要明确的是 Redis 依赖 Linux 操作系统实现的高性能 IO，刚刚提到的多路复用 IO 模型实际也是传统阻塞型 IO 模型演化而来的。在传统的网络 IO 操作中，accept() 和 recv()函数都是阻塞型的，一旦发生阻塞，影响其他网络连接。但是在多路复用 IO 模型中，可以实现同时存在多个 socket，内核监听 socket 中的是否有数据请求或者连接请求，如果有请求，那么内核就会交给 Redis 进行处理，因此 Redis 的主线程，也就是单线程的 Redis 可以处理多个 IO 连接。

整个过程涉及到 epoll_create、epoll_ctl 以及 epoll_wait 三个系统调用，具体的过程大致是这样的：

1、当 Redis 启动的时候，会调用内核的 epoll_create 创建 epoll 对象，在这个过程中包含初始化红黑树 cache 以及双向链表，红黑树中主要存储了需要进行状态监控的 FD，实际就是 epitem 结构体，双向链表中存储了需要返回给用户已经处于就绪状态的事件。

2、调用 epoll_ctl()，通过 epoll_ctl 注册要监听的事件类型，将客户端 FD 以及需要监听的事件添加到红黑树 cache 中，添加时进行检查，如果已存在则返回，如果不存在则添加到节点当中，同时注册相应的事件回调函数，如果存在连接事件或者读写事件，那么就会通过回调函数将就绪的事件加入到双向链表中，实际就是红黑树的节点。

3、Redis 调用 epoll_wait 获取已经就绪的事件的 fired 数组，fire 数组的事件中存储了就绪的 FD 以及事件类型，遍历数组中的事件，根据事件类型处理函数继续后续的处理。如果是读事件那就调用读事件处理函数进行处理。对于 Redis 来说它只要关注链表中有没有数据就好，有数据就会进行读取，没有数据则阻塞超过 timeout 之后再进行调用。在大多数情况下，返回的数组中包含的事件并不多。通过这样的设计，Redis 不需要一直轮训检查到底有没有实际的请求发生，避免了 CPU 资源的浪费。因此及时是单线程的 Redis，借助于 epoll 机制，它也可以实现数十万连接的并发处理。

面试官：（内心 OS：小伙子回答的不错，看来常见的面试题难不倒你啊，那么我就来问问陷阱题吧，嘿嘿）

总结

程序猿小枫这次表现不错，抗住了面试官关于 Redis 的连环炮，那么接下来的问题他还能回答出来吗？请大家继续拭目以待哦。