Redis 核心原理和架构 _Redis

本文介绍了 redis 核心原理和架构：基于事件驱动的模型。事件模型是构成 Redis 内核的引擎，Redis 的丰富功能和组件都是构建在这个模型上的。如果你使用过 Redis，那么本文可以为你打开一道进入 Redis 内部世界的门，窥探 Redis 如何构建它的帝国。
本文先对 Redis 使用的事件模型和原理进行介绍，然后按以下主题顺序展开：

Redis 主程序启动流程
事件循环（eventloop）
事件处理器（event handler）
事件处理流程

最后以一次客户端 SET 命令操作为例子，讲解一个请求在 Redis 内部的流转是如何完成的。
阅读之前
为了方便公众号上进行阅读，帮助读者快速掌握 Redis 核心原理，本文对 Redis 模型进行了简化，去掉了大量的检查和异常处理流程，并且仅在必要的时候通过代码说明。
本文参考的源码基于编写时的最新分支 Redis 5.0.3，实际对照中发现 Redis 的核心逻辑在历史版本迭代中变化不大，也体现了 Redis 的这个核心逻辑的地位。
一、Redis 事件驱动模型
1.1 事件驱动模型
事件驱动，顾名思义，只有在发生某些事件的时候，程序才会有所行动。
事件驱动模型在架构设计领域也称为 Reactor 模式，体现的是一种被动响应的特征。
事件驱动模型通常可以抽象为如下图所示流程：

文章插图

主程序处于一个阻塞状态的事件循环(event loop)中等待事件(event)，当有事件发生时，根据事件的属性分发到相应的处理函数进行处理。事件以并发的方式发送到服务处理器 (service handler)，服务处理器将事件整合到一个有序队列中（这过程称为 demultiplexes），并分发到具体的请求处理器 (request handler)进行处理。
为了阅读的方便，因为「事件」这个词在中文中较常见，所以下文针对事件模型中的「事件」等专用术语，会进行特定的标识，如：事件循环 (event loop)，事件 (event)，处理器 (handler)等。
1.2 Redis 核心原理
Redis 在事件驱动模型下工作，当有来自外部或内部的请求的时候，才会执行相关的流程。
Redis 程序的整个运作都是围绕事件循环 (event loop)进行的。
事件循环对于 Redis 而言，就像是一台车的引擎一样，提供了整个系统所需的流转动力。所有其他的组件都是基于这个引擎的基础上组合和构建起来的。可以说理解了 Redis 的事件循环就能了解 Redis 的工作原理的核心。
Redis 事件模型如下图所示：

文章插图

事件循环 eventloop同时监控多个事件，这里的事件本质上是 Redis 对于连接套接字的抽象。
当套接字变为可读或者可写状态时，就会触发该事件，把就绪的事件放在一个待处理事件的队列中，以有序 (sequentially)、同步 (synchronously) 的方式发送给事件处理器进行处理。这个过程在 Redis 中被称为Fire 。
Redis 的事件循环会保存两个列表：events和fired列表，前者表示正在监听的事件，后者表示就绪事件，可以被进一步执行。
在具体实现时，Redis 采用 IO 多路复用 (multiplexing) 的方式，封装了操作系统底层 select/epoll 等函数，实现对多个套接字 (socket) 的监听，这些套接字就是对应多个不同客户端的连接。
最后由对应的处理器将处理的结果返回给客户端去。
Redis事件的来源有两种：文件事件和时间事件，限于篇幅问题，本文主要介绍文件事件的处理流程，时间事件会在文章最后做简要的说明。
以上就概括了Redis 处理用户请求的大致过程。从这个过程我们可以发现：

Redis 处理所有命令都是顺序执行的，其中包括来自客户端的连接请求。所以当 Redis 在处理一个复杂度高、时间很长的请求（比如 KEYS 命令）的时候，其他客户端的连接都没办法相应。
Redis 内部定时执行的任务也是放在顺序队列中处理，其中也可能包含时间较长的任务，比如自动删除一个过期的大 Key，比如很大 list, hash, set 等。所以有时候会遇到明明业务没有主动操作复杂，但也会出现卡顿的问题。

1.3 事件驱动模型的优势
有利于架构解耦和模块化开发
有利于功能架构实现上更加解耦，模块的可重用性更高。因事件循环的流程本身和具体的处理逻辑之间是独立的，只要在创建事件的时候关联特定的处理逻辑（事件处理器），就可以完成一次事件的创建和处理。