redis 事务 和 watch

一般的 事务简单来说就是 一系列的操作保证原子性，成功都成功～失败都失败。

但是！但是！但是！ redis 的事务在执行中出错时，错的将会被忽略，队列之后的指令依然可以执行。一旦出现这种情况 需要手动回滚。

redis 的事务仅仅保证了所有的操作都会严格的 按照原子操作来执行，不保证所有的都是成功的，这需要开发者自己来约束。

开启和执行

如何开启事物并开始执行

multi

设定事务的开启位置，此指令执行后，后续的所有指令均加入到事务中。

exec

设定事务的结束位置，同时执行事务。与multi成对出现，成对使用

注意

加入事务的命令暂时到任务队列中，没有立即执行，在一切顺利的情况下（在nulti 和 exec 之间没有出现error）只有执行exec命令才开始执行。

取消事务

将 multi 之后但还没有 exec 的事物取消掉

主动

discard
终止当前事务定义，发生在multi之后，exec之前。

被动

语法错误

在事务的定义阶段，也就是 multi 和 exec 之间存在语法错误，那么整个事务队列将会被删除。

当redis事务开始执行，就不在乎是否全部成功，即使存在error 后面的也会执行，需要手动回滚。

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name monkey
QUEUED
127.0.0.1:6379> set gender male or female    # 执行这行会报错
QUEUED
127.0.0.1:6379> get name
QUEUED
127.0.0.1:6379> exec
1) OK   # name 设置成功了
2) (error) ERR syntax error  # gender 失败
3) "monkey"  # 错误之后的也会执行～  这事务 很蛋疼～～
127.0.0.1:6379> 

手动进行事务回滚

记录状态

将操作过程中被影响的数据提前备份记录
单数据：string
多数据：hash,list,set,zset

恢复状态

使用之前备份的数据恢复事务操作之前的数据。
单数据：直接set（注意周边属性，例如时效）
多数据：修改对应值或整体克隆复制

事务的工作流程

watch

场景

假如在线商城的某个货物售空了，此时有多个业务员可以进行补货操作。但是又希望在卖的商品不能超过100个，应该怎么办？

分析

这几个业务员不可能每次补货之前都沟通一下，因此必须要保证每次只能有一个人来操作数据，并且数据一旦被修改，就不需要其他人在修改了。一旦多个人同时修改，则只有一个人能修改成功。

解决方案

对 key 添加监视锁，在执行exec前如果 key 发生了变化，终止事务执行

watch key1 [key2…]   # 可以同时监视多个变量

取消对所有key的监视

unwatch  # 取消对所有key的监视

我们先对当前的 货物数 进行监视，对补货操作开启事务，如果在执行事务 exec 之前 数量变了，表示已经有人进行了补货操作，因此终止事务。如果一切顺利，成功的补货完成。

注意 在 watch 对象改变时，事务队列中所有的操作都不会被执行，就是说事务队列直接被销毁。