一、是什么
- 可以一次执行多个命令,本质是一组命令的集合。一个事务中的所有命令都会被序列化,按顺序的串行化执行而不会被其他命令插入,不许加塞
- 一个队列中,一次性、顺序性、排他性的执行一系列命令
二、怎么玩?
1、常用命令
discard
:取消事务,放弃执行事务块内的所有命令exec
:执行所有事务块内的命令multi
:标记一个事务块的开始unwatch
:取消 watch 命令对所有 key 的监视watch key1 [key2…]
:监视一个或多个 key,如果在事务执行之前这个(或这些)key 被其他命令所改动,那么事务将被打断
2、情况分类:
- 正常执行:即 multi 之后都是正常命令
- 放弃事务:即 multi 之后,没有 exec,而使用了 discard,则放弃了之前所有的操作
- 全体连坐:即 multi 之后,只要出现一条错误命令,还没 exec,在加入队列时就出错了,则全部不会执行,eg:
multi set k1 v1 set k2 v2 getset k3 #(此处就是错误命令,加入队列时就会出现错误) exec # 该情况全部不会执行
- 冤头债主:即 multi 之后,命令都是正确的,加入队列时没有出错,但会有类型转换失败,则在 exec 之后,只有类型不一致那个没有执行成功,其他的都会执行成功,eg:
multi set k1 aa set k2 v2 incr k1 #(加入队列不会出现错误,但执行时会类型转换失败) set k3 v3 set k4 v4 exec # 该情况除了 incr k1 这条没有执行成功之外,其他的都执行成功了
3、watch 监控
- 悲观锁和乐观锁
(1) 悲观锁:(Pessimistic Lock),顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会 block 直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,
读锁,写锁等,都是在做操作之前先上锁
(2) 乐观锁:(Optimistic Lock),顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制。乐观锁适用于多读的应用类型,这样可以提高
吞吐量;乐观锁策略:提交版本必须大于记录当前版本才能执行更新
(3) CAS(Check And Set) - unwatch:当监控之后,发现有人修改了该值,则应取消监控,再重新监控
- 一旦执行了 exec,之前加的监控锁都会被取消掉了
三、3 阶段
- 开启:以 multi 开始一个事务
- 入队:将多个命令入队到事务中,接到这些命令并不会立即执行,而是放到等待执行的事务队列里面
- 执行:由 exec 命令触发事务
四、3 特性
- 单独的隔离操作:事务中的所有命令都会序列化、按顺序地执行。事务在执行过程中,不会被其他客户端发送来的命令请求所打断
- 没有隔离级别的概念:队列中的命令里没有提交之前都不会实际的被执行,因为事务提交前任何指令都不会被实际执行,也就不存在“事务内的查询要看到事务里的更新,在事务外查询不能看到”这个让人万分头痛的问题
- 不保证原子性:Redis 同一个事务中如果有一条命令执行失败,其后的命令仍然会被执行,没有回滚,所以说 Redis 是部分支持事务
五、Redis 的消息发布订阅(了解)
- 是什么:进程间的一种消息通信模式:发送者(pub)发送消息,订阅者(sub)接收消息
- 命令
(1)psubscribe pattern [pattern2…]
:订阅一个或多个符合给定模式的频道
(2)pubsub subcommand [argument [argument2…]]
:查看订阅与发布系统状态
(3)publish channel message
:将信息发送到指定的频道
(4)punsubscribe pattern [pattern2…]
:退订所有给定模式的频道
(5)subscribe channel [channel2…]
:订阅给定的一个或多个频道的信息
(6)unsubscribe [channel [channel2…]]
:指退订给定的频道 - 案例:先订阅后发布后才能收到消息
(1) 可以一次性订阅多个:subscribe c1 c2 c3
(2) 消息发布:publish c2 hello-redis
,订阅的一端就会立即收到
(3) 订阅多个,通配符 *,psubscribe new*
(4) 消息发布:publish new1 redis2015
,订阅的一端就会立即收到