小编给大家分享一下redis中分布式锁是不是乐观锁，希望大家阅读完这篇文章后大所收获，下面让我们一起去探讨吧！

 简单来说，Redis使用乐观锁，相对于悲观锁，在实现中更加简单，在某些场景中的性能也更好。Redis作为一个轻量级的、快速的缓存引擎，而不是一个全功能的关系型数据库，既没有使用悲观锁的必要，也难以承受使用悲观锁的成本。

乐观锁（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类型的缓存引擎，要处理的是大量读少量写的场景，对一致性也没有要求。

看完了这篇文章，相信你对redis中分布式锁是不是乐观锁有了一定的了解，想了解更多相关知识，欢迎关注天达云行业资讯频道，感谢各位的阅读！