事件 =========================== 事件是 Redis 服务器的核心， 它处理两项重要的任务： 1. 处理文件事件：在多个客户端中实现多路复用，接受它们发来的命令请求，并将命令的执行结果返回给客户端。 2. 时间事件：实现服务器常规操作（server cron job）。 本文以下内容就来介绍这两种事件， 以及它们背后的运作模式。 文件事件 ------------ Redis 服务器通过在多个客户端之间进行多路复用， 从而实现高效的命令请求处理： 多个客户端通过套接字连接到 Redis 服务器中， 但只有在套接字可以无阻塞地进行读或者写时， 服务器才会和这些客户端进行交互。 Redis 将这类因为对套接字进行多路复用而产生的事件称为文件事件（file event）， 文件事件可以分为读事件和写事件两类。 读事件 ^^^^^^^^^ 读事件标志着客户端命令请求的发送状态。 当一个新的客户端连接到服务器时， 服务器会给为该客户端绑定读事件， 直到客户端断开连接之后， 这个读事件才会被移除。 读事件在整个网络连接的生命期内， 都会在等待和就绪两种状态之间切换： - 当客户端只是连接到服务器，但并没有向服务器发送命令时，该客户端的读事件就处于等待状态。 - 当客户端给服务器发送命令请求，并且请求已到达时（相应的套接字可以无阻塞地执行读操作），该客户端的读事件处于就绪状态。 作为例子， 下图展示了三个已连接到服务器、但并没有发送命令的客户端： .. graphviz:: image/event-waiting-for-read.dot 这三个客户端的状态如下表： ============= ========================== =============================== 客户端 读事件状态 命令发送状态 客户端 X 等待 未发送 客户端 Y 等待 未发送 客户端 Z 等待 未发送 ============= ========================== =============================== 之后， 当客户端 X 向服务器发送命令请求， 并且命令请求已到达时， 客户端 X 的读事件状态变为就绪： .. graphviz:: image/event-ready-for-read.dot 这时， 三个客户端的状态如下表（只有客户端 X 的状态被更新了）： ============= ========================== =============================== 客户端 读事件状态 命令发送状态 客户端 X **就绪** **已发送，并且已到达** 客户端 Y 等待 未发送 客户端 Z 等待 未发送 ============= ========================== =============================== 当事件处理器被执行时， 就绪的文件事件会被识别到， 相应的命令请求会被发送到命令执行器， 并对命令进行求值。 写事件 ^^^^^^^^^ 写事件标志着客户端对命令结果的接收状态。 和客户端自始至终都关联着读事件不同， 服务器只会在有命令结果要传回给客户端时， 才会为客户端关联写事件， 并且在命令结果传送完毕之后， 客户端和写事件的关联就会被移除。 一个写事件会在两种状态之间切换： - 当服务器有命令结果需要返回给客户端，但客户端还未能执行无阻塞写，那么写事件处于等待状态。 - 当服务器有命令结果需要返回给客户端，并且客户端可以进行无阻塞写，那么写事件处于就绪状态。 当客户端向服务器发送命令请求， 并且请求被接受并执行之后， 服务器就需要将保存在缓存内的命令执行结果返回给客户端， 这时服务器就会为客户端关联写事件。 作为例子， 下图展示了三个连接到服务器的客户端， 其中服务器正等待客户端 X 变得可写， 从而将命令的执行结果返回给它： .. graphviz:: image/event-waiting-for-write.dot 此时三个客户端的事件状态分别如下表： ============= ========================== ================================= 客户端 读事件状态 写事件状态 客户端 X 等待 等待 客户端 Y 等待 无 客户端 Z 等待 无 ============= ========================== ================================= 当客户端 X 的套接字可以进行无阻塞写操作时， 写事件就绪， 服务器将保存在缓存内的命令执行结果返回给客户端： .. graphviz:: image/event-ready-for-write.dot 此时三个客户端的事件状态分别如下表（只有客户端 X 的状态被更新了）： ============= ========================== ================================= 客户端 读事件状态 写事件状态 客户端 X 等待 **已就绪** 客户端 Y 等待 无 客户端 Z 等待 无 ============= ========================== ================================= 当命令执行结果被传送回客户端之后， 客户端和写事件之间的关联会被解除（只剩下读事件）， 至此， 返回命令执行结果的动作执行完毕： .. graphviz:: image/event-waiting-for-read.dot .. note:: 同时关联写事件和读事件 前面提到过，读事件只有在客户端断开和服务器的连接时，才会被移除。 这也就是说，当客户端关联写事件的时候，实际上它在同时关联读/写两种事件。 因为在同一次文件事件处理器的调用中， 单个客户端只能执行其中一种事件（要么读，要么写，但不能又读又写）， 当出现读事件和写事件同时就绪的情况时， 事件处理器优先处理读事件。 这也就是说， 当服务器有命令结果要返回客户端， 而客户端又有新命令请求进入时， 服务器先处理新命令请求。 时间事件 ----------- 时间事件记录着那些要在指定时间点运行的事件， 多个时间事件以无序链表的形式保存在服务器状态中。 每个时间事件主要由三个属性组成： - ``when`` ：以毫秒格式的 UNIX 时间戳为单位，记录了应该在什么时间点执行事件处理函数。 - ``timeProc`` ：事件处理函数。 - ``next`` 指向下一个时间事件，形成链表。 根据 ``timeProc`` 函数的返回值，可以将时间事件划分为两类： - 如果事件处理函数返回 ``ae.h/AE_NOMORE`` ，那么这个事件为单次执行事件：该事件会在指定的时间被处理一次，之后该事件就会被删除，不再执行。 - 如果事件处理函数返回一个非 ``AE_NOMORE`` 的整数值，那么这个事件为循环执行事件：该事件会在指定的时间被处理，之后它会按照事件处理函数的返回值，更新事件的 ``when`` 属性，让这个事件在之后的某个时间点再次运行，并以这种方式一直更新并运行下去。 可以用伪代码来表示这两种事件的处理方式： .. code-block:: python def handle_time_event(server, time_event): # 执行事件处理器，并获取返回值 # 返回值可以是 AE_NOMORE ，或者一个表示毫秒数的非符整数值 retval = time_event.timeProc() if retval == AE_NOMORE: # 如果返回 AE_NOMORE ，那么将事件从链表中删除，不再执行 server.time_event_linked_list.delete(time_event) else: # 否则，更新事件的 when 属性 # 让它在当前时间之后的 retval 毫秒之后再次运行 time_event.when = unix_ts_in_ms() + retval 当时间事件处理器被执行时， 它遍历所有链表中的时间事件， 检查它们的到达事件（\ ``when`` 属性）， 并执行其中的已到达事件： .. code-block:: python def process_time_event(server): # 遍历时间事件链表 for time_event in server.time_event_linked_list: # 检查事件是否已经到达 if time_event.when <= unix_ts_in_ms(): # 处理已到达事件 handle_time_event(server, time_event) .. note:: 无序链表并不影响时间事件处理器的性能 在目前的版本中， 正常模式下的 Redis 只带有 ``serverCron`` 一个时间事件， 而在 benchmark 模式下， Redis 也只使用两个时间事件。 在这种情况下， 程序几乎是将无序链表退化成一个指针来使用， 所以使用无序链表来保存时间事件， 并不影响事件处理器的性能。 时间事件应用实例：服务器常规操作 --------------------------------------- 对于持续运行的服务器来说， 服务器需要定期对自身的资源和状态进行必要的检查和整理， 从而让服务器维持在一个健康稳定的状态， 这类操作被统称为常规操作（cron job）。 在 Redis 中， 常规操作由 ``redis.c/serverCron`` 实现， 它主要执行以下操作： - 更新服务器的各类统计信息，比如时间、内存占用、数据库占用情况等。 - 清理数据库中的过期键值对。 - 对不合理的数据库进行大小调整。 - 关闭和清理连接失效的客户端。 - 尝试进行 AOF 或 RDB 持久化操作。 - 如果服务器是主节点的话，对附属节点进行定期同步。 - 如果处于集群模式的话，对集群进行定期同步和连接测试。 Redis 将 ``serverCron`` 作为时间事件来运行， 从而确保它每隔一段时间就会自动运行一次， 又因为 ``serverCron`` 需要在 Redis 服务器运行期间一直定期运行， 所以它是一个循环时间事件： ``serverCron`` 会一直定期执行，直到服务器关闭为止。 在 Redis 2.6 版本中， 程序规定 ``serverCron`` 每秒运行 ``10`` 次， 平均每 ``100`` 毫秒运行一次。 从 Redis 2.8 开始， 用户可以通过修改 ``hz`` 选项来调整 ``serverCron`` 的每秒执行次数， 具体信息请参考 ``redis.conf`` 文件中关于 ``hz`` 选项的说明。 事件的执行与调度 ------------------------ 既然 Redis 里面既有文件事件， 又有时间事件， 那么如何调度这两种事件就成了一个关键问题。 简单地说， Redis 里面的两种事件呈合作关系， 它们之间包含以下三种属性： 1. 一种事件会等待另一种事件执行完毕之后，才开始执行，事件之间不会出现抢占。 2. 事件处理器先处理文件事件（处理命令请求），再执行时间事件（调用 ``serverCron``\ ） 3. 文件事件的等待时间（类 ``poll`` 函数的最大阻塞时间），由距离到达时间最短的时间事件决定。 这些属性表明， 实际处理时间事件的时间， 通常会比时间事件所预定的时间要晚， 至于延迟的时间有多长， 取决于时间事件执行之前， 执行文件事件所消耗的时间。 比如说， 以下图表就展示了， 虽然时间事件 ``TE 1`` 预定在 ``t1`` 时间执行， 但因为文件事件 ``FE 1`` 正在运行， 所以 ``TE 1`` 的执行被延迟了： :: t1 | V time -----------------+------------------->| | FE 1 | TE 1 | |<------>| TE 1 delay time 另外， 对于像 ``serverCron`` 这类循环执行的时间事件来说， 如果事件处理器的返回值是 ``t`` ， 那么 Redis 只保证： - 如果两次执行时间事件处理器之间的时间间隔大于等于 ``t`` ， 那么这个时间事件至少会被处理一次。 - 而并不是说， 每隔 ``t`` 时间， 就一定要执行一次事件 —— 这对于不使用抢占调度的 Redis 事件处理器来说，也是不可能做到的 举个例子， 虽然 ``serverCron`` （\ ``sC``\ ）设定的间隔为 ``10`` 毫秒， 但它并不是像如下那样每隔 ``10`` 毫秒就运行一次： :: time ----------------------------------------------------->| |<---- 10 ms ---->|<---- 10 ms ---->|<---- 10 ms ---->| | FE 1 | FE 2 | sC 1 | FE 3 | sC 2 | FE 4 | ^ ^ ^ ^ ^ | | | | | file event time event | time event | handler handler | handler | run run | run | file event file event handler handler run run 在实际中， ``serverCron`` 的运行方式更可能是这样子的： :: time ----------------------------------------------------------------------->| |<---- 10 ms ---->|<---- 10 ms ---->|<---- 10 ms ---->|<---- 10 ms ---->| | FE 1 | FE 2 | sC 1 | FE 3 | FE 4 | FE 5 | sC 2 | |<-------- 15 ms -------->| |<------- 12 ms ------->| >= 10 ms >= 10 ms ^ ^ ^ ^ | | | | file event time event | time event handler handler | handler run run | run file event handler run 根据情况， 如果处理文件事件耗费了非常多的时间， ``serverCron`` 被推迟到一两秒之后才能执行， 也是有可能的。 整个事件处理器程序可以用以下伪代码描述： .. code-block:: python def process_event(): # 获取执行时间最接近现在的一个时间事件 te = get_nearest_time_event(server.time_event_linked_list) # 检查该事件的执行时间和现在时间之差 # 如果值 <= 0 ，那么说明至少有一个时间事件已到达 # 如果值 > 0 ，那么说明目前没有任何时间事件到达 nearest_te_remaind_ms = te.when - now_in_ms() if nearest_te_remaind_ms <= 0: # 如果有时间事件已经到达 # 那么调用不阻塞的文件事件等待函数 poll(timeout=None) else: # 如果时间事件还没到达 # 那么阻塞的最大时间不超过 te 的到达时间 poll(timeout=nearest_te_remaind_ms) # 处理已就绪文件事件 process_file_events() # 处理已到达时间事件 process_time_event() 通过这段代码， 可以清晰地看出： - 到达时间最近的时间事件，决定了 ``poll`` 的最大阻塞时长。 - 文件事件先于时间事件处理。 将这个事件处理函数置于一个循环中， 加上初始化和清理函数， 这就构成了 Redis 服务器的主函数调用： .. code-block:: python def redis_main(): # 初始化服务器 init_server() # 一直处理事件，直到服务器关闭为止 while server_is_not_shutdown(): process_event() # 清理服务器 clean_server() 小结 ----- - Redis 的事件分为时间事件和文件事件两类。 - 文件事件分为读事件和写事件两类：读事件实现了命令请求的接收，写事件实现了命令结果的返回。 - 时间事件分为单次执行事件和循环执行事件，服务器常规操作 ``serverCron`` 就是循环事件。 - 文件事件和时间事件之间是合作关系：一种事件会等待另一种事件完成之后再执行，不会出现抢占情况。 - 时间事件的实际执行时间通常会比预定时间晚一些。