基于数据库
1. 悲观锁
总是假设最坏的情况，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞直到它拿到锁（共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程）。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。Java中synchronized和ReentrantLock等独占锁就是悲观锁思想的实现。
优点：是比较安全的一种实现方法。
缺点：在高并发的场景下开销是不能容忍的。容易出现数据库死锁等情况。
2. 乐观锁
乐观锁常常用于分布式系统对数据库某张特定表执行update操作。考虑线上选座的场景，用户A和B同时选择了某场次电影的一个座位，都去将座位的状态设置为已售。
设想这样的执行序列：
1、用户A判断该座位为未售状态；
2、用户B判断该座位为未售状态；
3、用户A执行update座位为已售；
4、用户B执行update座位为已售。
这样会出现同一个座位售出两次的情况，解决方案是在这张数据库表中增加一个版本号的字段。执行操作前读取当前数据库表中的版本号，在执行update语句时将版本号放在where语句中，如果更新了记录则说明成功，如果没有更新记录，则说明此次update失败。
加了乐观锁的执行序列：
1、用户A查询该座位，得到该座位是未售状态，版本号是5；
2、用户B查询该座位，得到该座位是未售状态，版本号是5；
3、用户A执行update语句将座位状态更新为已售，版本号更新为6；
4、用户B执行update语句时此时这个座位的记录版本号为6，没有版本号为5的这个座位的记录，执行失败。
优点：乐观锁的性能高于悲观锁，并不容易出现死锁。
缺点：乐观锁只能对一张表的数据进行加锁，如果是需要对多张表的数据操作加分布式锁，基于版本号的乐观锁是办不到的。
基于Redis
redis提供了setNx原子操作。基于redis的分布式锁也是基于这个操作实现的，setNx是指如果有这个key就set失败，如果没有这个key则set成功，但是setNx不能设置超时时间。
基于redis组成的分布式锁解决方案为：
1、setNx一个锁key，相应的value为当前时间加上过期时间的时钟；
2、如果setNx成功，或者当前时钟大于此时key对应的时钟则加锁成功，否则加锁失败退出；
3、加锁成功执行相应的业务操作（处理共享数据源）；
4、释放锁时判断当前时钟是否小于锁key的value，如果当前时钟小于锁key对应的value则执行删除锁key的操作。
注：这对于单点的redis能很好地实现分布式锁，如果redis集群，会出现master宕机的情况。如果master宕机，此时锁key还没有同步到slave节点上，会出现机器B从新的master上获取到了一个重复的锁。
设想以下执行序列：
1、机器AsetNx了一个锁key，value为当前时间加上过期时间，master更新了锁key的值；
2、此时master宕机，选举出新的master，新的master正同步数据；
3、新的master不含锁key，机器BsetNx了一个锁key，value为当前时间加上过期时间；
这样机器A和机器B都获得了一个相同的锁；解决这个问题的办法可以在第3步进行优化，内存中存储了锁key的value，在执行访问共享数据源前再判断内存存储的锁key的value与此时redis中锁key的value是否相等如果相等则说明获得了锁，如果不相等则说明在之前有其他的机器修改了锁key，加锁失败。同时在第4步不仅仅判断当前时钟是否小于锁key的value，也可以进一步判断存储的value值与此时的value值是否相等，如果相等再进行删除。
此时的执行序列：
1、机器AsetNx了一个锁key，value为当前时间加上过期时间，master更新了锁key的值；
2、此时，master宕机，选举出新的master，新的master正同步数据；
3、机器BsetNx了一个锁key，value为此时的时间加上过期时间；
4、当机器A再次判断内存存储的锁与此时的锁key的值不一样时，机器A加锁失败；
5、当机器B再次判断内存存储的锁与此时的锁key的值一样，机器B加锁成功。
注：如果是为了效率而使用分布式锁，例如：部署多台定时作业的机器，在同一时间只希望一台机器执行一个定时作业，在这种场景下是允许偶尔的失败的，可以使用单点的redis分布式锁；如果是为了正确性而使用分布式锁，最好使用再次检查的redis分布式锁，再次检查的redis分布式锁虽然性能下降了，但是正确率更高。
网友评论