Optimistic locking using check-and-set(乐观锁)
乐观锁介绍：
watch指令在redis事物中提供了CAS的行为。为了检测被watch的keys在是否有多个clients同时改变引起冲突，这些keys将会被监控。如果至少有一个被监控的key在执行exec命令前被修改，整个事物将会回滚，不执行任何动作，从而保证原子性操作，并且执行exec会得到null的回复。
乐观锁工作机制：
watch 命令会监视给定的每一个key，当exec时如果监视的任一个key自从调用watch后发生过变化，则整个事务会回滚，不执行任何动作。注意watch的key是对整个连接有效的，事务也一样。如果连接断开，监视和事务都会被自动清除。当然exec，discard，unwatch命令，及客户端连接关闭都会清除连接中的所有监视。还有，如果watch一个不稳定(有生命周期)的key并且此key自然过期，exec仍然会执行事务队列的指令。
客户端1 | 客户端2 | 说明 |
redis 127.0.0.1:6379> get age "10" redis 127.0.0.1:6379> get name "zhangsan" | redis 127.0.0.1:6379> get age "10" redis 127.0.0.1:6379> get name "zhangsan" | 数据库中两客户端登录，及键初始值。 |
redis 127.0.0.1:6379> multi OK redis 127.0.0.1:6379> incr age QUEUED redis 127.0.0.1:6379> set name lisi QUEUED | 此时，客户端1开启事务，并提交队列命令： 1.想要将当前age自增+1运算； 2.将name值改为lisi | |
redis 127.0.0.1:6379> incr age (integer) 11 | 此时，客户端2修改了age值 | |
redis 127.0.0.1:6379> exec 1) (integer) 12 2) OK redis 127.0.0.1:6379> get name "lisi" | 此时，客户端1执行队列命令，发现运算之后age不是理想中的11，而是12原因是被其它客户插足抢先给修改了。name值也修改了。这样可能导致数据不一致性... 为了解决这个问题引入“乐观锁”的机制： | |
客户端1-引入“乐观锁”机制 | 客户端2 | 说明 |
redis 127.0.0.1:6379> get age "10" redis 127.0.0.1:6379> get name "zhangsan" | redis 127.0.0.1:6379> get age "10" redis 127.0.0.1:6379> get name "zhangsan" | 数据库中两客户端登录，及键初始值。 |
redis 127.0.0.1:6379> watch age name OK redis 127.0.0.1:6379> multi OK redis 127.0.0.1:6379> incr age QUEUED redis 127.0.0.1:6379> set name lisi QUEUED | 此时，客户端1用watch命令监视age和name，然后开启事务，并提交队列命令 | |
redis 127.0.0.1:6379> incr age (integer) 11 | 此时，客户端2修改了age值 | |
redis 127.0.0.1:6379> exec (nil) redis 127.0.0.1:6379> get age "11" redis 127.0.0.1:6379> get name "zhangsan" | 此时，客户端1执行队列命令，由watch监控发现此期间age的值已经被修改过，则让事整个务回滚，不做任何动作。 watch可以同时监控多个键，在监控期间只要有一个键被其它客户端改变，则整个事务回滚。 | |
