Redis 事务操作原理

事务原理剖析

redis事务操作，原理是基于pipe队列实现原子性提交操作，在只想事务操作，相当于将需要提交的命令放置在队列中，基于Pipe实现批量提交命令：
请看下面示例：

192.168.137.150:0>multi
"OK"
192.168.137.150:0>set 11 22
"QUEUED"
192.168.137.150:0>set 22 33
"QUEUED"
192.168.137.150:0>set 33 44
"QUEUED"
192.168.137.150:0>exec
 1)  "OK"
 2)  "OK"
 3)  "OK"

事务执行相关指令：

MULTI：redis事务开始的标志
EXEC：redis 事务结束的标志
DISCARD：DISCARD通常在事务
WATCH：对数据进行监听，假如当前数据发生更改，需要重新执行事务
UNWATCH:对数据取消监听

redis 事务不支持回滚

只有在使用错误的语法调用时才会失败Redis命令（并且在命令排队期间无法检测到问题），或者对于持有错误数据类型的键，Redis命令可能会失败：这意味着实际上失败的命令是编程错误的结果，以及在开发过程中很可能检测到的一种错误，而不是在生产中。
Redis内部简化且速度更快，因此它不需要回滚的能力。

watch实现乐观锁

WATCH用于为Redis事务提供检查和设置（CAS）行为。

WATCH监视ed键以检测对它们的更改。如果在EXEC命令之前修改了至少一个监视密钥，则整个事务将中止，并且EXEC返回Null应答以通知该事务失败。

例如，假设我们需要将键的值原子递增1（假设Redis没有INCR）。

第一次尝试可能如下：

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

只有当我们有一个客户在给定时间内执行操作时，这才能可靠地工作。如果多个客户端几乎在同一时间尝试递增密钥，则会出现竞争条件。例如，客户端A和B将读取旧值，例如，10。两个客户端将值增加到11，最后SET作为密钥的值。所以最终值将是11而不是12。

感谢WATCH，我们能够很好地模拟问题：

WATCH mykey
val = GET mykey
val = val + 1
MULTI
SET mykey $val
EXEC

使用上面的代码，如果存在竞争条件而另一个客户端修改了val我们对WATCH的调用和我们对EXEC的调用之间的时间结果，则事务将失败。
我们只需要重复这个操作，希望这次我们不会再参加比赛了。这种形式的锁定称为乐观锁定，是一种非常强大的锁定形式。在许多用例中，多个客户端将访问不同的密钥，因此不太可能发生冲突 - 通常不需要重复操作。

那么WATCH究竟是什么呢？这是一个使EXEC成为条件的命令：只有在没有WATCH修改ed键的情况下，我们才会要求Redis执行事务。（但是它们可能会被交易中的同一客户更改而不会中止。更多内容。）否则交易根本不会输入。（请注意，如果你观察了一个易失性密钥，而Redis在你编写密钥后会使密钥到期，WATCH那么[EXEC]仍然有用可以多次调用[WATCH]。简单地说，所有[WATCH]呼叫都有效监视从呼叫开始的更改，直到调用[EXEC]。您还可以向单个[WATCH]呼叫发送任意数量的密钥。

当EXEC被调用时，所有按键都UNWATCH编，不管交易是否中止与否。此外，当客户端连接关闭时，所有内容都会被UNWATCH编辑。

也可以使用UNWATCH命令（不带参数）来刷新所有被监视的键​​。有时这很有用，因为我们乐观地锁定了几个键，因为我们可能需要执行一个事务来改变这些键，但是在读完键的当前内容之后我们不想继续。当发生这种情况时，我们只需调用UNWATCH，以便连接可以自由地用于新事务。