Pomelo Lee workspace

几种常见的分布式锁的策略优缺点及对应处理

星期二, 十二月 19th, 2017 | JAVA-and-J2EE | 没有评论

在微信朋友圈看到的文章总结的很好,记录下以便翻阅.自己主要是以redis做分布式锁实现.

前言

随着互联网的发展，各种高并发、海量处理的场景越来越多。为了实现高可用、可扩展的系统，常常使用分布式，这样避免了单点故障和普通计算机cpu、内存等瓶颈。

但是分布式系统也带来了数据一致性的问题，比如用户抢购秒杀商品多台机器共同执行出现超卖等。有些同学容易将分布式锁与线程安全混淆，线程安全是指的线程间的协同。如果是多个进程间的协同需要用到分布式锁，本文总结了几种常见的分布式锁。

基于数据库

悲观锁—事务

比如用户抢购秒杀商品的场景，多台机器都接收到了抢购的请求，可以将获取库存、判断有货、用户付款、扣减库存等多个数据库操作放到一个事务，这样当一台机器与数据库建立链接请求了抢购商品这个事务，另外的机器只能等这个机器将请求完成才能操作数据库。在实际应用场景中，常常库存与交易是两个独立的系统，这时的事务是一个分布式事务，需要用到两段式、三段式提交。

优点：是比较安全的一种实现方法。

缺点：在高并发的场景下开销是不能容忍的。容易出现数据库死锁等情况。

乐观锁—基于版本号

乐观锁常常用于分布式系统对数据库某张特定表执行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的这个座位的记录，执行失败。

优点：乐观锁的性能高于悲观锁，并不容易出现死锁。

缺点：乐观锁只能对一张表的数据进行加锁，如果是需要对多张表的数据操作加分布式锁，基于版本号的乐观锁是办不到的。

› Continue reading

Tags: redis, 分布式锁