当前位置:Gxlcms > redis > redis的分布式锁是乐观锁吗

redis的分布式锁是乐观锁吗

时间:2021-07-01 10:21:17 帮助过:117人阅读

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

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

乐观锁策略:提交版本必须大于记录当前版本才能执行更新(推荐学习:Redis视频教程)

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

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

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

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

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

更多Redis相关技术文章,请访问Redis数据库使用入门教程栏目进行学习!

以上就是redis的分布式锁是乐观锁吗的详细内容,更多请关注Gxl网其它相关文章!

人气教程排行