Redis学习:Redis实现乐观锁

实际这部分是接着事务那一块,加了一个watch命令。

这里要有一个乐观锁和悲观锁的概念:
悲观锁:

很悲观,认为什么时候都会出现问题,无论做什么都会加锁

乐观锁:

很乐观,认为什么时候都不会出现问题,所以不会上锁!更新数据的时候去判断一下,在此期间是否有人修改过这个数据
获取version
更新的时候比较version

watch命令
使用watch key监控指定数据,相当于乐观锁加锁。类似一个CAS操作。

127.0.0.1:6379> set money 100 # 设置余额:100
OK
127.0.0.1:6379> set use 0 # 支出使用:0
OK
127.0.0.1:6379> watch money # 监视money (上锁)
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> DECRBY money 20
QUEUED
127.0.0.1:6379> INCRBY use 20
QUEUED
127.0.0.1:6379> exec # 监视值没有被中途修改,事务正常执行
1) (integer) 80
2) (integer) 20

测试多线程修改值,使用watch可以当做redis的乐观锁操作(相当于getversion)

起两个客户端模拟多线程
线程一

127.0.0.1:6379> watch money # money上锁
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> DECRBY money 20
QUEUED
127.0.0.1:6379> INCRBY use 20
QUEUED
127.0.0.1:6379> 	# 此时事务并没有执行

线程二

127.0.0.1:6379> INCRBY money 500 # 修改了线程一中监视的money
(integer) 600

回到线程一客户端

127.0.0.1:6379> EXEC # 执行之前,另一个线程修改了我们的值,这个时候就会导致事务执行失败
(nil) # 没有结果,说明事务执行失败

127.0.0.1:6379> get money # 线程2 修改生效
"600"
127.0.0.1:6379> get use # 线程1事务执行失败,数值没有被修改
"0"

解锁获取最新值,然后再加锁进行事务。

unwatch进行解锁。

实际上用得不多,很多利用redis分布式锁一般是setex+lua脚本(Redisson)

但是redis分布式锁是最简单实现的,但是也会有问题GC阻塞时间太长,导致时间失效,或者是redis服务器时钟漂移(就是两台服务器时间不一致,一个快导致两个服务器一把锁),还有单点故障master挂掉slave成为master也会带来问题。

解决单点故障有redlock,就是对多个端设置时间,但是对于每个redis实例设置一个超时时间,比如书1min有效时间,超时时间是1秒,你在1秒内获取不到这个实例,就取获取下一个锁。

你可能感兴趣的:(redis,redis,lua,数据库)