建议：分布式锁。

叁歲伎倆 2022-02-18 13:15 83阅读 0赞

# 前言 #

**      由于在平时的工作中，线上服务器是分布式多台部署的，经常会面临解决分布式场景下数据一致性的问题，那么就要利用分布式锁来解决这些问题。所以自己结合实际工作中的一些经验和网上看到的一些资料，做一个讲解和总结。希望这篇文章可以方便自己以后查阅，同时要是能帮助到他人那也是很好的。**

# 正文 #

## 自身的业务场景 ##

在我日常做的项目中，目前涉及了以下这些业务场景:

**场景一:** 比如分配任务场景。在这个场景中，由于是公司的业务后台系统，主要是用于审核人员的审核工作，并发量并不是很高，而且任务的分配规则设计成了通过审核人员每次主动的请求拉取，然后服务端从任务池中随机的选取任务进行分配。这个场景看到这里你会觉得比较单一，但是实际的分配过程中，由于涉及到了按用户聚类的问题，所以要比我描述的复杂，但是这里为了说明问题，大家可以把问题简单化理解。那么在使用过程中，主要是为了避免同一个任务同时被两个审核人员获取到的问题。**我最终使用了基于数据库资源表的分布式锁来解决的问题。**

**场景二:** 比如支付场景。在这个场景中，我提供给用户三个用于保护用户隐私的手机号码(这些号码是从运营商处获取的，和真实手机号码看起来是一样的)，让用户选择其中一个进行购买，用户购买付款后，我需要将用户选择的号码分配给用户使用，同时也要将没有选择的释放掉。在这个过程中，给用户筛选的号码要在一定时间内(用户筛选正常时间范围内)让当前用户对这个产品具有独占性，以便保证付款后是100%可以拿到；同时由于产品资源池的资源有限，还要保持资源的流动性，即不能让资源长时间被某个用户占用着。对于服务的设计目标，一期项目上线的时候至少能够支持峰值qps为300的请求，同时在设计的过程中要考虑到用户体验的问题。**我最终使用了memecahed的add()方法和基于数据库资源表的分布式锁来解决的问题。**

**场景三:** 我有一个数据服务，每天调用量在3亿，每天按86400秒计算的qps在4000左右，由于服务的白天调用量要明显高于晚上，所以白天下午的峰值qps达到6000的，一共有4台服务器，单台qps要能达到3000以上。**我最终使用了redis的setnx()和expire()的分布式锁解决的问题。**

**       场景四:**场景一和场景二的升级版。在这个场景中，不涉及支付。但是由于资源分配一次过程中，需要保持涉及一致性的地方增加，而且一期的设计目标要达到峰值qps500，所以需要我们对场景进一步的优化。**我最终使用了redis的setnx()、expire()和基于数据库表的分布式锁来解决的问题。**

看到这里，不管你觉得我提出的业务场景qps是否足够大，都希望你能继续看下去，因为无论你身处一个什么样的公司，最开始的工作可能都需要从最简单的做起。不要提阿里和腾讯的业务场景qps如何大，因为在这样的大场景中你未必能亲自参与项目，亲自参与项目未必能是核心的设计者，是核心的设计者未必能独自设计。如果能真能满足以上三条，关闭页面可以不看啦，如果不是的话，建议还是看完，我有说的不足的地方欢迎提出建议，我说的好的地方，也希望给我点个赞或者评论一下，算是对我最大的鼓励哈。

## 分布式锁的解决方式 ##

*  首先明确一点，有人可能会问是否可以考虑采用ReentrantLock来实现，但是实际上去实现的时候是有问题的，ReentrantLock的lock和unlock要求必须是在同一线程进行，而分布式应用中，lock和unlock是两次不相关的请求，因此肯定不是同一线程，因此导致无法使用ReentrantLock。
 *  基于数据库表做乐观锁，用于分布式锁。
 *  使用memcached的add()方法，用于分布式锁。
 *  使用memcached的cas()方法，用于分布式锁。(不常用) 
 *  使用redis的setnx()、expire()方法，用于分布式锁。
 *  使用redis的setnx()、get()、getset()方法，用于分布式锁。
 *  使用redis的watch、multi、exec命令，用于分布式锁。(不常用) 
 *  使用zookeeper，用于分布式锁。(不常用)

## 基于数据库资源表做乐观锁，用于分布式锁: ##

### 乐观锁的含义 ###

大多数是基于数据版本(version)的记录机制实现的。何谓数据版本号？即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表添加一个 “version”字段来实现读取出数据时，将此版本号一同读出，之后更新时，对此版本号加1。

在更新过程中，会对版本号进行比较，如果是一致的，没有发生改变，则会成功执行本次操作；如果版本号不一致，则会更新失败。

### 具体的例子，我们来推演下我们应该怎么处理 ###

*  假设我们有一张资源表，如下图所示: t\_resource , 其中有6个字段id, resoource,  state, add\_time, update\_time, version,分别表示表主键、资源、分配状态(1未分配  2已分配)、资源创建时间、资源更新时间、资源数据版本号。

![437162-20160604181422055-1240923233.jpg][]

*  假设我们现在我们对id=5780这条数据进行分配，那么非分布式场景的情况下，我们一般先查询出来state=1(未分配)的数据，然后从其中选取一条数据可以通过以下语句进行，如果可以更新成功，那么就说明已经占用了这个资源

update t_resource set state=2 where state=1 and id=5780。

*  如果在分布式场景中，由于数据库的update操作是原子是原子的，其实上边这条语句理论上也没有问题，但是这条语句如果在典型的“ABA”情况下，我们是无法感知的。有人可能会问什么是“ABA”问题呢？大家可以网上搜索一下，这里我说简单一点就是，如果在你第一次select和第二次update过程中，由于两次操作是非原子的，所以这过程中，如果有一个线程，先是占用了资源(state=2)，然后又释放了资源(state=1)，实际上最后你执行update操作的时候，是无法知道这个资源发生过变化的。也许你会说这个在你说的场景中应该也还好吧，但是在实际的使用过程中，比如银行账户存款或者扣款的过程中，这种情况是比较恐怖的。
 *  那么如果使用乐观锁我们如何解决上边的问题呢？

a. 先执行select操作查询当前数据的数据版本号,比如当前数据版本号是26：

select id, resource, state,version from t_resource  where state=1 and id=5780;

b. 执行更新操作：

update t_resoure set state=2, version=27, update_time=now() where resource=xxxxxx and state=1 and version=26

c. 如果上述update语句真正更新影响到了一行数据，那就说明占位成功。如果没有更新影响到一行数据，则说明这个资源已经被别人占位了。

### 基于数据库表做乐观锁的一些缺点 ###

*  这种操作方式，使原本一次的update操作，必须变为2次操作: select版本号一次；update一次。增加了数据库操作的次数。
 *  如果业务场景中的一次业务流程中，多个资源都需要用保证数据一致性，那么如果全部使用基于数据库资源表的乐观锁，就要让每个资源都有一张资源表，这个在实际使用场景中肯定是无法满足的。而且这些都基于数据库操作，在高并发的要求下，对数据库连接的开销一定是无法忍受的。
 *  乐观锁机制往往基于系统中的数据存储逻辑，因此可能会造成脏数据被更新到数据库中。在系统设计阶段，我们应该充分考虑到这些情况出现的可能性，并进行相应调整，如将乐观锁策略在数据库存储过程中实现，对外只开放基于此存储过程的数据更新途径，而不是将数据库表直接对外公开。

### 讲了乐观锁的实现方式和缺点，是不是会觉得不敢使用乐观锁了呢？？ ###

当然不是，在文章开头我自己的业务场景中，场景1和场景2的一部分都使用了基于数据库资源表的乐观锁，已经很好的解决了线上问题。所以大家要根据的具体业务场景选择技术方案，并不是随便找一个足够复杂、足够新潮的技术方案来解决业务问题就是好方案？！比如，如果在我的场景一中，我使用zookeeper做锁，可以这么做，但是真的有必要吗？？？答案觉得是没有必要的！！！

## 使用memcached的add()方法，用于分布式锁 ##

**      **对于使用memcached的add()方法做分布式锁，这个在互联网公司是一种比较常见的方式，而且基本上可以解决自己手头上的大部分应用场景。在使用这个方法之前，只要能搞明白memcached的add()和set()的区别，并且知道为什么能用add()方法做分布式锁就好。如果还不知道add()和set()方法，请直接百度吧，这个需要自己了解一下。

我在这里想说明的是另外一个问题，人们在关注分布式锁设计的好坏时，还会重点关注这样一个问题，那就是是否可以避免死锁问题？？？！！！

**     ** 如果使用memcached的add()命令对资源占位成功了，那么是不是就完事儿了呢？当然不是！我们需要在add()的使用指定当前添加的这个key的有效时间，如果不指定有效时间，正常情况下，你可以在执行完自己的业务后，使用delete方法将这个key删除掉，也就是释放了占用的资源。但是，如果在占位成功后，memecached或者自己的业务服务器发生宕机了，那么这个资源将无法得到释放。所以通过对key设置超时时间，即便发生了宕机的情况，也不会将资源一直占用，可以避免死锁的问题。

## 使用memcached的cas()方法，用于分布式锁 ##

## 使用redis的setnx()、expire()方法，用于分布式锁 ##

**     ** 对于使用redis的setnx()、expire()来实现分布式锁，这个方案相对于memcached()的add()方案，redis占优势的是，其支持的数据类型更多，而memcached只支持String一种数据类型。除此之外，无论是从性能上来说，还是操作方便性来说，其实都没有太多的差异，完全看你的选择，比如公司中用哪个比较多，你就可以用哪个。

**首先说明一下setnx()命令，**setnx的含义就是SET if Not Exists，其主要有两个参数 setnx(key, value)。该方法是原子的，如果key不存在，则设置当前key成功，返回1；如果当前key已经存在，则设置当前key失败，返回0。但是要注意的是setnx命令不能设置key的超时时间，只能通过expire()来对key设置。

### 使用步骤 ###

1.  setnx(lockkey, 1)  如果返回0，则说明占位失败；如果返回1，则说明占位成功
2.  expire()命令对lockkey设置超时时间，为的是避免死锁问题。
3.  执行完业务代码后，可以通过delete命令删除key。

这个方案其实是可以解决日常工作中的需求的，但从技术方案的探讨上来说，可能还有一些可以完善的地方。**比如，如果在第一步setnx执行成功后，在expire()命令执行成功前，发生了宕机的现象，那么就依然会出现死锁的问题，所以如果要对其进行完善的话，可以使用redis的setnx()、get()和getset()方法来实现分布式锁。****  **

## 使用redis的setnx()、get()、getset()方法，用于分布式锁 ##

**     ** 这个方案的背景主要是在setnx()和expire()的方案上针对可能存在的死锁问题，做了一版优化。

**那么先说明一下这三个命令，对于setnx()和get()这两个命令，相信不用再多说什么。那么getset()命令？**这个命令主要有两个参数 getset(key，newValue)。该方法是原子的，对key设置newValue这个值，并且返回key原来的旧值。假设key原来是不存在的，那么多次执行这个命令，会出现下边的效果：

1.  getset(key, "value1")  返回nil   此时key的值会被设置为value1
2.  getset(key, "value2")  返回value1   此时key的值会被设置为value2
3.  依次类推！

### 使用步骤 ###

1.  setnx(lockkey, 当前时间+过期超时时间)** **，如果返回1，则获取锁成功；如果返回0则没有获取到锁，转向2。
2.  get(lockkey)获取值oldExpireTime ，并将这个value值与当前的系统时间进行比较，如果小于当前系统时间，则认为这个锁已经超时，可以允许别的请求重新获取，转向3。
3.  计算newExpireTime=当前时间+过期超时时间，然后getset(lockkey, newExpireTime) 会返回当前lockkey的值currentExpireTime。
4.  判断currentExpireTime与oldExpireTime 是否相等，如果相等，说明当前getset设置成功，获取到了锁。如果不相等，说明这个锁又被别的请求获取走了，那么当前请求可以直接返回失败，或者继续重试。
5.  在获取到锁之后，当前线程可以开始自己的业务处理，当处理完毕后，比较自己的处理时间和对于锁设置的超时时间，如果小于锁设置的超时时间，则直接执行delete释放锁；如果大于锁设置的超时时间，则不需要再锁进行处理。

注意: 这个方案我当初在线上使用的时候是没有问题的，所以当初写这篇文章时也认为是没有问题的。但是截止到2017.05.13(周六)，自己在重新回顾这篇文章时，看了文章下网友的很多评论，我发现有两个问题比较集中:

**问题1:**  在“get(lockkey)获取值oldExpireTime ”这个操作与“getset(lockkey, newExpireTime) ”这个操作之间，如果有N个线程在get操作获取到相同的oldExpireTime后，然后都去getset，会不会返回的newExpireTime都是一样的，都会是成功，进而都获取到锁？？？

我认为这套方案是不存在这个问题的。依据有两条: 第一，redis是单进程单线程模式，串行执行命令。 第二，在串行执行的前提条件下，getset之后会比较返回的currentExpireTime与oldExpireTime 是否相等。

** 问题2:** 在“get(lockkey)获取值oldExpireTime ”这个操作与“getset(lockkey, newExpireTime) ”这个操作之间，如果有N个线程在get操作获取到相同的oldExpireTime后，然后都去getset，假设第1个线程获取锁成功，其他锁获取失败，但是获取锁失败的线程它发起的getset命令确实执行了，这样会不会造成第一个获取锁的线程设置的锁超时时间一直在延长？？？

我认为这套方案确实存在这个问题的可能。但我个人认为这个微笑的误差是可以忽略的，不过技术方案上存在缺陷，大家可以自行抉择。

## 使用redis的watch、multi、exec命令，用于分布式锁 ##

## 使用zookeeper，用于分布式锁 ##

### 使用zookeeper节点名称唯一性，用于分布式锁 ###

**      关于zookeeper集群的搭建，可以参考一篇文章: [ZooKeeper1 利用虚拟机搭建自己的ZooKeeper集群][ZooKeeper1 _ZooKeeper]**

**     ** zookeeper抽象出来的节点结构是一个和文件系统类似的小型的树状的目录结构，同时zookeeper机制规定：同一个目录下只能有一个唯一的文件名。例如：我们在zookeeper的根目录下，由两个客户端同时创建一个名为/myDistributeLock，只有一个客户端可以成功。

上述方案和memcached的add()方法、redis的setnx()方法实现分布式锁有着相同的思路。这样的方案实现起来如果不考虑搭建和维护zookeeper集群的成本，由于正确性和可靠性是zookeeper机制自己保证的，实现还是比较简单的。

### 使用zookeeper临时顺序节点，用于分布式锁 ###

在讨论这套方案之前，我们有必要先“吹毛求疵”般的说明一下使用zookeeper节点名称唯一性来做分布式锁这个方案的缺点。比如，当许多线程在等待一个锁时，如果锁得到释放的时候，那么所有客户端都被唤醒，但是仅仅有一个客户端得到锁。在这个过程中，大量的线程根本没有获得锁的可能性，但是也会引起大量的上下文切换，这个系统开销也是不小的，对于这样的现象有一个专业名词，称之为“惊群效应”。

我们首先说明一下zookeeper的顺序节点、临时节点和watcher机制:

*  **所谓顺序节点**，假如我们在/myDisLocks/目录下创建3个节点，zookeeper集群会按照发起创建的顺序来创建节点，节点分别为/myDisLocks/0000000001、/myDisLocks/0000000002、/myDisLocks/0000000003。
 *  **所谓临时节点**，临时节点由某个客户端创建，当客户端与zookeeper集群断开连接，则该节点自动被删除。
 *  **所谓对于watcher机制**，大家可以参考[Apache ZooKeeper Watcher机制源码解释][Apache ZooKeeper Watcher]。当然如果你之前不知道watcher机制是个什么东东，不建议你直接去看前边我提供的文章链接，这样你极有可能忘掉我们的讨论主线，即分布式锁的实现方案，而陷入到watcher机制的源码实现中。所以你也可以先看看下面的具体方案，猜测一下watcher是用来干嘛的，我这里先总结一句话做个引子: 所谓watcher机制，你可以简单一点儿理解成任何一个连接zookeeper的客户端可以通过watcher机制关注自己感兴趣的节点的增删改查，当这个节点发生增删改查的操作时，会“广播”自己的消息，所有对此感兴趣的节点可以在收到这些消息后，根据自己的业务需要执行后续的操作。

具体的使用步骤如下:

1.  每个业务线程调用create()方法创建名为“/myDisLocks/thread”的节点，需要注意的是，这里节点的创建类型需要设置为EPHEMERAL\_SEQUENTIAL，即节点类型为临时顺序节点。此时/myDisLocks节点下会出现诸如/myDisLocks/thread0000000001、/myDisLocks/thread0000000002、/myDisLocks/thread0000000003这样的子节点。
2.  每个业务线程调用getChildren(“myDisLocks”)方法来获取/myDisLocks这个节点下所有已经创建的子节点。
3.  每个业务线程获取到所有子节点的路径之后，如果发现自己在步骤1中创建的节点的尾缀编号是所有节点中序号最小的，那么就认为自己获得了锁。
4.  如果在步骤3中发现自己并非是所有子节点中序号最小的，说明自己还没有获取到锁。使用watcher机制监视比自己创建节点的序列号小的节点（比自己创建的节点小的最大节点），进入等待。比如，如果当前业务线程创建的节点是/myDisLocks/thread0000000003，那么在没有获取到锁的情况下，他只需要监视/myDisLocks/thread0000000002的情况。只有当/myDisLocks/thread0000000002获取到锁并释放之后，当前业务线程才启动获取锁，这样可以避免一个业务线程释放锁之后，其他所有线程都去竞争锁，引起不必要的上下文切换，最终造成“惊群现象”。
5.  释放锁的过程相对比较简单，就是删除自己创建的那个子节点即可。

**      ****注意:** 这个方案实现的分布式锁还带着一点儿公平锁的味道！为什么呢？我们在利用每个节点的序号进行排队以此来避免进群现象时，实际上所有业务线程获得锁的顺序就是自己创建节点的顺序，也就是哪个业务线程先来，哪个就可以最快获得锁。

注意：使用上述文章中的”临时节点+watcher机制方案”解决一个分布式锁的问题时，最终发现在实现过程中，由于watcher机制类似于通知等待机制的特点，如果主线程在经历“获取锁操作”、“处理业务代码”、“释放锁操作”这三步的过程中，使用watcher机制阻塞的获取锁时，会导致根本无法将获取锁结果返回给主线程，而在实际的时候过程中，一般情况下主线程在“获取锁操作”时都希望可以同步获得一个返回值。

所以，上述的”临时节点+watcher机制方案”从技术方案角度足够完美，但是在实际使用过程中，个人觉得还不是特别的方便。

# 总结 #

综上，关于分布式锁的第一篇文章我就写到这儿了，在文章中主要说明了日常项目中会比较常用到四种方案，大家掌握了这四种方案，其实在日常的工作中就可以解决很多业务场景下的分布式锁的问题。从文章开头我自己的实际使用中，也可以看到，这么说完全是有一定的依据。对于另外那三种方案，我会在下一篇关于分布式锁的文章中，和大家再探讨一下。

## 常用的四种方案 ##

*  基于数据库表做乐观锁，用于分布式锁。
 *  使用memcached的add()方法，用于分布式锁。
 *  使用redis的setnx()、expire()方法，用于分布式锁。
 *  使用redis的setnx()、get()、getset()方法，用于分布式锁。

## 不常用但是可以用于技术方案探讨 ##

*  使用memcached的cas()方法，用于分布式锁。 
 *  使用redis的watch、multi、exec命令，用于分布式锁。
 *  使用zookeeper，用于分布式锁。

转载：[https://www.cnblogs.com/PurpleDream/p/5559352.html][https_www.cnblogs.com_PurpleDream_p_5559352.html]

[437162-20160604181422055-1240923233.jpg]: /images/20220218/5feb0c34c22f4068b4c92012760c264f.png
[ZooKeeper1 _ZooKeeper]: http://www.cnblogs.com/PurpleDream/p/4823724.html
[Apache ZooKeeper Watcher]: https://www.ibm.com/developerworks/cn/opensource/os-cn-apache-zookeeper-watcher/
[https_www.cnblogs.com_PurpleDream_p_5559352.html]: https://www.cnblogs.com/PurpleDream/p/5559352.html