目录
发布与订阅
频道订阅与退订
模式的订阅与退订
发送消息
查看订阅信息
总结
事务
事务的实现
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
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 命令则负责移除客户端和被退订模式在链表中的记录。pubsub_channels
字典来向频道的所有订阅者发送消息, 通过访问 pubsub_patterns
链表来向所有匹配频道的模式的订阅者发送消息。pubsub_channels
字典和 pubsub_patterns
链表中的信息来实现的。redis的事务同数据库的事务概念一样,即多条命令都成功执行,才会生效,否则不生效。redis客户端中输入multi命令,然后中间的所有命令都不会立即生效,直到再输入exec命令。
一个事务从开始到结束通常会经历以下三个阶段:
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"
与此不同的是, 当一个客户端切换到事务状态之后, 服务器会根据这个客户端发来的不同命令执行不同的操作:
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命令是一个乐观锁,可以在执行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分别表示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是阻塞的,效率极低,因此不具有实用性。
watched_keys
字典中进行关联, 当键被修改时, 程序会将所有监视被修改键的客户端的 REDIS_DIRTY_CAS
标志打开。REDIS_DIRTY_CAS
标志未被打开时, 服务器才会执行客户端提交的事务, 否则的话, 服务器将拒绝执行客户端提交的事务。appendfsync
选项的值为 always
时, 事务也具有耐久性。
参考文章:
《Redis设计与实现》