★ 事务相关的命令
Redis事务保证事务内的多条命令会按顺序作为整体执行，其他客户端发出的请求绝不可能被插入到事务处理的中间，
这样可以保证事务内所有命令作为一个隔离操作被执行。
Redis事务同样具有原子性，事务内所有命令要么全部被执行，要么全部被放弃。
比如事务执行过程中遇到数据库宕机，Redis会自动回滚这些已经执行过的命令。
需要说明的是，某条命令执行出现错误并不会影响事务提交。（这句下面会演示）
▲ 事务相关的常用命令如下：
DISCARD： 取消事务，放弃执行事务块内的所有命令。
MULTI： 开启事务
EXEC： 执行事务
WATCH key [key …]： 监视一个或多个key，如果在事务exec之前这些key对应的值被其他命令改动，事务会自动中断。
UNWATCH： 取消WATCH命令对所有key的监视。
【注意】 WATCH命令 必须在事务开启之前执行。
演示Redis的事务
一个简单的事务演示：
某条命令执行出现错误并不会影响事务提交
如图：这个事务一共有3条命令操作，其中有一条命令是错误的，会执行失败，但是不影响事务提交。
演示两个事务之间的操作：
情景：
甲事务要修改Redis中 A key所对应数据，甲事务在执行的过程中肯定会对A key所对应数据加锁，
等待事务结束才会释放对A key的加锁。
因此在甲事务在对A key所对应数据的修改过程中，其他进程肯定无法修改A key对应的value。
但试想一下，A key的value依赖于B key的value，
甲事务对A key的value所修改必须以B key所对应的value为基础。
换而言之，如果B key所对应的value已经被其他进程修改了，
那么甲事务对A key的value所修改应该自动撤销。
此时就可以在甲事务开始之前，使用WATCH命令来监视B key，
这样当B key所对应的value发生修改后，甲事务自动撤销。
【注意】WATCH命令必须在事务开始之前执行。
比如 watch keyB # 指定当keyB对应的value在其他命令修改之后，
当前进程中事务所做的修改就会自动撤销。
演示：先演示 keyA 和 keyB 没啥关系的情况下的事务执行。
先添加两个 key-value对，
然后开始事务
修改 keyA 的value值
然后这时候再开启一个redis。
可以看出修改keyB的事务，对修改keyA的事务并没有什么影响。
但是如果 keyA 和 keyB 有关联的话，我们要的效果应该是当 keyB 被修改过后，那么修改keyA的操作将失败才合理。
现在演示：
假设keyA是依赖keyB的，所以只要keyB在其他线程发生修改，那keyA这边的事务就会被撤销。
UNWATCH： 取消WATCH命令对所有key的监视。
测试：这个watch 的监视的作用时间，在上一个事务执行完成后，就失效了，我重新开一个事务，就没有再监视keyB了。
测试在事务的执行过程中能否去掉对key的监视。
结论：对keyB的监视作用还在，所以说明这个去掉监视的命令，
不能在事务中执行
再测试一遍，在事务开启前取消对key的监视
结论：表明这个取消对key监视的命令，需要在事务开启前执行
★ 发布订阅相关的命令：
Redis内置支持发布/订阅的消息机制，消息订阅者可以订阅一个或多个channel，
每个channel也可被多个消息订阅者订阅。只要消息发布者向某个channel发布消息，
该消息就会同时被该channel的多个消息订阅者收到。
发布/订阅相关的常用命令如下：
SUBSCRIBE channel [channel …]： 订阅一个或多个channel。
UNSUBSCRIBE [channel [channel …]]： 取消订阅一个或多个channel，如果不带参数，表明取消订阅所有channel。
PSUBSCRIBE pattern [pattern …]： 按模式匹配的方式订阅一个或多个channel。
PUNSUBSCRIBE [pattern [pattern …]]： 按模式匹配的方式取消订阅一个或多个channel，如果不带参数，表明取消订阅所有channel。
PUBLISH channel message： 向指定channel发布消息。
PUBSUB subcommand [argument [argument …]]： 检查订阅/发布系统状态。文章来源：https://uudwc.com/A/Ev0jD
演示：redis中的基本的订阅-发布的操作
文章来源地址https://uudwc.com/A/Ev0jD
