独立功能的实现
十八、发布和订阅
发布和订阅由下面几条命令组成
- PUBLISH，发布消息，例如PUBLISH <频道名> <消息内容>
- SUBSCRIBE，订阅某个频道 SUBSCRIBE <频道名>
- UNSUBSCRIBE 退订某个频道
- PSUBSCRIBE，订阅某个模式频道，例如news.* PSUBSCRIBE <模式频道名>
- PUNSUBSCRIBE，退订某个模式频道
数据结构
- redisServer
- dict *pubsub_channels key是频道名，value是一个链表，保存所有订阅这个频道的客户端
- list *pubsub_patterns 链表，值是pubsub_pattern对象，保存客户端和模式频道
操作
- 订阅频道。例如命令 SUBSCRIBE news.it
- 查看pubsub_channels 字典是否有news.it这个key，如果有，把客户端添加到链表后面，如果没有，新建一个链表，设置news.it这个key指向这个链表
- 退订频道。例如命令 UNSUBSCRIBE news.it
- 找到news.it对应的链表，遍历链表，找出当前客户端，然后删除
- 订阅模式频道。例如命令 PSUBSCRIBE news.*
- 在pubsub_patterns 链表后面添加一个pubsub_pattern对象，保存这个客户端的信息和news.*
- 退订模式频道。例如命令 PUNSUBSCRIBE news.*
- 遍历pubsub_patterns 链表，删除客户端等于当前客户端，模式等于news.*的对象
- 发布消息，例如 PUBLISH news.it news11
- 遍历pubsub_channels[news11]链表，把消息发送给链表中的所有客户端
- 遍历pubsub_patterns链表，如果模式和news11匹配，就发送消息给对应的客户端
其他命令
这些命令是2.8后新增的
- PUBSUB CHANNELS [pattern] 模式是可选的
- 如果没有pattern 返回服务端所有被订阅的频道
- 如果有，返回匹配上pattern的所有频道
- PUBSUB NUMSUB [channel-1 channel-2 。。。] 可以输入多个频道
- 返回每个频道的订阅者数量，也就是pubsub_channels[channel-1]链表的长度
- PUBSUB NUMPAT
- 返回服务端当前被订阅的模式频道数量,也就是pubsub_patterns 链表的长度。
十九、事务
Redis通过MULTI EXEC WATCH命令来实现事务
事务例子
MULTI
get test
set test 111
EXEC
数据结构
- redisClient 客户端对象
- multiState mstate 事务状态
- multiState 事务状态对象
- multiCMD *commands 保存改事务下面的所有命令FIFO原则
- int count 已入队的命令数量
- multiCmd 命令对象
- robj **argv 命令参数
- int argc 参数数量
- struct redisCommand * cmd 命令对象
流程
- 当执行MULTI命令，改客户端进入事务模式。会打开客户端对象的flags属性的REDIS_MULTI标识
- 当执行get和set命令，会把这些命令的信息加入到commands队列。但是不会立刻执行
- 当执行EXEC命令。服务端把客户端的commands命令拿出来，逐条执行，然后返回每条的结果
- 在MULTI和EXEC命令之间的所有命令，都不会立刻执行。
- 执行完EXEC命令后，清空客户端对象的事务状态，包括flags标识，multiState对象等
WATCH命令
WATCH命令是一个乐观锁，可以在EXEC命令开始前监视任意数量的数据库键。
例如事务
WATCH name
MULTI
set name kevinlu
EXEC
如果在WATCH后，EXEC前，name这个键被修改了，执行EXEC后，会返回空给客户端。
实现：
- redisDb的对象的dict *watched_keys变量用于保存当前watch命令的所有key和客户端对象。key是数据库的键，value是链表，值是客户端对象
- 当执行WATCH命令，Redis会在watched_keys加上数据
- 当Redis执行修改命令时，会执行touchWatchKey操作。具体就是在watched_keys找出修改的key的链表，对链表中的所有客户端对象，打开客户端的REDIS_DIRTY_CAS标识，表示这些客户端WATCH的key中至少有一个被修改了
- 当客户端执行EXEC命令时，检查REDIS_DIRTY_CAS标识是否被打开，如果是，返回空。否则才执行事务。
事务性质（ACID）
- A 原子性。因为Redis把事务打包在一起执行，所以是具有原子性的。要不成功，要不失败。但是Redis不会有事务回滚，也就是例如第2条命令失败了，第1条命令不会回滚，第3条命令也会继续执行。作者是命令回滚太复杂，不适合Redis的简单原则。
- C 一致性。事务执行前和执行后都能保证一致性。一致性是指不会破坏数据库的设计（这个好笼统，不知道具体的边界）。Redis的命令执行错误主要有两种：
- 入队错误。例如命令不存在。这个在EXEC前就会被发现并被Redis拒绝。所以这个不会破坏一致性。
- 执行错误。命令执行的时候错误了，例如key是string类型，却用rpush操作。对于这种错误，Redis不会终止事务的执行，也不会回滚。所以这些命令不会执行，所以也不会破坏一致性（不太明白这个，都有一个条命令执行失败了，怎么会不破坏一致性？）
- 数据库停机。如果不保存数据，那一致性就不用考虑了，因为重启后都是空白数据库。如果保存数据，事务会落地，所以也能保证一致性
- I 隔离性。由于Redis是单线程执行，所以不会有事务并发问题。所以可以保证隔离性。
- D 耐久性。事务执行成功后保证可以持久化到数据库。由于Redis在执行指定命令，例如BGSAVE的时候，才会进行持久化，所以不能保证耐久性。
- 可以使用AOF 设置appendfsync来保证耐久性