Redis学习（十）独立功能--发布订阅与事务

目录

发布与订阅

频道订阅与退订

模式的订阅与退订

发送消息

查看订阅信息

总结

事务

事务的实现

WATCH 命令的实现

事务ACID性质

总结

---

发布与订阅

Redis的发布订阅由publish、subscribe、psubscribe等命令组成。客户端通过subscribe订阅频道，发布端通过publish进行发布。

例如，a、b、c三个客户端都执行了命令subscribe“new.it”，则表示这三个客户端都监听该频道的信息。此时，如果某个客户端执行publish “new.it” “hello”，则a、b、c三个客户端都会收到该消息。

每个客户端都可以订阅多个频道，每个频道也可以给多个客户端订阅，属于多对多关系。

由于news.it频道和news.et频道都属于news.[ie]t模式，所以当消息发到news.it频道，则A、C、D三个客户端都会收到消息。

频道订阅与退订

1、订阅

当客户端执行subscribe命令，客户端和频道之间就形成订阅的关系，redis将所有频道的订阅关系放在redisServer结构体的pubsub_channels字典中，这个字典的键是被订阅的频道，值是链表，链表里面记录了所有订阅这个频道的客户端。

每当有客户端订阅频道，服务器都会将字典中的频道与客户端关联。如果频道已经有其他订阅者，则该客户端加到链表的末尾；如果频道还没有订阅者，则频道不存在于pubsub_channels字典，则会新创建一个键值对。

2、退订

unsubscribe命令是退订的命令，客户端执行此命令退订某个频道，则服务器会将键对应的链表的节点删除。另外，如果删除链表的节点后，该频道的键对应的链表是空，表示此时没有客户端定义该频道，则该键也会被删除。

模式的订阅与退订

1、订阅模式

模式的订阅与退订保存在redisServer结构体的列表pubsub_patterns中，该list是一个链表，每个节点包含一个pubsub_pattern结构，如下：

  typedef struct pubsubPattern{
                  redisClient *client;
                  robj *pattern;
  }pubsubPattern;

这个结构的 pattern 记录了订阅的模式，而 client 记录了定阅该模式的客户端。

当客户端执行psubscribe命令，即订阅某个模式，redis服务器会新建一个pubsubPattern节点，并且将client信息进行记录。

2、退订模式

punsubscribe命令是退订模式的命令。当退订模式，服务器会将客户端的信息从模式对应的pubsubPattern结构体删除。

发送消息

redis任一客户端执行publish <channel><message>，表示其发送消息，其会将消息发送给频道订阅者与模式订阅者。

1、发送给频道订阅者

由于pubsub_channels字典记录所有频道的订阅关系，则redis服务器会从频道的字典中，找到channel订阅者的名单，即一个链表，并将消息发送给其中的所有的订阅者。

2、发送给模式订阅者

由于pubsub_patterns是一个链表形式，记录所有的模式订阅者的信息，因此redis会遍历该链表，找到所有与当前channel匹配的模式，并将消息发送给这些模式的客户端。

查看订阅信息

pubsub命令可以用于查看频道的订阅情况，其共有三个子命令。

1、pubsubchannels

pubsub channels [pattern]命令用于返回服务器当前被订阅的频道，pattern参数可选，不给定参数，返回当前所有频道；给定参数，返回当前频道中与pattern模式匹配的频道。

该命令是通过遍历pubsub_channels字典，查看所有匹配的频道。

2、pubsubnumsub

pubsub numsub [channel-1 channel-2 …]子命令接收多个频道作为参数，返回这些频道订阅者的数量。

该命令是通过遍历pattern_channels字典，找到需要查阅的频道，并且返回频道对应的链表的长度。如果频道没有被订阅，则返回0。

3、pubsubnumpat

pubsub numpat返回服务器当前被订阅的模式的数量。

该命令是通过返回pubsub_patterns链表的长度来实现的。

总结

• 服务器状态在 pubsub_channels 字典保存了所有频道的订阅关系： SUBSCRIBE 命令负责将客户端和被订阅的频道关联到这个字典里面， 而 UNSUBSCRIBE 命令则负责解除客户端和被退订频道之间的关联。
• 服务器状态在 pubsub_patterns 链表保存了所有模式的订阅关系： PSUBSCRIBE 命令负责将客户端和被订阅的模式记录到这个链表中， 而 UNSUBSCRIBE 命令则负责移除客户端和被退订模式在链表中的记录。
• PUBLISH 命令通过访问 pubsub_channels 字典来向频道的所有订阅者发送消息， 通过访问 pubsub_patterns 链表来向所有匹配频道的模式的订阅者发送消息。
• PUBSUB 命令的三个子命令都是通过读取 pubsub_channels 字典和 pubsub_patterns 链表中的信息来实现的。

事务

redis的事务同数据库的事务概念一样，即多条命令都成功执行，才会生效，否则不生效。redis客户端中输入multi命令，然后中间的所有命令都不会立即生效，直到再输入exec命令。

事务的实现

一个事务从开始到结束通常会经历以下三个阶段：

1. 事务开始。
2. 命令入队。
3. 事务执行。

1、事务开始

MULTI 命令可以将执行该命令的客户端从非事务状态切换至事务状态， 这一切换是通过在客户端状态的 flags 属性中打开 REDIS_MULTI 标识来完成的。

2、命令入队

当一个客户端处于非事务状态时， 这个客户端发送的命令会立即被服务器执行：

redis> SET "name" "Practical Common Lisp"
OK

redis> GET "name"
"Practical Common Lisp"

redis> SET "author" "Peter Seibel"
OK

redis> GET "author"
"Peter Seibel"

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

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

                                       

3、事务队列

每个 Redis 客户端都有自己的事务状态， 这个事务状态保存在客户端状态的 mstate 属性里面，事务状态包含一个事务队列， 以及一个已入队命令的计数器 （也可以说是事务队列的长度）：

typedef struct multiState {

    // 事务队列，FIFO 顺序
    multiCmd *commands;

    // 已入队命令计数
    int count;

} multiState;

事务队列是一个 multiCmd 类型的数组， 数组中的每个 multiCmd 结构都保存了一个已入队命令的相关信息， 包括指向命令实现函数的指针， 命令的参数， 以及参数的数量：

typedef struct multiCmd {

    // 参数
    robj **argv;

    // 参数数量
    int argc;

    // 命令指针
    struct redisCommand *cmd;

} multiCmd;

事务队列以先进先出（FIFO）的方式保存入队的命令： 较先入队的命令会被放到数组的前面， 而较后入队的命令则会被放到数组的后面。

                

4、执行事务

当一个处于事务状态的客户端向服务器发送 EXEC 命令时， 这个 EXEC 命令将立即被服务器执行： 服务器会遍历这个客户端的事务队列， 执行队列中保存的所有命令， 最后将执行命令所得的结果全部返回给客户端。

def EXEC():

    # 创建空白的回复队列
    reply_queue = []

    # 遍历事务队列中的每个项
    # 读取命令的参数，参数的个数，以及要执行的命令
    for argv, argc, cmd in client.mstate.commands:

        # 执行命令，并取得命令的返回值
        reply = execute_command(cmd, argv, argc)

        # 将返回值追加到回复队列末尾
        reply_queue.append(reply)

    # 移除 REDIS_MULTI 标识，让客户端回到非事务状态
    client.flags &= ~REDIS_MULTI

    # 清空客户端的事务状态，包括：
    # 1）清零入队命令计数器
    # 2）释放事务队列
    client.mstate.count = 0
    release_transaction_queue(client.mstate.commands)

    # 将事务的执行结果返回给客户端
    send_reply_to_client(client, reply_queue)

WATCH 命令的实现

watch命令是一个乐观锁，可以在执行exec之前，监视任意数量数据库的键，并在执行exec时，检查监视的键是否有被修改的，如果有一个或以上的键被修改，则拒绝执行事务，客户端返回事务执行失败的空回复（nil）。

1、watch 监视

redis数据库结构体redisDB中，保存着watched_keys字典，字典的键是被watch命令监视的键，值是一个链表，记录所有监视相应数据库键的客户端。通过watch key1 key2… 即可监视键。

通过该字典，可以清楚判断哪些键被监视，以及哪些客户端监视这些键。

2、监视机制的触发

所有对数据库的键进行修改的命令，如set、lpush等，执行后都会自动调用multi.c/touchWatchKey函数，对字典watched_keys进行检查，查看是否有数据库监视该键。

如果有数据库监视该键，则将监视被修改键的所有客户端的状态REDIS_DIRTY_CAS标识打开，表示该客户端事务的安全性已经被破坏。

3、判断事务是否安全

当客户端执行exec命令时，就会判断对应自身客户端的状态是否被打开REDIS_DIRTY_CAS，如果被打开，说明至少一个键被修改，则事务不安全，redis服务器拒绝客户端提交事务，并返回nil；如果没有被打开，表示事务安全，正常执行事务。

事务ACID性质

ACID分别表示Atomicity（原子性）、Consistency（一致性）、Isolation（隔离性）、（Durability）持久性。redis的事务总是会保证ACI三个属性，在开启某些持久化方式后，也可以保证D的属性。

1、原子性

事务原子性指要么事务全部操作都执行，要么全部不执行（这里的全部执行或不执行指的是入队成功或失败，而不是真正执行）

例如redis的命令错误等，在命令入队的时候就会进行校验，如果有命令错误，则入队的时候会报错，等到执行exec时，redis则拒绝执行整个事务。

与很多关系型数据库不同，redis不支持事务的回滚，因为redis的作者认为事务出错只有在开发环境中会有，生产环境没有。而回滚会导致redis代码复杂，与设计初衷不符。

2、一致性

事务的一致性指事务执行前后，数据库是一致的，无论事务是否执行成功。一致指数据库的数据符号数据库本身定义和要求，没有非法、无效数据。

redis在三个地方进行校验：

1）入队出错

命令不存在或命令格式错误等，表示入队出错，redis会拒绝执行事务。

2）执行错误

事务执行过程中可能会发生错误，这些错误是在入队的时候无法发现的错误。在执行中发生的错误，不会中断事务，事务会继续进行。对数据库键进行错误类型操作是最常发生的执行错误。

错误的命令会被服务器报出，并且不会将错误的命令进行执行，保证数据一致性。

3）服务器停机

如果redis事务执行期间发生服务器停机，则根据redis的持久化的方案，会发生以下不同的情况：

1. 无持久化，则没有保存任何数据，数据是一致的。

2. rdb或aof持久化，则可以根据rdb或aof文件进行回复，不会发生数据不一致。如果无文件，则无法恢复数据，但数据仍是一致性的。

3、隔离性

隔离性是指多个事务并发进行，各个事务不会互相影响，并且并发状态下执行事务与串行状态下执行事务结果完全相同。

由于redis是单线程执行事务，且服务器保证事务执行期间不会有其他命令插入，因此redis的命令总是串行执行的，保证隔离性。

4、持久性

事务耐久性是指一个事务执行完毕后，事务的结果被保存在磁盘里，后面及时服务器停机，数据仍存在。

由于redis的事务只是对一组命令进行包裹，并没有附带持久化的命令，因此redis事务的持久化与否取决于redis服务器配置的持久化策略。

只有redis在aof持久化状态下，且appendfsync选项的值设置为always，程序才会每次将命令的结果实时强制同步到磁盘中，redis的事务才有真正的耐久性，其他情况下的redis事务不具有耐久性。

虽然可以在执行exec之前，输入一个save命令，强制全磁盘保存，保证事务的耐久性，但是由于save是阻塞的，效率极低，因此不具有实用性。

总结

• 事务提供了一种将多个命令打包， 然后一次性、有序地执行的机制。
• 多个命令会被入队到事务队列中， 然后按先进先出（FIFO）的顺序执行。
• 事务在执行过程中不会被中断， 当事务队列中的所有命令都被执行完毕之后， 事务才会结束。
• 带有 WATCH 命令的事务会将客户端和被监视的键在数据库的 watched_keys 字典中进行关联， 当键被修改时， 程序会将所有监视被修改键的客户端的 REDIS_DIRTY_CAS 标志打开。
• 只有在客户端的 REDIS_DIRTY_CAS 标志未被打开时， 服务器才会执行客户端提交的事务， 否则的话， 服务器将拒绝执行客户端提交的事务。
• Redis 的事务总是保证 ACID 中的原子性、一致性和隔离性， 当服务器运行在 AOF 持久化模式下， 并且 appendfsync 选项的值为 always 时， 事务也具有耐久性。

 

 

 

参考文章：

《Redis设计与实现》