Redis学习——事务、消息订阅和发布
一、Redis事务
Redis 提供的事务机制与传统的数据库事务有些不同，传统数据库事务必须维护以下特性：原子性(Atomicity)， 一致性(Consistency)，隔离性(Isolation)，持久性(Durability)，简称ACID。
Redis支持简单的事务，将执行命令放入队列缓存，程序中有异常，执行discard回滚，其实只是取消队列命令的执行。但执行exec时，已经执行的命令，是无法回滚的。
但是Redis 的应用场景明显不是为了数据存储的高可靠而设计的，而是为了数据访问的高性能而设计，设计者为了简单性和高性能而部分放弃了原子性。
Redis的事务中，启用的是乐观锁，使用watch命令负责监控key有没有被改动过，在事务中，如果任意一个监控的key有改变，则事务取消。
Redis与 mysql事务的对比：
| Mysql | redis | |
| 开启事务 | start transaction | multi |
| 执行语句 | 普通sql (建表语句会立即执行) | 普通redis命令 |
| 失败 | rollback 回滚 | discard 取消 |
| 成功 | commit | exec |
1、模拟一个redis事务操作过程
批量操作在发送 exec 命令前被放入队列缓存，收到 exec 命令后进入事务执行
2、在mutil后面的语句中，语句出错可能有2种情况：
① 语法有问题，在exec时会报错， 所有语句得不到执行。
② 语法本身没错，但命令适用对象有问题，exec之后，会执行正确的语句，并跳过有不适当的语句。这里其实就没有真正意义上的回滚事务，这种情况只能是开发者自己避免。
3、discard 取消事务，清空队列即可，比较简单。
4、redis中的乐观锁
准备两个客户端，模拟抢票，这里设置只有一张票：
zhang客户端，准备买票，正在事务中，还没执行最终的命令：
而此时，wang这边已经把票买走了，票剩下0张
再看张这边，执行命令后，票数却剩下-1张了，这是不科学的。
所以，为了避免上面这种情况，redis中使用乐观锁来监控key有没有被改动
同样，zhang这边准备好执行命令，但在开始事务前使用watch监控ticket的变动：
之后，王这边买票成功，票剩余0张：
zhang这边再执行命令：
返回nil，说明票已被改动过，事务就取消了。
使用unwatch命令取消所有watch监听
二、消息订阅与发布
Redis 发布订阅(pub/sub)是一种消息通信模式，可以用于消息的传输，Redis的发布订阅机制包括三个部分，发布者，订阅者和Channel。适宜做在线聊天、消息推送等。
发布者和订阅者都是Redis客户端，Channel则为Redis服务器端，发布者将消息发送到某个的频道，订阅了这个频道的订阅者就能接收到这条消息，客户端可以订阅任意数量的频道
1、publish channel message：发布者向指定的频道发布消息
2、sbuscribe channel [channel2 ... n]：订阅者订阅某个或几个频道，监听channel的消息
订阅者订阅频道后，只能接收到之后发布者发布的消息
订阅后，发布者再发布消息，可以看到有一个客户端接收到消息了
3、psubscribe pattern [pattern2 .. n]：根据匹配模式订阅频道，可订阅多个匹配的频道
订阅所有redis频道
可以看到接收到匹配频道的消息
4、pubsub channels [pattern]：列出活跃的频道
5、pubsub subnum channel [channel2 .. n]：查询频道订阅者数量
