Redis监听：悲观锁和乐观锁

悲观锁：每次拿数据的时候都认为别人会修改，所以在每次拿数据的时候都会上锁。

传统的关系型数据库里面就用到了很多这种锁机制，比如行锁，表锁，读锁，写锁等，都是在操作之前先上锁。

乐观锁：每次拿数据的时候都认为别人不会修改，所以在每次拿数据时候都不会上锁。

乐观锁适用于多读的应用类型，这样可以提高吞吐量。

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

实践

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

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
OK

窗口2

127.0.0.1:6379> get balance
"80"
127.0.0.1:6379> set balance 200
OK

窗口1

127.0.0.1:6379(TX)> decrby balance 20
QUEUED
127.0.0.1:6379(TX)> incrby detb 20
QUEUED
127.0.0.1:6379(TX)> exec
(nil)
127.0.0.1:6379> get balance
"200"

由于窗口 1 监听 balance 并开启事务后，窗口 2 修改了 balance 的值，导致窗口 1 的监听失败，执行事务后展示为空，且 balance 的值不是预期值。

监听失败后放弃监听，然后重来

窗口1

127.0.0.1:6379> unwatch
OK
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

小结

• 一旦exec开启事务后，无论事务是否执行成功，watch对变量的监听都将被取消。
• 当事务执行失败后，需要重新执行watch命令对变量进行监听，并开启新的事务进行操作。
• watch指令类似于乐观锁，在事务提交时，如果watch监控的多个key中任何key的值已经被其他客户端更改，则使用exec执行事务时，事务队列将不会被执行，同时返回（nil）应答以通知调用者事务执行失败。