乐观锁（Optimistic Lock），顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候回判断一下再次期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。

乐观锁策略：提交版本必须大于记录当前版本才能执行更新

Redis对于事务只提供了非常有限的支持，其实更多地是试图绕过问题。

首先，Redis对于同一事务中的一组操作，而不是立即执行，而是放入一个queue中，当执行到EXEC时，再一起执行。事务执行是全局独占的，也就是同一时间只有一个事务被执行，中途不能被其它事务打断。Redis用这种最简单的、也是性能最差的方式避免了race condition。

其次，在Redis的事务中，如果有一个或多个操作失败，其它操作仍然会成功，也就是说它根本没有回滚机制。

这种方式会带来很多严重的问题，其中之一是，无法先读取某个数值后再进行依赖这个值的操作，因为放在一个事务里会被在同一个瞬间执行，不放在同一个事务里又会导致race condition。解决方法是使用WATCH，它会监视一个或多个变量，如果变量的值在调用WATCH以后和事务提交之前被别的事务修改过了，整个事务都会失败。这类似于操作系统中的CAS（Compare and Set）。我不知道WATCH具体是怎么实现的，但是我推测它监控了指定变量的版本号。

即使有了WATCH，Redis的事务也是受到严重限制的。第一，它没有实现读数据时的一致性，因为WATCH对于读操作不起作用。第二，它不支持回滚。第三，在对同一变量存在大量并发写操作时，性能会非常差，因为每次提交事务时，WATCH监控的变量都已经被修改了，导致事务将多次提交失败。但是，Redis本来就是一个KV类型的缓存引擎，要处理的是大量读少量写的场景，对一致性也没有要求。