Redis：事件与事务

参考资料： 

 

《Redis的事件机制 》

《Redis 事件机制详解》

《Redis 事务》

《彻底搞懂 Redis 事务》

《事务的实现》

《Redis事务》

相关文章：

《IO 模型与多路复用》

        写在开头：本文为学习后的总结，可能有不到位的地方，错误的地方，欢迎各位指正。

目录

一、Redis事件

        1、事件分类

        2、文件事件

         Redis中的IO多路复用模型

        3、时间时间

        3.1、时间事件分类

         3.2、事件的调度与执行

二、事务

        1、定义

        2、Redis事务相关命令和使用

        MULTI：命令用于开启一个事务，它总是返回 OK 

         EXEC：命令负责触发并执行事务中的所有命令

        DISCARD：放弃事务，并清空队列，客户端退出事务状态

        WATCH：为 Redis 事务提供 check-and-set （CAS）行为

        3、Redis事务执行步骤

        4、关于回滚

         5、Redis与事务的ACID的关系

        6、管道技术

---

一、Redis事件

        1、事件分类

        Redis采用事件驱动机制来处理大量的网络IO，Redis服务器即是一个事件驱动程序，服务器需要处理两类事件：

• 文件事件（file event） - 用于处理 Redis 服务器和客户端之间的网络IO。
• 时间事件（time event） - 用于处理定时任务之类的操作。

        2、文件事件

        Redis基于Reactor模式开发了自己的网络事件处理器，也就是文件事件处理器。（建议先阅读完这篇文章《IO 模型与多路复用》）

• Redis 文件事件处理器使用 I/O 多路复用程序来同时监听多个套接字，并根据套接字目前执行的任务来为套接字关联不同的事件处理器。
• 当被监听的套接字准备好执行连接应答、读取、写入、关闭操作时，与操作相对应的文件事件就会产生，这时文件事件处理器就会调用套接字之前关联好的事件处理器来处理这些事件。

        虽然文件事件处理器以单线程方式运行，但通过使用 I/O 多路复用程序来监听多个套接字，多路复用机制使其在网络 IO 操作中能并发处理大量的客户端请求，因此文件事件处理器实现了高性能的网络通信模型。

        文件事件处理器有四个组成部分：套接字、I/O 多路复用程序、文件事件分派器、事件处理器。

        文件事件是对套接字操作的抽象，每当一个套接字准备好执行 accept、read、write和 close 等操作时，就会产生一个文件事件。因为 Redis 通常会连接多个套接字，所以多个文件事件有可能并发的出现。

        I/O多路复用程序负责监听多个套接字，并向文件事件派发器传递那些产生了事件的套接字。

        尽管多个文件事件可能会并发地出现，但I/O多路复用程序总是会将所有产生的套接字都放到同一个队列(即aeEventLoop的就绪事件表)里边，然后文件事件处理器会以有序、同步、单个套接字的方式处理该队列中的套接字，也就是处理就绪的文件事件。

         Redis中的IO多路复用模型

         在 Redis 只运行单线程的情况下，该机制允许内核中，同时存在多个监听套接字和已连接套接字。内核会一直监听这些套接字上的连接请求或数据请求。一旦有请求到达，就会交给 Redis 线程处理，这就实现了一个 Redis 线程处理多个 IO 流的效果。

        下图就是基于多路复用的 Redis IO 模型。图中的多个 FD 就是刚才所说的多个套接字。Redis 网络框架调用 epoll 机制，让内核监听这些套接字。此时，Redis 线程不会阻塞在某一个特定的监听或已连接套接字上，也就是说，不会阻塞在某一个特定的客户端请求处理上。正因为此，Redis 可以同时和多个客户端连接并处理请求，从而提升并发性。

        select/epoll 一旦监测到 FD 上有请求到达时，就会触发相应的事件。这些事件会被放进一个事件队列，Redis 单线程对该事件队列不断进行处理。这样一来，Redis 无需一直轮询是否有请求实际发生，这就可以避免造成 CPU 资源浪费。同时，Redis 在对事件队列中的事件进行处理时，会调用相应的处理函数，这就实现了基于事件的回调。因为 Redis 一直在对事件队列进行处理，所以能及时响应客户端请求，提升 Redis 的响应性能。

        例如有两个事件，Accept事件与Read 事件，Redis 分别对这两个事件注册 accept 和 get 回调函数。当 Linux 内核监听到有连接请求或读数据请求时，就会触发 Accept 事件和 Read 事件，此时，内核就会回调 Redis 相应的 accept 和 get 函数进行处理。

        3、时间时间

        3.1、时间事件分类

        时间事件又分为：

• 定时事件：让一段程序在指定的时间之后执行一次。
• 周期性事件：让一段程序每隔指定时间就执行一次。

        Redis 的时间事件的具体定义结构如下所示。

typedef struct aeTimeEvent {
    /* 全局唯一ID */
    long long id; /* time event identifier. */
    /* 秒精确的UNIX时间戳，记录时间事件到达的时间*/
    long when_sec; /* seconds */
    /* 毫秒精确的UNIX时间戳，记录时间事件到达的时间*/
    long when_ms; /* milliseconds */
    /* 时间处理器 */
    aeTimeProc *timeProc;
    /* 事件结束回调函数，析构一些资源*/
    aeEventFinalizerProc *finalizerProc;
    /* 私有数据 */
    void *clientData;
    /* 前驱节点 */
    struct aeTimeEvent *prev;
    /* 后继节点 */
    struct aeTimeEvent *next;
} aeTimeEvent;

        Redis 将所有时间事件都放在一个无序链表中，每当时间事件执行器运行时，通过遍历整个链表查找出已到达的时间事件，并调用响应的事件处理器。

         3.2、事件的调度与执行

        服务器需要不断监听文件事件的套接字才能得到待处理的文件事件，但是不能一直监听，否则时间事件无法在规定的时间内执行，因此监听时间应该根据距离现在最近的时间事件来决定。

        事件调度与执行由 aeProcessEvents 函数负责，伪代码如下：

def aeProcessEvents():

    ## 获取到达时间离当前时间最接近的时间事件
    time_event = aeSearchNearestTimer()

    ## 计算最接近的时间事件距离到达还有多少毫秒
    remaind_ms = time_event.when - unix_ts_now()

    ## 如果事件已到达，那么 remaind_ms 的值可能为负数，将它设为 0
    if remaind_ms < 0:
        remaind_ms = 0

    ## 根据 remaind_ms 的值，创建 timeval
    timeval = create_timeval_with_ms(remaind_ms)

    ## 阻塞并等待文件事件产生，最大阻塞时间由传入的 timeval 决定
    aeApiPoll(timeval)

    ## 处理所有已产生的文件事件
    procesFileEvents()

    ## 处理所有已到达的时间事件
    processTimeEvents()

        将 aeProcessEvents 函数置于一个循环里面，加上初始化和清理函数，就构成了 Redis 服务器的主函数，伪代码如下：

def main():

    ## 初始化服务器
    init_server()

    ## 一直处理事件，直到服务器关闭为止
    while server_is_not_shutdown():
        aeProcessEvents()

    ## 服务器关闭，执行清理操作
    clean_server()

        从事件处理的角度来看，服务器运行流程如下：

                

         更多的源码可以看这里的解析《aeEventLoop的具体实现》。

二、事务

        1、定义

        Redis 事务是一组命令的集合。事务支持一次执行多个命令，一个事务中所有命令都会被序列化。在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。

         Redis 提供的不是严格的事务，Redis 只保证串行执行命令，并且能保证全部执行，但是执行命令失败时并不会回滚，而是会继续执行下去。

        2、Redis事务相关命令和使用

        Redis 事务相关的命令包括MULTI 、 EXEC 、 DISCARD 和 WATCH。

• MULTI ：开启事务，redis会将后续的命令逐个放入队列中，然后使用
• EXEC命令来原子化执行这个命令系列。 EXEC：执行事务中的所有操作命令。
• DISCARD：取消事务，放弃执行事务块中的所有命令。
• WATCH：监视一个或多个key,如果事务在执行前，这个key(或多个key)被其他命令修改，则事务被中断，不会执行事务中的任何命令。
• UNWATCH：取消WATCH对所有key的监视。

        MULTI：命令用于开启一个事务，它总是返回 OK 

        MULTI 执行之后， 客户端可以继续向服务器发送任意多条命令， 这些命令不会立即被执行， 而是被放到一个队列中， 当 EXEC 命令被调用时， 所有队列中的命令才会被执行。

> MULTI
OK
> INCR foo
QUEUED
> INCR bar
QUEUED
> EXEC
1) (integer) 1
2) (integer) 1

         EXEC：命令负责触发并执行事务中的所有命令

        如果客户端在使用 MULTI 开启了一个事务之后，却因为断线而没有成功执行 EXEC ，那么事务中的所有命令都不会被执行。
        另一方面，如果客户端成功在开启事务之后执行 EXEC ，那么事务中的所有命令都会被执行。

        DISCARD：放弃事务，并清空队列，客户端退出事务状态

> SET foo 1
OK
> MULTI
OK
> INCR foo
QUEUED
> DISCARD
OK
> GET foo
"1"

        WATCH：为 Redis 事务提供 check-and-set （CAS）行为

       被 WATCH 的键会被监视，并会发觉这些键是否被改动过了。 如果有至少一个被监视的键在 EXEC 执行之前被修改了， 那么整个事务都会被取消， EXEC 返回 nil-reply 来表示事务已经失败。

WATCH mykey
val = GET mykey
val = val + 1
MULTI
SET mykey $val
EXEC

        使用上面的代码， 如果在 WATCH 执行之后， EXEC 执行之前， 有其他客户端修改了 mykey 的值， 那么当前客户端的事务就会失败。 程序需要做的， 就是不断重试这个操作， 直到没有发生碰撞为止。

        这种形式的锁被称作乐观锁， 它是一种非常强大的锁机制。 并且因为大多数情况下， 不同的客户端会访问不同的键， 碰撞的情况一般都很少， 所以通常并不需要进行重试。

        WATCH 使得 EXEC 命令需要有条件地执行：事务只能在所有被监视键都没有被修改的前提下执行，如果这个前提不能满足的话，事务就不会被执行。WATCH 命令可以被调用多次。对键的监视从 WATCH 执行之后开始生效，直到调用 EXEC 为止。

        

        3、Redis事务执行步骤

        通过上文命令执行，很显然Redis事务执行是三个阶段：

• 开启：以MULTI开始一个事务

• 入队：将多个命令入队到事务中，接到这些命令并不会立即执行，而是放到等待执行的事务队列里面

• 执行：由EXEC命令触发事务

        当一个客户端切换到事务状态之后， 服务器会根据这个客户端发来的不同命令执行不同的操作：

• 如果客户端发送的命令为 EXEC 、 DISCARD 、 WATCH 、 MULTI 四个命令的其中一个， 那么服务器立即执行这个命令。
• 与此相反， 如果客户端发送的命令是 EXEC 、 DISCARD 、 WATCH 、 MULTI 四个命令以外的其他命令， 那么服务器并不立即执行这个命令， 而是将这个命令放入一个事务队列里面， 然后向客户端返回 QUEUED 回复。

        4、关于回滚

        Redis 不支持回滚。Redis 不支持回滚的理由：

        以下是这种做法的优点：

• Redis 命令只会因为错误的语法而失败（并且这些问题不能在入队时发现），或是命令用在了错误类型的键上面：这也就是说，从实用性的角度来说，失败的命令是由编程错误造成的，而这些错误应该在开发的过程中被发现，而不应该出现在生产环境中。
• 因为不需要对回滚进行支持，所以 Redis 的内部可以保持简单且快速。

        有种观点认为 Redis 处理事务的做法会产生 bug ， 然而需要注意的是， 在通常情况下， 回滚并不能解决编程错误带来的问题。 举个例子， 如果你本来想通过 INCR 命令将键的值加上 1 ， 却不小心加上了 2 ， 又或者对错误类型的键执行了 INCR ， 回滚是没有办法处理这些情况的。

         5、Redis与事务的ACID的关系

• 原子性atomicity

        首先通过上文知道 运行期的错误是不会回滚的，很多文章由此说Redis事务违背原子性的；而官方文档认为是遵从原子性的。

        Redis官方文档给的理解是，Redis的事务是原子性的：所有的命令，要么全部执行，要么全部不执行。而不是完全成功。

• 一致性consistency

        redis事务可以保证命令失败的情况下得以回滚，数据能恢复到没有执行之前的样子，是保证一致性的，除非redis进程意外终结。

• 隔离性Isolation

        redis事务是严格遵守隔离性的，原因是redis是单进程单线程模式(v6.0之前），可以保证命令执行过程中不会被其他客户端命令打断。

        但是，Redis不像其它结构化数据库有隔离级别这种设计。

• 持久性Durability

        redis事务是不保证持久性的，这是因为redis持久化策略中不管是RDB还是AOF都是异步执行的，不保证持久性是出于对性能的考虑。

        6、管道技术

        Redis事务在MULTI命令开启后会将所有指令存储在队列中，这实际上就是基于管道实现的。

        管道技术允许请求以异步方式发送，即旧请求的应答还未返回的情况下，允许发送新请求。这种方式可以大大提高传输效率。在需要批量执行 Redis 命令时，如果一条一条执行，显然很低效。为了减少通信次数并降低延迟，可以使用 Redis 管道功能。

        简单来说就是管道允许Redis可以将多个命令打包发送，服务端收到后会将请求放到缓存队列中（占用内存），执行完毕后一次性发送结果。（注意：如果需要发送大量的命令，会占用大量的内存，因此应该按照合理数量分批次的处理）

        Redis 的管道（pipeline）功能没有提供命令行支持，但是在各种语言版本的客户端中都有相应的实现。

Pipeline pipe = conn.pipelined();
pipe.multi();
pipe.hset("login:", token, user);
pipe.zadd("recent:", timestamp, token);
if (item != null) {
    pipe.zadd("viewed:" + token, timestamp, item);
    pipe.zremrangeByRank("viewed:" + token, 0, -26);
    pipe.zincrby("viewed:", -1, item);
}
pipe.exec();