分布式理论之分布式锁

news2024/11/24 4:39:42

写在前面

在分布式理论之分布式互斥一文中我们分析了分布式环境中的分布式互斥问题,其中解决该问题有如下的三种方案：

1：集中式算法
2：分布式算法
3：令牌环算法

而本文要分析的分布式锁，就是其中的算法1，接下来我们一起看下。

1：为什么需要分布式锁

当分布式集群中的多个应用实例同时访问某临界资源时，如果是不加以控制，以共享的方式访问，则可能会出现数据一致性的问题，比如当前库存量为3，同时有两个服务要-1，最终应该是1，但如果是二者同时拿到库存量3，然后各自-1后写回，则最终结果就是2，就出现了数据一致性的问题，所以我们这里需要分布式锁。

2：具体方案

目前实现分布式锁，主要有如下3中方案：

1：基于DB的唯一索引实现
2：基于缓存实现
3：基于zookeeper实现

分别来看下。

2.1：基于DB的唯一索引实现

实现思路是，在数据库中创建一张表，除主键外额外创建一个唯一索引字段，当有多个连接同时插入相同值时，只有一个连接可以插入成功，插入成功则代表获取了锁，待执行完毕后将该数据delete掉释则会放锁，这种方式的优点是门槛低，实现简单，缺点如下：

1：单点问题，当DB宕机或不可用，应用也将阻塞不可用
2：死锁问题，客户端异常中断或数据删除失败，将导致锁不能被释放，其他应用将无法获取锁
3：并发量低，DB天生不支持高并发，所以这里也有此问题

2.2：基于缓存实现

这里我们一般都是基于Redis来使用，因为其具有支持高并发访问的特点，具体实现方法参考这篇文章，优点是并发性能好，缺点如下：

1：锁等待，当获取锁线程异常终止，或者释放锁失败的话则只能等待锁过期自动删除
2：锁丢失，当锁所在实例宕机，则可能造成锁丢失，即使有主从，如果是数据还没有同步到从节点，同样会发生锁丢失

对于1我们基于zookeeper的方案可以解决，对于2则可以考虑使用redlock，redlock是要求在一组Redis实例分别执行setnx操作，只有超过半数设置成功才算加锁成功，同样的，要释放锁的话，需要在所有的实例上都执行del key操作释放锁，但是这种方式需要在多实例分别操作，会影响到并发性，但是可靠性更高。