文章目录
1.Redis事务的定义
Redis事务是一个单独的隔离操作,事务中的所有命令都会序列化,然后按照顺序地执行。事务在执行的过程中,不会被其他客户端发送来的命令请求所打断。
1.1.Redis事务的特点
- **单独隔离操作:**事务中所有命令都会序列化按顺序的执行。事务在执行过程中不会被其他客户端发送来的命令请求打断。
- **没有隔离级别的概念:**事务在提交前,任何指令都不会被执行
- **不保证原子性:**食物中如果有一条命令执行失败,其他命令依旧会执行,不会整体回滚。
2.事务的命令(Multi / Discard / Exec )
2.1.Multi
Multi指令标识一个事务的开始,后续指令进入事务队列等待被执行。
在开始事务组队后输入的某个指令出现报错,则整个事务队列都会被作废
正确输入时:
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set k1 1
QUEUED
127.0.0.1:6379(TX)> set k2 22
QUEUED
127.0.0.1:6379(TX)> set k3 333
QUEUED
127.0.0.1:6379(TX)> exec
1) OK
2) OK
3) OK
报错时:
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set k1 abc
QUEUED
127.0.0.1:6379(TX)> set k2
(error) ERR wrong number of arguments for 'set' command
2.2.Discard
在命令组队阶段可以执行 discard 命令,放弃在组队的事务,对于已经存在缓存队列中的命令不会执行全部作废,关闭当前事务
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set k1 11
QUEUED
127.0.0.1:6379(TX)> set k2 22
QUEUED
127.0.0.1:6379(TX)> discard
OK
127.0.0.1:6379>
2.3.Exec
执行事务队列中的命令
只有出现错误的命令不执行,其他任务都执行
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set k1 v1
QUEUED
127.0.0.1:6379(TX)> set k2 v2
QUEUED
127.0.0.1:6379(TX)> set k3 v3
QUEUED
127.0.0.1:6379(TX)> incr k1
QUEUED
127.0.0.1:6379(TX)> exec
1) OK
2) OK
3) OK
4) (error) ERR value is not an integer or out of range
3.乐观锁(WATCH)和悲观锁(UNWATCH)
3.1.乐观锁(WATCH)
乐观锁(Optimistic Lock),
顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制。乐观锁适用于多读的应用类型,这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。
在执行multi命令之前,可以先执行WATCH key (监视一个或者多个key),如果在事务执行之前watch监视的一个或者多个key被其他命令改动,那么事务将会被打断,有点类似我们上面介绍的乐观锁
3.2.悲观锁(UNWATCH)
悲观锁(Pessimistic Lock),
顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁。
但是在效率方面,处理加锁的机制会产生额外的开销,还有增加产生死锁的机会。另外还会降低并行性,如果已经锁定了一个线程A,其他线程就必须等待该线程A处理完才可以处理。
取消 WATCH 命令对所有 key 的监视,如果在执行 WATCH 命令之后,EXEC 命令或DISCARD 命令先被执行了的话,那么就不需要再执行UNWATCH 了。