随笔 - 47  文章 - 12  评论 - 431  0

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

 

 

posted on 2017-11-04 14:57  bojiangzhou  阅读(5032)  评论(1编辑  收藏