共计 1056 个字符，预计需要花费 3 分钟才能阅读完成。
自动写代码机器人，免费开通
丸趣 TV 小编给大家分享一下 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 中分布式锁是不是乐观锁有了一定的了解，想了解更多相关知识，欢迎关注丸趣 TV 行业资讯频道，感谢各位的阅读！
向 AI 问一下细节
丸趣 TV 网 – 提供最优质的资源集合！
