Redis的事务和Watch机制

1、背景

Redis version: 3.2.9

2、事务

Redis的事务，可以理解成是一系列命令的打包操作。
与传统事务相比，Redis的事务不支持回滚，若遇到错误，不影响其他命令的执行。符合Redis追求快速、高效的目标。当然，与此同时，也就无法做到严格的要么全部执行，要么全不执行。

（1）常用命令

multi exec discard 等

multi：开启事务
exec：提交事务
discard：取消事务

Tips:
因“语法错误”导致的error，redis 事务不回滚，不影响其他命令执行

下面的例子所示：
其中k1为string，无法执行incr命令，因此会报error。报错后，并没有影响后面的k2、k3的操作。

（2）lua脚本

是Redis事务的另一种实现，通过lua脚本，可以执行事务的原子性。

3、Watch

常用命令：Watch、UnWatch等

监控key，在事务中，若key被其他进程修改，则不允许被提交。

示例：
client1：

client2：

client1:

在client1的修改k的命令提交时，监测到k值已经被修改，因此，在执行“exec”提交事务命令时失败。client1的修改操作无法执行。

对于并发问题，Redis采用乐观锁的CAS去处理同步问题。另外，Redis中的CAS不会出现ABA问题。

Why？
我们从监控的示意图说起，若client监控了某个key值，就会将client信息保存在其后的链表中。

Redis在对key1值执行操作命令（如 set、del、sadd等）后，会将所有监视这个key1的客户端的REDIS_DIRTY_CAS选项打开。当客户端执行exec等命令时，会去检查REDIS_DIRTY_CAS。若被打开，则说明有其他client已经对该key值进行了修改，事务提交失败。

综上所述，CAS的ABA问题不会在Redis的watch中出现。

3、小结

无论是Redis的事务还是乐观锁的Watch机制，在了解新东西“如何用”的同时，也要和以往的基础做关联做对比，找到相似之处和不同之处。并分析不同之处存在的缘由。