redis乐观锁

乐观锁（又名乐观并发控制，Optimistic Concurrency Control，缩写“OCC”），是一种并发控制的方法。它假设多用户并发的事务在处理时不会彼此互相影响，各事务能够在不产生锁的情况下处理各自影响的那部分数据。在提交数据更新之前，每个事务会先检查在该事务读取数据后，有没有其他事务又修改了该数据。

与乐观所相对的，就是悲观锁（又名悲观并发控制，Pessimistic Concurrency Control，缩写“PCC”），它可以阻止一个事务以影响其他用户的方式来修改数据。如果一个事务执行的操作都某行数据应用了锁，那只有当这个事务把锁释放，其他事务才能够执行与该锁冲突的操作。

通俗的说，就是悲观锁就是“先取锁在访问”，因为悲观锁会“悲观”地认为访问会产生冲突，因此这种保守的策略虽然在数据处理的安全行上提供了保障，但是在效率方面会让数据库产生极大的开销，而且还有可能出现死锁的情况。

在Redis中WATCH命令的实现是基于乐观锁，即，假设访问不会产生冲突，但是在提交数据之前会先检查该事务该事物读取数据后，其他事务是否修改数据，如果其他事务修改了数据，像MySQL提供了回滚操作，而Redis不支持回滚，因为antirez认为这与Redis简单高效的设计主旨不相符，并且Redis事务执行时错误在开发环境时是可以避免的。

乐观锁控制的事务一般包括三个阶段：

• 读取：当执行完MULTI命令后，客户端进入事务模式，客户端接下来输入的命令会读入到事务队列中，入队过程中出错会设置CLIENT_DIRTY_EXEC标识。
• 校验：如果数据库有键被修改，那么会检测被修改的键是否是被WATCH命令监视的命令，如果是则会设置对应的标识（CLIENT_DIRTY_CAS），并且在命令执行前会检测这两个标识，如果检测到该标识，则会取消事务的执行。
• 写入：如果没有设置以上两种标识，那么会执行事务的命令，而Redis是单进程模型，因此可以避免执行事务命令时其他请求可能修改数据库键的可能。

Redis的乐观锁不是通常实现乐观锁的一般方法：检测版本号，而是在执行完一个写命令后，会进行检查，检查是否是被WATCH监视的键。