悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。
SQL数据库中使用FOR UPDATE进行数据锁定，更新的时候通过事务实现隔离。
乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。
两种锁各有优缺点，不可认为一种好于另一种，像乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去了锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行retry，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适。
乐观锁的版本号：A和B用户同时读取同一条数据时，在这个数据上为其设置一个版本号(1);
A对数据修改后版本号更新
B数据修改是发现版本号变化，无法更新
Redis-A：设置数据
set age18
Redis-A：对数据进行监听
watch age
Redis-A：开启事务支持
multi
Redis-B：修改age数据
set age 38
Redis-A：修改age数据
set age 68
Redis-A：进行事务提交
exec
Redis-A使用了watch监听，B已经修改了相应的数据内容，执行后出现nil，表示没有正常执行