redis设计与实现-事件

事件

事件是 Redis 服务器的核心， 它处理两项重要的任务：

文件事件(file event)：在多个客户端中实现多路复用，接受它们发来的命令请求，并将命令的执行结果>返回给客户端。
时间事件(time event)：实现服务器常规操作（server cron job）。

文件事件

Redis 服务器通过在多个客户端之间进行多路复用， 从而实现高效的命令请求处理： 多个客户端通过套接字连接到 Redis 服务器中， 但只有在套接字可以无阻塞地进行读或者写时， 服务器才会和这些客户端进行交互。

Redis 将这类因为对套接字进行多路复用而产生的事件称为文件事件（file event）， 文件事件可以分为读事件和写事件两类。

多路复用产生的套接字都放到一个队列中。以有序，同步方式向文件事件分派器发送套接字

读事件

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

当一个新的客户端连接到服务器时， 服务器会给为该客户端绑定读事件， 直到客户端断开连接之后， 这个读事件才会被移除。

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

当客户端只是连接到服务器，但并没有向服务器发送命令时，该客户端的读事件就处于等待状态。
当客户端给服务器发送命令请求，并且请求已到达时（相应的套接字可以无阻塞地执行读操作），该客户端的读事件处于就绪状态。
当事件处理器被执行时， 就绪的文件事件会被识别到， 相应的命令请求会被发送到命令执行器， 并对命令进行求值。

写事件

写事件标志着客户端对命令结果的接收状态。

和客户端自始至终都关联着读事件不同， 服务器只会在有命令结果要传回给客户端时， 才会为客户端关联写事件， 并且在命令结果传送完毕之后， 客户端和写事件的关联就会被移除。

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

当服务器有命令结果需要返回给客户端，但客户端还未能执行无阻塞写，那么写事件处于等待状态。
当服务器有命令结果需要返回给客户端，并且客户端可以进行无阻塞写，那么写事件处于就绪状态。
当客户端向服务器发送命令请求， 并且请求被接受并执行之后， 服务器就需要将保存在缓存内的命令执行结果返回给客户端， 这时服务器就会为客户端关联写事件。

同时关联写事件和读事件
前面提到过，读事件只有在客户端断开和服务器的连接时，才会被移除。

这也就是说，当客户端关联写事件的时候，实际上它在同时关联读/写两种事件。

因为在同一次文件事件处理器的调用中， 单个客户端只能执行其中一种事件（要么读，要么写，但不能又读又写）， 当出现读事件和写事件同时就绪的情况时， 事件处理器优先处理读事件。这也就是说， 当服务器有命令结果要返回客户端， 而客户端又有新命令请求进入时， 服务器先处理新命令请求。

时间事件

时间事件记录着那些要在指定时间点运行的事件， 多个时间事件以无序链表的形式保存在服务器状态中。

redis时间事件分为2类：

定时事件：在指定时间之后，执行一次。
周期性事件：每隔一段时间就执行一次。
每个时间事件主要由以下几个属性组成：

id：全局唯一ID，新事件ID号比旧事件ID号大。
when ：以毫秒格式的 UNIX 时间戳为单位，记录了应该在什么时间点执行事件处理函数。
timeProc ：事件处理函数。
next 指向下一个时间事件，形成链表。
根据 timeProc 函数的返回值，可以将时间事件划分为两类：

如果事件处理函数返回 ae.h/AE_NOMORE ，那么这个事件为单次执行事件：该事件会在指定的时间被处理一次，之后该事件就会被删除，不再执行。
如果事件处理函数返回一个非 AE_NOMORE 的整数值，那么这个事件为循环执行事件：该事件会在指定的时间被处理，之后它会按照事件处理函数的返回值，更新事件的 when 属性，让这个事件在之后的某个时间点再次运行，并以这种方式一直更新并运行下去。
实现
服务器将所有时间事件都放在一个无序列表中，每当时间事件执行器运行时，就遍历列表，查找所有已到达时间事件，并调用相应事件处理器。无序列表不是指不按ID排序，是指不按when排序。

无序链表并不影响时间事件处理器的性能

在目前的版本中， 正常模式下的 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 里面的两种事件呈合作关系， 它们之间包含以下三种属性：

一种事件会等待另一种事件执行完毕之后，才开始执行，事件之间不会出现抢占。
事件处理器先处理文件事件（处理命令请求），再执行时间事件（调用 serverCron）
文件事件的等待时间（类 poll 函数的最大阻塞时间），由距离到达时间最短的时间事件决定。
这些属性表明， 实际处理时间事件的时间， 通常会比时间事件所预定的时间要晚， 至于延迟的时间有多长， 取决于时间事件执行之前， 执行文件事件所消耗的时间。