分布式锁架构设计方案 -02

Posted 2021-04-10 互联网后端架构

在上一篇博文：，我为大家详细介绍了如何实现一个完善、高性能的基于Redis的分布式锁方案，相信大家应该都能有所裨益。然后，在实际开发过程中，之前的方案还是存在一些问题，虽然我们习惯性的将它称之为分布式锁，但从严格意义上来说却并不算，因为这仅仅只是一个依托于分布式组件作为载体来实现的单点锁，换句话说，锁的容错性较差，一旦目标Redis节点宕机，或者产生网络抖动都有可能导致客户端无法顺利加锁而导致业务异常；甚至还有可能因主/从切换引发安全问题（比如客户端A、B同时获取到目标锁资源）的情况出现(因此不建议增加slave节点)，因为这是一个彻彻底底的单点问题，是无法简单通过横扩Redis集群节点就能够解决的。



那么实现一个完善的分布式锁，则必须要同时满足以下3个特性：

• 容错性：避免单点问题；

• 可用性：避免产生死锁；

• 互斥性：锁资源未释放之前，其它客户端不得进行加锁。

RedLock架构

我们都知道Zookeeper是一个典型的CP系统，是一个基于ZAB(Zookeeper Atomic Broadcast，原子广播)协议的强一致性中间件，当我们向leader写入数据时，会由leader负责向集群中的其他follower节点同步数据，当 > 半数以上集群节点同步确认完成后，一次数据写入操作才算是成功。那么基于类似这样的思想，Redis社区提出了RedLock算法。



RedLock的核心思想是什么？简而言之，我们首先需要部署N个单点Redis，务必保证这些Redis节点之间是完全相互独立的，没必要存在任何主/从复制，以及集群协调机制的介入；当客户端在尝试加锁时，需要满足同时至少

>=(N>>1)+1

个Redis节点上都顺利加锁成功，才代表一次分布式加锁操作是成功的，反之加锁失败。通过这样的保障机制，则可以有效提升分布式锁的容错性和满足安全性，以及互斥性需求。

redlock整体架构

在此大家需要注意，在实现RedLock时需要遵守如下5个约定：

 
   
   
 

  
    
    
  以毫秒为单位获取当前时间；
 
   
   
 
以上是关于分布式锁架构设计方案 -02的主要内容，如果未能解决你的问题，请参考以下文章
 
 秒杀系统——秒杀功能设计理念
 分布式架构下实现分布式锁使用数据库方案 Zookeeper分布式锁Redis分布式锁
 分布式锁设计方案
 解析分布式锁之Redis实现
 架构设计 | 基于Seata中间件，微服务模式下事务管理
 分布式——补充的一些东西（就业相关的）秒杀的设计方案分布式id生成方案分布式锁分布式锁的三种实现方式（基于数据库RedisZookeeper）