Redis事务和乐观锁

一.事务定义

• 事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
• 事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。

二.Rdis事务

1) MUTLI开启事务

MULTI 执行之后， 客户端可以继续向服务器发送任意多条命令， 这些命令不会立即被执行， 而是被放到一个队列中， 当 EXEC 命令被调用时， 所有队列中的命令才会被执行

2) EXEC：提交事务

如果客户端在使用 MULTI 开启了一个事务之后，却因为断线而没有成功执行 EXEC ，那么事务中的所有命令都不会被执行。
另一方面，如果客户端成功在开启事务之后执行 EXEC ，那么事务中的所有命令都会被执行。

3) DISCARD取消事务

记住，此指令不是严格意义上的“事务回滚”，只是表达了“事务操作被取消”的语义，客户端会清空事务的操作队列， 并放弃执行事务

代码实例

> MULTI
OK

> INCR foo
QUEUED

> INCR bar
QUEUED

> EXEC
1) (integer) 1
2) (integer) 1

4) 扩展

当使用 AOF 方式做持久化的时候， Redis 会使用单个 write(2) 命令将事务写入到磁盘中。

然而，如果 Redis 服务器因为某些原因被管理员杀死，或者遇上某种硬件故障，那么可能只有部分事务命令会被成功写入到磁盘中。

如果 Redis 在重新启动时发现 AOF 文件出了这样的问题，那么它会退出，并汇报一个错误。

使用 redis-check-aof 程序可以修复这一问题：它会移除 AOF 文件中不完整事务的信息，确保服务器可以顺利启动。

二.Redis WATCH 实现乐观锁

WATCH/UNWATCH：“监控”，这个操作也可以说是Redis的特殊功能，在事务开启“MUTIL”前，可以对某个KEY注册“WATCH”，如果在事务提交后，将会首先检测“WATCH”列表中的KEY集合是否被其他客户端修改，如果任意一个KEY 被修改，都将会导致事务直接被“DISCARD清空事务操作队列；事务执行成功或者被DISCARD，都将会导致WATCH KEY被“UNWATCH”，因此事务之后，你需要重新WATCH。WATCH需要在事务开启之前执行。

举个例子， 假设我们需要原子性地为某个值进行增 1 操作（假设 INCR 不存在）。

val = GET mykey
val = val + 1
SET mykey $val

上面的这个实现在只有一个客户端的时候可以执行得很好。 但是， 当多个客户端同时对同一个键进行这样的操作时， 就会产生竞争条件。

举个例子， 如果客户端 A 和 B 都读取了键原来的值， 比如 10 ， 那么两个客户端都会将键的值设为 11 ， 但正确的结果应该是 12 才对。

有了 WATCH ， 我们就可以轻松地解决这类问题了：

WATCH mykey

val = GET mykey
val = val + 1

MULTI
SET mykey $val
EXEC

使用上面的代码， 如果在 WATCH 执行之后， EXEC 执行之前， 有其他客户端修改了 mykey 的值， 那么当前客户端的事务就会失败。 程序需要做的， 就是不断重试这个操作， 直到没有发生碰撞为止。

这种形式的锁被称作乐观锁， 它是一种非常强大的锁机制。 并且因为大多数情况下， 不同的客户端会访问不同的键， 碰撞的情况一般都很少， 所以通常并不需要进行重试。