Redis事件处理机制详解（下）

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()