★ 事务相关的命令

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 …]]： 检查订阅/发布系统状态。

演示：redis中的基本的订阅-发布的操作