全是干货的技术号：
本文已收录在github，欢送 star/fork：
https://github.com/Wasabi1234...

Redis 服务器的事件次要解决两方面：

• 解决文件事件：在多个客户端中实现多路复用，承受它们发来的命令申请，并将命令的执行后果返回给客户端
• 工夫事件：实现服务器惯例操作

1 文件事件

Redis server通过在多个客户端间多路复用， 实现了高效的命令申请解决： 多个客户端通过socket连贯到 Redis server， 但只有在socket可无阻塞读/写时， server才会和这些客户端交互。

Redis 将这类因为对socket进行多路复用而产生的事件称为文件事件， 文件事件可分类如下：

1.1 读事件

读事件标记着客户端命令申请的发送状态。

当一个新的client连贯到服务器时， server会给该client绑定读事件， 直到client断开连接后， 该读事件才会被移除。

读事件在整个网络连接的生命期内， 都会在期待和就绪两种状态之间切换：

• 当client只是连贯到server，但并未向server发送命令时，该客户端的读事件就处于期待状态
• 当client给server发送命令申请，并且申请已达到时（相应的套接字能够无阻塞地执行读操作），该client的读事件处于就绪状态。

示例

如图展现三个已连贯到server、但并未发命令的client

此时客户端的状态：

起初，A向服务器发送命令申请， 并且命令申请已达到时， A的读事件状态变为就绪：

此时客户端的状态：

当事件处理器被执行时，就绪的文件事件会被辨认到，相应的命令申请就会被发送到命令执行器，并对命令进行求值。

1.2 写事件

写事件标记着client对命令后果的接管状态。

和client从头至尾都关联着读事件不同， server只会在有命令后果要传回给client时， 才会为client关联写事件， 并且在命令后果传送结束之后， client和写事件的关联就会被移除。

一个写事件会在两种状态之间切换：

• 当server有命令后果需返回给client，但client还未能执行无阻塞写，那么写事件处期待状态
• 当server有命令后果需返回给client，且client可无阻塞写，那么写事件处就绪状态

当client向server发命令申请， 且申请被承受并执行后， server就需将保留在缓存内的命令执行后果返回给client， 这时server就会为client关联写事件。

示例

server正等待client A 变得可写， 从而将命令后果返回给A：

此时客户端的状态：

当A的socket可无阻塞写时， 写事件就绪， server将保留在缓存内的命令执行后果返回给client：

此时client状态：

当命令执行后果被传回client后， client和写事件的关联会被解除（只剩读事件），返回命令执行后果的动作执行结束，回到最后：

1.3 同时关联读/写事件

咱们说过，读事件只有在client断开和server的连贯时，才会被移除。即当client关联写事件时，实际上它在同时关联读/写事件。

因为在同一次文件事件处理器的调用中， 单个客户端只能执行其中一种事件（要么读，要么写，不能又读又写）， 当呈现读事件和写事件同时就绪时，事件处理器优先解决读事件。

即当server有命令后果要返回client， 而client又有新命令申请进入时， server先解决新命令申请。

2 工夫事件

工夫事件记录着那些要在指定工夫点运行的事件，多个工夫事件以无序链表构造保留在服务器状态中。

无序链表并不影响工夫事件处理器的性能。
在Redis3.0版本，失常模式下的 Redis 只带有 serverCron 一个工夫事件， 而在 benchmark 模式下， Redis 也只应用两个工夫事件。
在这种状况下， 程序简直是将无序链表进化成一个指针来应用， 所以应用无序链表来保留工夫事件， 并不影响事件处理器性能。

• 工夫事件的数据结构

依据 timeProc 函数返回值，将工夫事件分类如下：

• 返回 AE_NOMORE

那么这个事件为单次执行事件。该事件会在指定工夫被解决一次，之后该事件就会被删除

• 返回一个非 AE_NOMORE 的整数值，则为循环执行事件。该事件会在指定工夫被解决，之后它会依照timeProc的返回值，更新事件的 when 属性，让这个事件在之后某工夫点再运行，以这种形式始终更新运行。

伪代码示意的两种事件处理：

def handle_time_event(server, time_event):    # 执行事件处理器，并获取返回值    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 属性，并执行已达到事件：

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)

工夫事件实例

服务器须要定期对本身的资源和状态进行查看、整顿， 保障服务器维持在一个衰弱稳固状态， 这类操作被统称为惯例操作（cron job）。

在 Redis 中， 惯例操作由 redis.c/serverCron 实现， 包含如下操作：

• 更新服务器的各类统计信息，比方工夫、内存占用、数据库占用状况等
• 清理数据库中的过期键值对
• 对不合理的数据库进行大小调整
• 敞开和清理连贯生效的客户端
• 尝试进行 AOF 或 RDB 长久化操作
• 如果服务器是主节点的话，对从属节点进行定期同步
• 如果处于集群模式的话，对集群进行定期同步和连贯测试

Redis 将 serverCron（后文简称为sC） 作为工夫事件运行， 确保它可能定期主动运行一次，又因 sC 须要在 Redis 服务器运行期始终定期运行， 所以它是一个循环工夫事件：sC 会始终定期执行，直至服务器敞开。

Redis 2.6 的 sC 每秒运行 10 次，即均匀每 100 ms运行一次。
Redis 2.8 用户能够通过批改 hz 选项设置 sC 的每秒执行次数。

3 两种事件的调度

简略地说， Redis 外面的两种事件呈协作关系， 它们之间蕴含如下属性：

• 一种事件会期待另一种事件执行完后，才开始执行，事件之间不会呈现抢占
• 事件处理器先解决文件事件（即解决命令申请），再执行工夫事件（调用 sC）
• 文件事件的等待时间（类 poll 函数的最大阻塞工夫），由间隔达到工夫最短的工夫事件决定

这表明， 理论解决工夫事件的工夫， 通常会比事件所预约的工夫要晚， 延迟时间取决于工夫事件执行前， 执行实现文件事件所耗时间。

示例

惯例案例

尽管工夫事件 Time Event Y 可设置其when属性打算在 t1 工夫执行， 但因为文件事件 File Event X 正在运行， 所以 Time Event Y 的执行被提早。

sC 案例

而且对于 sC 这类循环执行的工夫事件来说，如果事件处理器的返回值是 t ，那么 Redis 只保障：

• 如果两次执行工夫事件处理器之间的工夫距离≥t ，则该工夫事件至多会被解决一次
• 而非，每隔 t 工夫，就肯定要执行一次事件

这对于不应用抢占调度的 Redis 事件处理器而言，也不可能做到

比方，尽管 sC 设定的距离为 10 ms，但它并非是如下那样每隔 10 ms就运行一次：

理论的 sC 运行形式更可能如下：

依据状况，如果解决文件事件消耗了十分多的工夫，sC 被推延到一两秒之后能力执行，也有可能。
整个事件处理器程序能够用以下伪代码形容：

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 服务器的主
函数调用：

def redis_main():    # 初始化服务器    init_server()        # 始终处理事件，直到服务器敞开为止    while server_is_not_shutdown():        process_event()        # 清理服务器    clean_server()

参考

• 《Redis 设计与实现》