redis事务及乐观锁

[TieMuZhen]

乐观锁 VS 悲观锁

乐观锁

这个世界是美好的，别人肯对不会在我操作数据前进行更改。在redis中，乐观锁指的是只是对key上锁，只要key不变就代表不会出问题。redis中的事务multi默认使用乐观锁，这将会导致一个问题：在秒杀这种高并发环境下，容易造成超卖问题。

如，在一件商品只剩一件时，这时A用户开启事务只准备抢购，而就在A完成事务之前，B用户已经抢了这件商品，当A完成事务后，库存数量为-1。为了解决这个问题，可以引进悲观锁。

悲观锁

这个世界一切东西都是不可信的。在redis中，悲观锁指的是对数据key和value都上锁，只要这个数据有一点小改动，事务将失败。因此上面的秒杀活动，在开启事务前，可对库存上锁：watch，只要在这个watch之后，别的进程或线程对这个库存有修改，本线程的事务将不会执行成功。

两种锁的使用场景

从上面对两种锁的介绍，我们知道两种锁各有优缺点，不可认为一种好于另一种，

• 乐观锁适用于写比较少的情况下（多读场景），即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。
• 如果是多写的情况，一般会经常产生冲突，这就会导致上层应用会不断的进行retry，这样反倒是降低了性能，所以一般多写的场景下用悲观锁就比较合适。

乐观锁的缺点

ABA 问题

如果一个变量V初次读取的时候是A值，并且在准备赋值的时候检查到它仍然是A值，那我们就能说明它的值没有被其他线程修改过了吗？

很明显是不能的，因为在这段时间它的值可能被改为其他值，然后又改回A，那CAS操作就会误认为它从来没有被修改过。这个问题被称为 ABA问题。

redis事务及乐观锁

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

Redis事务没有隔离级别的概念 所有的命令在事务中，并没有直接被执行！只有发起执行命令的时候才会执行exec

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

Redis事务的三个阶段：

• 开始事务(multi)
• 命令入队
• 执行事务(exec)

Redis事务相关命令：

• watch key1 key2 ...: 监视一或多个key，如果在事务执行之前，被监视的key被其他命令改动，则事务被打断 （ 类似乐观锁 ）
• multi: 标记一个事务块的开始
• exec: 执行所有事务块的命令 （ 一旦执行exec后，之前加的监控锁都会被取消掉 ）　
• discard: 取消事务，放弃事务块中的所有命令
• unwatch: 取消watch对所有key的监控

Redis事务使用案例：

（1）正常执行

（2）放弃事务

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

（4） 运行错误指在EXEC命令执行时出现的错误，这种错误在实际执行之前Redis是无法发现的，所以在事务里这样的命令是会被Redis接受并执行的。如果事务里的一条命令出现了运行错误，事务里其他的命令依然会继续执行（包括出错命令之后的命令）：

redis＞MULTI
OK
redis＞SET key 1
QUEUED
redis＞SADD key 2
QUEUED
redis＞SET key 3
QUEUED
redis＞EXEC
1) OK
2) (error) ERR Operation against a key holding the wrong kind of value
3) OK
redis＞GET key
"3"

（5）使用watch

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

案例二：使用watch检测balance，在开启事务后（标注1处），在新窗口执行标注2中的操作，更改balance的值，模拟其他客户端在事务执行期间更改watch监控的数据，然后再执行标注1后命令，执行EXEC后，事务未成功执行。

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

参考文献

• redis事务及乐观锁