一. 发布/订阅命令
1.1 消息系统
发布/订阅，即pub/sub，是一种消息通信模式：发布者也称消息生产者，生产和发送消息到存储系统；订阅者也称为消息消费者，从存储系统接受和消费消息。这个存储系统可以是文件系统FS、消息中间件MQ、数据管理系统DBMS，也可以是Redis。整个消息发布者、订阅者与存储系统统称为消息系统。
消息系统中的订阅者订阅了某类消息后，只要存储系统中存在该类消息，其就可不断的接受并消费这些消息。当存储系统中没有该消息后，订阅者的接受、消费阻塞。而当发布者将消息写入到存储系统后，会立即唤醒订阅者。当存储系统放满时，不同的发布者具有不同的处理方式：有的会阻塞发布者的发布，等待可用的存储空间；有的则会将多余的消息丢失。
当然，不同的消息系统消息的发布/订阅方式也是不同的。例如RocketMQ、Kafka等消息中间件构成的消息系统中，发布/订阅的消息都是以Topic分类的。而Reids构成的消息系统中，发布/订阅的消息都是以频道Channel分类的。
1.2 subscibe
SUBSCRIBE channel [channel ...]
redis客户端通过一个subscibe命令可以同时订阅任意数量的频道。在输出了订阅了主题后，命令处于阻塞状态，等待相关频道的消息。
1.3 pubsubscibe
PSUBSCRIBE pattern [pattern ...]
订阅一个或多个符合给定模式的频道。
说明：这里的模式只能使用通配符*。例如，it*可以匹配所有以it开头的频道，像it.news、it.blog、it.tweets等；news.*可以匹配所有以news.开头的频道，像news.global.today、news.it等。
1.4 publish
PUBLISH channel message
reids 客户端将信息 message 发送到指定的频道 channel 。返回值：接收到信息 message 的订阅者数量。
1.5 unsubscibe
UNSUBSCRIBE [channel [channel ...]]
redis客户端退订给定的频道。
说明：如果没有频道被指定，也即是，一个无参数的 UNSUBSCRIBE 调用被执行，那么客户端使用 SUBSCRIBE 命令订阅的所有频道都会被退订。在这种情况下，命令会返回一个信息，告知客户端所有被退订的频道。
1.6 punsubscibe
PUNSUBSCRIBE [pattern [pattern ...]]
退订一个或多个符合给定模式的频道。
说明：这里的模式只能使用通配符*。如果没有模式被指定，也即是，一个无参数的 PUNSUBSCRIBE 调用被执行，那么客户端使用 PSUBSCRIBE 命令订阅的所有模式都会被退订。在这种情况下，命令会返回一个信息，告知客户端所有被退订的模式。
1.7 pubsub
PUBSUB <subcommand> [argument [argument ...]]
PUBSUB 是一个查看订阅与发布系统状态的内省命令， 它由数个不同格式的子命令组成， 以下将分别对这些子命令进行介绍。
（1）PUBSUB CHANNELS
PUBSUB CHANNELS [pattern]
列出当前的活跃频道（活跃的意思是有订阅者的意思）。活跃频道指的是那些至少有一个订阅者的频道， 订阅模式的客户端不计算在内。
说明：pattern 参数是可选的。如果不给出 pattern 参数，那么列出订阅/发布系统中的所有活跃频道。如果给出 pattern 参数，那么只列出和给定模式 pattern 相匹配的那些活跃频道。pattern中只能使用通配符*。
（2）PUBSUB NUMSUB
PUBSUB NUMSUB [channel-1 ... channel-N]
返回给定频道的订阅者数量， 订阅模式的客户端不计算在内。不给定任何频道，命令只返回一个空列表。
（3）PUBSUB NUMPAT
PUBSUB NUMPAT
返回订阅模式的数量，所有客户端订阅的所有频道模式的数量总和。 注意， 这个命令返回的不是订阅模式的客户端的数量， 而是客户端订阅的所有模式的数量总和。返回值为 一个整数回复（Integer reply）。
二. Redis 事务
Redis的事务的本质是一组命令的批处理。这组命令在执行过程中会被顺序地、一次性全部执行完毕，只要没有出现语法错误，这组命令在执行期间是不会被中断的。
2.1 Redis事务特性
Redis的事务仅保证了数据的一致性，不具有像DBMS一样的ACID特性。
*** 这组命令中的某些命令的执行失败不会影响其它命令的执行，不会引发回滚。即不具备原子性。
*** 这组命令通过乐观锁机制实现了简单的隔离性。没有复杂的隔离级别。
*** 这组命令的执行结果是被写入到内存的，是否持久取决于Redis的持久化策略，与事务无关。
2.2 Redis事务实现
（1）三个命令
Redis事务通过三个命令进行控制。
*** muti：开启事务。
*** exec：执行事务。
*** discard：取消事务。
（2）基本使用
下面是定义并执行事务的用法
MULTI
MULTI
标记一个事务块的开始。事务块内的多条命令会按照先后顺序被放进一个队列当中，最后由 EXEC 命令原子性(atomic)地执行。返回值，总是返回 OK 。
EXEC
EXEC
执行所有事务块内的命令。假如某个(或某些) key 正处于 WATCH 命令的监视之下，且事务块中有和这个(或这些) key 相关的命令，那么 EXEC 命令只在这个(或这些) key 没有被其他命令所改动的情况下执行并生效，否则该事务被打断(abort)。返回值：事务块内所有命令的返回值，按命令执行的先后顺序排列；当操作被打断时，返回空值 nil 。
DISCARD
DISCARD
取消事务，放弃执行事务块内的所有命令。如果正在使用 WATCH 命令监视某个(或某些) key，那么取消所有监视，等同于执行命令 UNWATCH 。返回值总是返回 OK 。
WATCH
WATCH key [key ...]
监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。返回值：总是返回 OK 。
这种又称为 Reids的乐观锁，其实现原理依赖是数据记录的版本号。
UNWATCH
UNWATCH
取消 WATCH 命令对所有 key 的监视。如果在执行 WATCH 命令之后， EXEC 命令或 DISCARD 命令先被执行了的话，那么就不需要再执行 UNWATCH 了。因为 EXEC 命令会执行事务，因此 WATCH 命令的效果已经产生了；而 DISCARD 命令在取消事务的同时也会取消所有对 key 的监视，因此这两个命令执行之后，就没有必要执行 UNWATCH 了。
（3）案例
# 事务被成功执行 redis> MULTI OK redis> INCR user_id QUEUED redis> INCR user_id QUEUED redis> INCR user_id QUEUED redis> PING QUEUED redis> EXEC 1) (integer) 1 2) (integer) 2 3) (integer) 3 4) PONG # 监视 key ，且事务成功执行 redis> WATCH lock lock_times OK redis> MULTI OK redis> SET lock "huangz" QUEUED redis> INCR lock_times QUEUED redis> EXEC 1) OK 2) (integer) 1 # 监视 key ，且事务被打断 redis> WATCH lock lock_times OK redis> MULTI OK redis> SET lock "joe" # 就在这时，另一个客户端修改了 lock_times 的值 QUEUED redis> INCR lock_times QUEUED redis> EXEC # 因为 lock_times 被修改， joe 的事务执行失败 (nil)
学习参阅声明
1.【Redis视频从入门到高级】
https://www.bilibili.com/video/BV1U24y1y7jF?p=11&vd_source=0e347fbc6c2b049143afaa5a15abfc1c】
2. 【Redis 命令参考】
https://haiyong.site/doc/redis/redis-gh-pages/hash/hscan.html