Redis 事务和乐观锁

快乐的小三菊

已于 2023-08-25 12:15:39 修改

阅读量3.1k

点赞数 1

分类专栏： redis 文章标签： redis

于 2020-04-22 16:40:44 首次发布

本文链接：https://blog.csdn.net/xhf852963/article/details/105686399

版权

redis 专栏收录该内容

24 篇文章 0 订阅

订阅专栏

一、事务

1.1 概念

Redis 事务的本质是一组命令的集合。事务支持一次执行多个命令，一个事务中所有命令都会被序列化。在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。

总结起来就是：redis 事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。

1.2 隔离级别

Redis 事务没有隔离级别的概念，批量操作在发送 EXEC 命令前被放入队列缓存，并不会被实际执行。

1.3 Redis 不保证原子性

Redis 中，单条命令是原子性执行的，但事务不保证原子性，且没有回滚。事务中任何命令执行失败，其余的命令仍会被执行。

1.4 Redis 事务的三个阶段

a、开始事务

b、命令入队

c、执行事务

1.5 Redis 事务相关命令

# 监视一或多个key,如果在事务执行之前，被监视的key被其他命令改动，则事务被打断 （ 类似乐观锁 ）
watch key1 key2 ... 

# 标记一个事务块的开始（ queued ）
multi 

# 执行所有事务块的命令 （ 一旦执行exec后，之前加的监控锁都会被取消掉 ）
exec 

# 取消事务，放弃事务块中的所有命令
discard 

# 取消watch对所有key的监控
unwatch

1.6 Redis 事务实践

1.6.1 正常执行

1.6.2 放弃事务

1.6.3 命令存在错误

若在事务队列中存在命令性错误（类似于 java 编译性错误），则执行 exec 命令时，所有命令都不会执行。

1.6.4 运行时错误

若在事务队列中存在语法性错误（类似于 java 的 I/O 的运行时异常），则执行 exec 命令时，其他正确命令会被执行，错误命令抛出异常。

二、乐观锁

2.1 悲观锁

悲观锁（Pessimistic Lock），顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿到这个数据就会 block 直到它拿到锁。传统的关系型数据库里面就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在操作之前先上锁。

2.2 乐观锁

乐观锁（Optimistic Lock），顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁。但是在更新的时候会判断一下再此期间别人有没有去更新这个数据，可以使用版本号等机制，乐观锁适用于多读的应用类型，这样可以提高吞吐量，

乐观锁策略：提交版本必须大于记录当前版本才能执行更新。

2.3 测试

初始化信用卡可用余额和欠款金额

127.0.0.1:6379> clear
127.0.0.1:6379> set balance 100
OK
127.0.0.1:6379> set debt 0
OK

使用 watch 检测 balance，事务期间 balance 数据未变动，事务执行成功

127.0.0.1:6379> watch balance
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> decrby balance 20
QUEUED
127.0.0.1:6379(TX)> incrby debt 20
QUEUED
127.0.0.1:6379(TX)> exec
1) (integer) 80
2) (integer) 20

使用 watch 检测 balance，事务期间 balance 数据变动，事务执行失败！

# 窗口 1 操作
127.0.0.1:6379> watch balance
OK
127.0.0.1:6379> multi               # 执行完此条命令后，执行窗口 2 的代码测试 
OK
127.0.0.1:6379(TX)> decrby balance 20
QUEUED
127.0.0.1:6379(TX)> incrby debt 20
QUEUED
127.0.0.1:6379(TX)> exec            # 修改失败
(nil)

# 窗口 2 操作
127.0.0.1:6379> get balance
"80"
127.0.0.1:6379> set balance 200
OK

# 窗口 1 操作，出现问题后放弃监视，然后重来！
127.0.0.1:6379> unwatch          # 放弃监视
127.0.0.1:6379> watch balance
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> decrby balance 20
QUEUED
127.0.0.1:6379(TX)> incrby debt 20
QUEUED
127.0.0.1:6379(TX)> exec          # 成功！
1) (integer) 180
2) (integer) 40

2.4 说明

一旦执行 EXEC 开启事务的执行后，无论事务执行是否成功， WATCH 对变量的监控都将被取消。故当事务执行失败后，需重新执行 WATCH 命令对变量进行监控，并开启新的事务进行操作。

2.5 小节

watch 指令类似于乐观锁，在事务提交时，如果 watch 监控的多个 KEY 中任何 KEY 的值已经被其他客户端更改，则使用 EXEC 执行事务时，事务队列将不会被执行，同时返回 Nullmulti-bulk 应答以通知调用者事务执行失败。