全是干货的技术号：
本文已收录在 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 设计与实现》