Redis使用Watch命令演示乐观锁（含图解）

前置知识

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

2、乐观锁(Optimistic Lock),，顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据（版本是否一致，不一致就放弃当前操作），可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。

3、Redis不支持悲观锁。Redis 作为缓存服务器使用时，以读操作为主，很少写操作，相应的操作被打断的几率较少。不采用悲观锁是为了防止降低性能。

4、watch命令是Redis实现乐观锁的一种手段。开启事务前 ，watch指令会对数据进行监听，exec时，如果发生数据发生过修改，作用于改数据的事务会自动取消（DISCARD）,事务EXEC后，无论成败，监听会被移除。    

实践是检验理论的唯一标准    

根据以上理论，通过自己的理解模拟了两个事务在开启对数据的监听后，最终数据有什么样的变化！有兴趣的小伙伴可以多动手尝试去检验一下

 从上图可以看出事务2先执行的incrby指令，这意味着num的版本最先更新，所以事务1在提交的时候就会报错，最终num的结果就是15