分布式锁的实现方式

发布时间:2024年01月24日

分布式锁是指分布式环境下,系统部署在多个机器中,实现多进程分布式互斥的一种锁。实现分布式锁有三种主流方式,接下来一一盘点。

盘点之前要说说选择时的优缺点

数据库实现的锁表完全不推荐。
Redis分布式锁性能优于ZooKeeper,因为不需要反复创建节点。
实现的简单程度和可靠性ZooKeeper更好,因为其封装好的框架几乎能应对所有的分布式锁问题。

基于数据库实现的——锁表

实际上就是开一个表。当我们要锁住某个资源时,就在该表中增加一条记录,想要释放锁的时候就删除这条记录。但数据库表要磁盘io,所以效率很低。并且一旦这个数据库寄了,那系统崩了。数据库锁没有失效时间,未获得锁的进程只能一直等待已获得锁的进程主动释放锁。倘若已获得共享资源访问权限的进程突然挂掉、或者解锁操作失败,使得锁记录一直存在数据库中,无法被删除,而其他进程也无法获得锁,从而产生死锁现象。

基于缓存实现的——缓存锁

就是说把数据存放在计算机内存中,不需要写入磁盘,减少了IO读写,实现时候是维护一个队列来维持进程访问共享资源的顺序的。
Redis的setnx和delete方法就支持这一方式。

也存在缺陷,因为进程没法主动释放锁,假设ABC三个进程来,A完事了到B,B进程对应的服务器坏了,那C就得等B超时自动释放才能访问共享资源。通过超时时间来控制锁的失效时间,并不是十分靠谱,因为一个进程执行时间可能比较长,或受系统进程做内存回收等影响,导致时间超时,从而不正确地释放了锁。

ZooKeeper

ZooKeeper基于树形数据存储结构实现分布式锁,ZooKeeper的树形数据存储结构主要由4种节点构成:

  • 持久节点(PERSISTENT)。这是默认的节点类型,一直存在于ZooKeeper中。
  • 持久顺序节点(PERSISTENT_SEQUENTIAL)。在创建节点时,ZooKeeper根据节点创建的时间顺序对节点进行编号命名。
  • 临时节点(EPHEMERAL)。当客户端与Zookeeper连接时临时创建的节点。与持久节点不同,当客户端与ZooKeeper断开连接后,该进程创建的临时节点就会被删除。
  • 临时顺序节点(EPHEMERAL_SEQUENTIAL)。就是按时间顺序编号的临时节点。

ZooKeeper是根据临时顺序节点来实现的分布式锁。以电商售卖吹风机的场景为例。假设用户A、B、C同时在11月11日的零点整提交了购买吹风机的请求,ZooKeeper会为每个进程分配一个临时顺序节点。每个节点都有一个监听器监听当前自己是不是序号最小的**(理论上要监听共享资源上的所有节点,实际上只要监听自己上一个节点的状态就行)**,是就去访问共享资源,不是就判断:

  • 假设一个进程要读,前面有写的话,就得等待;假设前面没有写的,就可以并发读。
  • 假设一个进程要写,前面有进程在就得等待。
    在这里插入图片描述
文章来源:https://blog.csdn.net/pige666/article/details/135830236
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。