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]：查询频道订阅者数量