Redis6.x 事务冲突的问题

最新推荐文章于 2022-04-26 16:56:25 发布

Alienware^

最新推荐文章于 2022-04-26 16:56:25 发布

阅读量175

点赞数 1

分类专栏： Redis 文章标签：数据库 redis

本文链接：https://blog.csdn.net/weixin_45417821/article/details/120120843

版权

Redis 专栏收录该内容

41 篇文章 1 订阅

订阅专栏

本文介绍了Redis中的事务处理机制，包括悲观锁和乐观锁的概念。悲观锁在操作数据时预先上锁，保证同一时间只有一个操作可以进行，而乐观锁则通过版本号检查实现并发控制。Redis使用乐观锁的check-and-set机制来实现事务，允许在事务执行前监控key的变化。文章还提到了WATCH和UNWATCH命令在事务中的作用，以及Redis事务的三大特性：序列化执行、无隔离级别和不保证原子性。

摘要由CSDN通过智能技术生成

例子

一个请求想给金额减8000
一个请求想给金额减5000
一个请求想给金额减1000

在这里插入图片描述

悲观锁

在这里插入图片描述
悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。

悲观锁：假设我有一万块钱，这一万块钱有三个人同时操作，假设这三个人一个人拿8000，一个人拿5000，一个人拿1000，开始操作时，这一万块钱先上锁，让第一个人先去操作，此时其他人无法操作，当8000拿到之后，剩下的2000是释放锁的，这时第二个人去上锁并且进行操作。因为第二个人拿5000，此时第二个人不操作，依次推类。（当我上了锁之后，别人不能操作，当我将锁解开之后，别人才能操作）

缺点，效率很低，只能一个一个人去操作，不能多人同时进行。

乐观锁

在这里插入图片描述乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。

乐观锁：假设还是有一万块钱，我将这一万块钱设置版本号。假设版本号为1.0，接下来有一个人要拿8000，一个人要拿5000，版本号都为1.0他们同时操作，先拿8000的先操作了，当操作之外，还剩下的2000，设置版本号为1.1，而下一个操作的拿5000，要和2000的作比较，判断当前数据的版本号和操作的版本号是否一致，当发现版本号不同，那这个那5000的就不能进行操作了。