前言

提示：本文章是日常学习内容的总结，并非全部原创；仅供大家参考借鉴，并无其他商业用途。Bilibili搜索关注：狂神说
真正在公司中的实践：NoSQL + RDBMS 一起使用才是最强的，阿里巴巴的架构演进！
技术没有高低之分，就看你如何去使用！（提升内功，思维的提高！）
云计算的长征之路：阿里云的这群疯子

概括

悲观锁：

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

乐观锁：

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

1、Redis测监视测试

1.1、正常执行成功

127.0.0.1:6379> set money 100 
OK
127.0.0.1:6379> set out 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 out 20
QUEUED 
127.0.0.1:6379> exec 
1) (integer) 80 
2) (integer) 20

1.2、测试多线程修改值 ，事务执行失败 返回(nil)

打开另一个redis-cli客户端，在其exec提交事务之前；修改money对象的值
使用watch 可以当做redis的乐观锁操作！
很乐观，不上锁！ 只在更新数据的时候去判断一下，在此期间是否有人修改过这个数据，

127.0.0.1:6379> watch money           # 监视 money 
OK
127.0.0.1:6379> multi 
OK
127.0.0.1:6379> DECRBY money 10 
QUEUED 
127.0.0.1:6379> INCRBY out 10 
QUEUED 
127.0.0.1:6379> exec                  # 执行之前，另外一个线程，修改了我们的值，这个时候，就会导致事务执行失 败！
(nil)

1.2.1、如果事务修改失败，怎么办？

先解锁money对象，再重新监视money对象的最新值，最后exec重新提交事务