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秒内获取不到这个实例，就取获取下一个锁。