分布式锁

微信扫一扫,分享到朋友圈

分布式锁

在jvm中,我们可以通过synchronized或者cas的lock加锁。又有单机的性能太差,无法适应高并发的需求,所以我们做了集群,此时jvm是无法控制其他jvm的锁的,这个时候只能分布式锁处理。分布式锁的本质,就是互斥,被A占领了资源,BCDEF等都不能用,把并行的操作,转为串行。

数据库

主键或唯一索引

我们知道,主键和唯一索引是不能重复的,所以我们可以利用这个做到资源的互斥。通过insert语句, insert into table VALUES(id,col1,col2)
,如果插入成功,说明拿到了锁,如果插入失败,报 Duplicate entry...key 'PRIMARY'
的错误,说明锁已经被拿到了。拿到锁的应用,操作完成,只需要删除这个id就可以释放锁了,其他应用就可以insert成功拿到锁。

由于insert和delete是两个操作,如果delete失败,则锁无法释放。所以插入的时候还要记录插入的时间,然后跑一个定时任务,看他已经多久没释放锁了,如果时间超过设定的阈值,则说明他删除失败,把这个记录删除释放锁。这边又引入了一个问题,阈值要怎么设置?设置长了,会导致其他应用长时间获取不到锁,设置短了,获取锁的应用还没执行完,锁就失效了,然后其他应用由获取到这个锁,达不到对资源互斥的效果。

乐观锁

主要是通过version来判断。 update table set col1=val,version=v1 where version=v2
,先从数据库取出version,再执行上面的语句,如果执行成功,说明拿到锁。乐观锁和主键的优点是他不需要释放锁。但是在大量的并发下,频繁的操作这个表,可能会导致数据库的不可用。

悲观锁

借助mysql数据库的 FOR UPDATE
,FOR UPDATE是一种行级锁,又叫排它锁。FOR UPDATE仅适用于InnoDB,且必须在事务处理模块(BEGIN/COMMIT)中才能生效。用法如下:

#开始事务
begin;
#悲观锁
select col1 from table where id=1 for update;
#处理其他业务
#...
#提交事务
commit;

悲观锁虽然保证了串行化,但是每次请求都会申请锁,很容易因为大量的请求导致数据库的不可用。

redis

redis – 分布式锁

zookeeper

zookeeper之分布式锁

etcd

对比

从性能上来说,redis>etcd>zookeeper>数据库,从cap模型来说,redis是ap模型,zookeeper、etcd是cp模型,数据库是ac模型(做主从就是ap)。

从业务来说,比如对钱的操作,需要强一致性的,那要用cp模型的分布式锁,比如zookeeper,etcd。如果不需要强一致性的,允许偶尔的数据问题,那可以用redis。数据只适合在并发比较小的情况下用。

罗罗计划为英国建设16座小型模块化核反应堆

上一篇

🏆 技术专题第七期 |万物皆可 Serverless

下一篇

你也可能喜欢

分布式锁

长按储存图像,分享给朋友