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
此时客户端的状态：
| Client | 读事件状态 | 命令发送状态 |
| A | 等待 | 未发送 |
| B | 等待 | 未发送 |
| C | 等待 | 未发送 |
后来，A向服务器发送命令请求， 并且命令请求已到达时， A的读事件状态变为就绪：
此时客户端的状态：
| Client | 读事件状态 | 命令发送状态 |
| A | 就绪 | 已发送且已到达 |
| B | 等待 | 未发送 |
| C | 等待 | 未发送 |
当事件处理器被执行时，就绪的文件事件会被识别到，相应的命令请求就会被发送到命令执行器，并对命令进行求值。
1.2 写事件
写事件标志着client对命令结果的接收状态。
和client自始至终都关联着读事件不同， server只会在有命令结果要传回给client时， 才会为client关联写事件， 并且在命令结果传送完毕之后， client和写事件的关联就会被移除。
一个写事件会在两种状态之间切换：
当server有命令结果需返回给client，但client还未能执行无阻塞写，那么写事件处等待状态
当server有命令结果需返回给client，且client可无阻塞写，那么写事件处就绪状态
当client向server发命令请求， 且请求被接受并执行后， server就需将保存在缓存内的命令执行结果返回给client， 这时server就会为client关联写事件。
示例
server正等待client A 变得可写， 从而将命令结果返回给A：
此时客户端的状态：
| Client | 读事件状态 | 写事件状态 |
| A | 等待 | 等待 |
| B | 等待 | 无 |
| C | 等待 | 无 |
当A的socket可无阻塞写时， 写事件就绪， server将保存在缓存内的命令执行结果返回给client：
| Client | 读事件状态 | 写事件状态 |
| A | 等待 | 已就绪 |
| B | 等待 | 无 |
| C | 等待 | 无 |
当命令执行结果被传回client后， client和写事件的关联会被解除（只剩读事件），返回命令执行结果的动作执行完毕，回到最初：
1.3 同时关联读/写事件
我们说过，读事件只有在client断开和server的连接时，才会被移除。即当client关联写事件时，实际上它在同时关联读/写事件。
因为在同一次文件事件处理器的调用中， 单个客户端只能执行其中一种事件（要么读，要么写，不能又读又写）， 当出现读事件和写事件同时就绪时，事件处理器优先处理读事件。
即当server有命令结果要返回client， 而client又有新命令请求进入时， server先处理新命令请求。
