Redis篇5-redis事务

Posted 2022-10-13 noodlerkun

概述

• 官方说明：https://redis.io/topics/transactions
• redis“部分”支持事务（部分回滚）
• 关键命令
  • MULTI 开始事务
  • EXEC 开始执行事务内命令s
  • DISCARD 取消事务并放弃事务内命令s的执行
  • WATCH 监视一个或多个key，开始乐观锁CAS的事务操作
  • UNWATCH 取消所有key监视
• 从Redis2.2开始支持用于乐观锁的check-and-set (CAS)

---

开始使用

multi-exec正常提交

mset k1 v1 k2 v2 k3 v3
multi
set k1 vv1
get k1
set k4 v4 
get k4
exec
keys *

multi-exec异常1-注意

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k5 v5
QUEUED
127.0.0.1:6379> set k1 11 12
QUEUED
127.0.0.1:6379> exec
1) OK
2) (error) ERR syntax error
127.0.0.1:6379> get k5
"v5"
127.0.0.1:6379> get k1
"vv1"
127.0.0.1:6379> keys *
1) "k5"
2) "k1"
3) "k2"
4) "k3"
5) "k4"

可以看出，multi后加入事务命令OK，但exec执行时出错时，并没有全部回滚。。

multi-exec异常2-说redis“部分支持事务”的原因

127.0.0.1:6379> flushdb
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> getset k3
(error) ERR wrong number of arguments for 'getset' command
127.0.0.1:6379> getset k3 v3
QUEUED
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> keys *
(empty list or set)

可以看出，exec之前出错，整个事务回滚，即DISCARD。

主动 DISCARD

127.0.0.1:6379> flushdb
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> get k2
QUEUED
127.0.0.1:6379> discard
OK
127.0.0.1:6379> keys *
(empty list or set)

discard比较好理解，就是主动退出/回滚事务，取消命令的执行。

乐观锁-WATCH-CAS

• 乐观锁一般相对于悲观锁理解，优点是不阻塞，缺点是失败率变高
• 事务开始前（multi），watch目标key，如果提交前目标key被其他会话改动（即CAS过程），则事务回滚（DISCARD）
• client1，session1

127.0.0.1:6379> get k1
"vv1"
127.0.0.1:6379> watch k1
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k1 0v1
QUEUED
127.0.0.1:6379> get k1 
QUEUED
127.0.0.1:6379> exec
(nil)
127.0.0.1:6379> get k1
"v1"
127.0.0.1:6379> get k1
"v1"
127.0.0.1:6379> get k2
"v2"
127.0.0.1:6379> watch k1
OK
127.0.0.1:6379> multi 
OK
127.0.0.1:6379> set k1 vv1
QUEUED
127.0.0.1:6379> set k2 vv2
QUEUED
127.0.0.1:6379> exec
(nil)
127.0.0.1:6379> mget k1 k2
1) "vvvv1"
2) "v2"

• client2，session2，在session1 watch k1后exec前执行以下

127.0.0.1:6379> get k1
"vv1"
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k1 vvvv1
OK
127.0.0.1:6379> get k1
"vvvv1"

可以看到结果是全部回滚。

---

关于redis“部分支持事务”

由上面使用可以看出redis事务并不像传统数据库事务那么“纯粹”——出错便全体回滚。
大部分场景都是“部分事务回滚”，表现有点类似spring配置事务传播行为的 RequiredNew。

redis事务操作出错是否全部回滚，本身也“看情况”

• exec之前出错
  multi到exec之间可以看成是批量收集命令的过程，这个过程中出错（没有QUEUED），exec执行就会全体回滚，相当于主动DISCARD，比如命令的语法错误。
• exec之后出错
  命令全部收集OK了（QUEUED），此时出错则不会全体回滚，比如对键做了错误操作，类似spring配置事务传播行为的 RequiredNew，提交一个算一个。

• 官方关于为什么不支持传统回滚的原因（说白了就是redis很快，不需要）
  https://redis.io/topics/transactions#why-redis-does-not-support-roll-backs

  Why Redis does not support roll backs?

当然，使用 watch-multi-cas-exec 不一样，这会DISCARD，代表全部回滚。

综上，结合与传统数据库事务特点的对比，redis“部分支持事务”：

• exec执行与提交
  redis在exec之前，只是先攒着命令，并没有执行过（传统的数据库是执行了，事后通过undo日志来回滚），exec之后就是批量命令顺序执行，执行多少就多少，提交一个算一个。
• 不保证原子性
  即上面说的，exec之后，“事务”中的命令，如果有一个出错，其后的命令会继续执行，不受影响。exec之前的话，有点像我们进行编程时的操作前校验，“校验”（指加入命令队列）不通过，便不再继续，也就是redis所谓的回滚（DISCARD）。