分布式锁实现方法和装置

摘要

本发明公开了一种分布式锁实现方法和装置，其中，方法包括：S1，在同一时间段内接收来自多个客户端的相同的业务请求；S2，运行与业务请求对应的脚本文件，并生成对应的业务标识；以及S3，根据业务标识确定执行业务请求对应的业务的客户端。本发明实施例的分布式锁实现方法和装置，通过在同一时间段内接收来自多个客户端的相同的业务请求，运行与业务请求对应的脚本文件，并生成对应的业务标识，以及根据业务标识确定执行业务请求对应的业务的客户端，能够避免来自多个客户端的相同业务被重复执行的问题，节省了资源，提升了服务器性能。

权利要求

1.一种分布式锁实现方法，其特征在于，包括以下步骤：S1，在同一时间段内接收来自多个客户端针对同一账号的相同的业务请求，所述业务请求包括心跳包；

S2，针对每一个客户端发送的心跳包运行相同的脚本文件，并为每一个客户端生成对应的业务标识，所述业务标识包括未获取分布式锁的业务标识和获取分布式锁的业务标识；以及S3，根据所述业务标识将获取分布式锁的业务标识的客户端上的用户设置为在线状态。

2.如权利要求1所述的方法，其特征在于，所述脚本文件为分布式锁LUA脚本。

3.如权利要求1所述的方法，其特征在于，针对每一个客户端发送的心跳包运行相同的脚本文件，并为每一个客户端生成对应的业务标识，包括：判断当前是否存在正在执行的业务；

若存在正在执行的业务，则生成未获取分布式锁的业务标识；

若不存在正在执行的业务，则生成获取分布式锁的业务标识。

4.如权利要求3所述的方法，其特征在于，在生成获取分布式锁的业务标识时，还包括：设置分布式锁的失效时间。

5.一种分布式锁实现装置，其特征在于，包括：接收模块，用于在同一时间段内接收来自多个客户端针对同一账号的相同的业务请求，所述业务请求包括心跳包；

运行模块，用于针对每一个客户端发送的心跳包运行相同的脚本文件，并为每一个客户端生成对应的业务标识，所述业务标识包括未获取分布式锁的业务标识和获取分布式锁的业务标识；以及确定模块，用于根据所述业务标识将获取分布式锁的业务标识的客户端上的用户设置为在线状态。

6.如权利要求5所述的装置，其特征在于，所述脚本文件为分布式锁LUA脚本。

7.如权利要求5所述的装置，其特征在于，所述运行模块，用于：判断当前是否存在正在执行的业务；

若存在正在执行的业务，则生成未获取分布式锁的业务标识；

若不存在正在执行的业务，则生成获取分布式锁的业务标识。

8.如权利要求7所述的装置，其特征在于，所述装置还包括：设置模块，用于在生成获取分布式锁的业务标识时，设置分布式锁的失效时间。

说明书

分布式锁实现方法和装置

技术领域

[0001] 本发明涉及计算机技术领域，尤其涉及一种分布式锁实现方法和装置。

背景技术

[0002] 目前，即时通讯类软件均支持多个客户端同时登录，例如：QQ软件，可支持手机客户端、平板电脑客户端、PC客户端同时登录，方便了用户的使用。但是随之而来的问题是，如
果多个客户端同时向服务器发送相同的业务请求，例如发送心跳包，服务器无法确定该业
务请求来自哪一个客户端，可能会产生重复执行业务的问题，造成了资源的浪费，导致服务
器性能降低。

发明内容

[0003] 本发明旨在至少在一定程度上解决相关技术中的技术问题之一。为此，本发明的一个目的在于提出一种分布式锁实现方法，能够避免来自多个客户端的相同业务被重复执
行的问题，节省了资源，提升了服务器性能。

[0004] 本发明的第二个目的在于提出一种分布式锁实现装置。

[0005] 为了实现上述目的，本发明第一方面实施例提出了一种分布式锁实现方法，包括：S1，在同一时间段内接收来自多个客户端的相同的业务请求；S2，运行与所述业务请求对应
的脚本文件，并生成对应的业务标识；以及S3，根据所述业务标识确定执行所述业务请求对
应的业务的客户端。

[0006] 本发明实施例的分布式锁实现方法，通过在同一时间段内接收来自多个客户端的相同的业务请求，运行与业务请求对应的脚本文件，并生成对应的业务标识，以及根据业务
标识确定执行业务请求对应的业务的客户端，能够避免来自多个客户端的相同业务被重复
执行的问题，节省了资源，提升了服务器性能。

[0007] 本发明第二方面实施例提出了一种分布式锁实现装置，包括：接收模块，用于在同一时间段内接收来自多个客户端的相同的业务请求；运行模块，用于运行与所述业务请求
对应的脚本文件，并生成对应的业务标识；以及确定模块，用于根据所述业务标识确定执行
所述业务请求对应的业务的客户端。

[0008] 本发明实施例的分布式锁实现装置，通过在同一时间段内接收来自多个客户端的相同的业务请求，运行与业务请求对应的脚本文件，并生成对应的业务标识，以及根据业务
标识确定执行业务请求对应的业务的客户端，能够避免来自多个客户端的相同业务被重复
执行的问题，节省了资源，提升了服务器性能。

附图说明

[0009] 图1是根据本发明一个实施例的分布式锁实现方法的流程图。

[0010] 图2是根据本发明一个实施例的分布式系统框架示意图。

[0011] 图3是根据本发明一个实施例的分布式锁实现装置的结构示意图。

具体实施方式

[0012] 下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附
图描述的实施例是示例性的，旨在用于解释本发明，而不能理解为对本发明的限制。

[0013] 下面参考附图描述本发明实施例的分布式锁实现方法和装置。

[0014] 图1是根据本发明一个实施例的分布式锁实现方法的流程图。

[0015] 如图1所示，分布式锁实现方法可包括：

[0016] S1，在同一时间段内接收来自多个客户端的相同的业务请求。

[0017] 其中，业务请求主要为针对同一账号，相同的业务请求，如发送心跳包。

[0018] 举例来说，用户A在使用QQ时，可通过手机客户端、PC客户端、平板电脑客户端等同时登录。在登录时，会发送相同的心跳包，通常为三秒一次。REDIS服务器在三秒之内接收到
多个来自不同客户端的心跳包之后，可将用户A设置为在线状态。在现有技术中，服务器无
法确认接收到的心跳包来自哪个客户端，也就是说三秒之内多次设置用户在线，造成了资
源的浪费。而在本发明的一个实施例中，可利用REDIS服务器的单线程特性，在三秒之内只
需设置一次用户在线即可。其中，REDIS服务器的作用在于在一定时间段内，确定多个相同
的业务请求只需执行一次。

[0019] S2，运行与业务请求对应的脚本文件，并生成对应的业务标识。

[0020] 其中，脚本文件可为分布式锁LUA脚本。具体脚本逻辑如：判断当前是否存在正在执行的业务，若存在正在执行的业务，则生成未获取分布式锁的业务标识；若不存在正在执
行的业务，则生成获取分布式锁的业务标识。在生成获取分布式锁的业务标识的同时，还可
设置分布式锁的失效时间如三秒，即在三秒之后，该分布式锁失效，从而保证三秒之内只执
行一个业务。

[0021] 继续上例进行描述，REDIS服务器在三秒之内接收到了多个客户端发来的心跳包，REDIS服务器则针对每一个客户端发来的心跳包，运行相同的分布式锁LUA脚本，并为每一
个客户端生成对应的业务标识。业务标识可包括未获取分布式锁的业务标识和获取分布式
锁的业务标识。也就是说，多个客户端在三秒之内发送的心跳包，只有一个能够获得分布式
锁，其他的则无法获得分布式锁。

[0022] S3，根据业务标识确定执行业务请求对应的业务的客户端。

[0023] 具体地，当业务标识为未获取分布式锁时，REDIS服务器可控制对应的客户端不执行业务请求对应的业务；当业务标识为已获取分布式锁时，REDIS服务器可控制对应的客户
端执行业务请求对应的业务。也就是说，多个客户端在同一时间段内向REDIS服务器发送业
务请求，而在该时间段内只允许执行一次对应的业务，即多个客户端中只有一个能够获取
分布式锁。则获取分布式锁的客户端执行对应的业务，而其他未获取分布式锁的客户端则
不执行对应的业务。

[0024] 下面通过一个具体的实施例进行描述。图2是一个分布式系统框架示意图。如图2所示，集群中可包括多个客户端，客户端在3秒之内向REDIS服务器发送相同的业务请求，而
REDIS服务器在接收到上述业务请求后，可执行业务请求对应的脚本。

[0025] 具体脚本内容如下：

[0026] --用户ID Key

[0027] local userKey＝ARGV[1]

[0028] --失效时间

[0029] local expireMilliseconds＝ARGV[2]

[0030] --如果不存在Key，更新Key，同时设置失效时间

[0031] local flag＝redis.call("EXISTS",userKey)

[0032] local time＝redis.call("PTTL",userKey)

[0033] if(time<0or time>3000)then

[0034]      redis.call("PSETEX",userKey,expireMilliseconds,"")

[0035] end

[0036] return flag

[0037] 该脚本逻辑如下：判断当前是否存在用户对应的KEY，即针对该用户是否存在正在执行的业务。如果存在用户对应的KEY，说明分布式锁正在被占用(其中，锁的失效时间是三
秒)，则可向发送业务请求的客户端返回“错误”结果，即未获取分布式锁，从而使客户端不
执行当前业务。如果不存在用户对应的KEY，说明分布式锁未被占用，则可生成一个新的
KEY，并为其设置失效时间三秒，即给客户端分配一个分布式锁，客户端可执行当前业务。设
置失效时间的作用在于，在该时间段内可避免执行其他相同的业务。

[0038] 本发明实施例的分布式锁实现方法，通过在同一时间段内接收来自多个客户端的相同的业务请求，运行与业务请求对应的脚本文件，并生成对应的业务标识，以及根据业务
标识确定执行业务请求对应的业务的客户端，能够避免来自多个客户端的相同业务被重复
执行的问题，节省了资源，提升了服务器性能。

[0039] 为实现上述目的，本发明还提出一种分布式锁实现装置。

[0040] 图3是根据本发明一个实施例的分布式锁实现装置的结构示意图。

[0041] 如图3所示，分布式锁实现装置可包括：接收模块110、运行模块120和确定模块130。

[0042] 接收模块110用于在同一时间段内接收来自多个客户端的相同的业务请求。其中，业务请求主要为针对同一账号，相同的业务请求，如发送心跳包。

[0043] 举例来说，用户A在使用QQ时，可通过手机客户端、PC客户端、平板电脑客户端等同时登录。在登录时，会发送相同的心跳包，通常为三秒一次。REDIS服务器在三秒之内接收到
多个来自不同客户端的心跳包之后，可将用户A设置为在线状态。在现有技术中，服务器无
法确认接收到的心跳包来自哪个客户端，也就是说三秒之内多次设置用户在线，造成了资
源的浪费。而在本发明的一个实施例中，可利用REDIS服务器的单线程特性，在三秒之内只
需设置一次用户在线即可。其中，REDIS服务器的作用在于在一定时间段内，确定多个相同
的业务请求只需执行一次。

[0044] 运行模块120用于运行与业务请求对应的脚本文件，并生成对应的业务标识。其中，脚本文件可为分布式锁LUA脚本。具体脚本逻辑如：判断当前是否存在正在执行的业务，
若存在正在执行的业务，则生成未获取分布式锁的业务标识；若不存在正在执行的业务，则
生成获取分布式锁的业务标识。

[0045] 继续上例进行描述，REDIS服务器在三秒之内接收到了多个客户端发来的心跳包，REDIS服务器则针对每一个客户端发来的心跳包，运行相同的分布式锁LUA脚本，并为每一
个客户端生成对应的业务标识。业务标识可包括未获取分布式锁的业务标识和获取分布式
锁的业务标识。也就是说，多个客户端在三秒之内发送的心跳包，只有一个能够获得分布式
锁，其他的则无法获得分布式锁。

[0046] 确定模块130用于根据业务标识确定执行业务请求对应的业务的客户端。具体地，当业务标识为未获取分布式锁时，确定模块130可控制对应的客户端不执行业务请求对应
的业务；当业务标识为已获取分布式锁时，确定模块130可控制对应的客户端执行业务请求
对应的业务。也就是说，多个客户端在同一时间段内向REDIS服务器发送业务请求，而在该
时间段内只允许执行一次对应的业务，即多个客户端中只有一个能够获取分布式锁。则获
取分布式锁的客户端执行对应的业务，而其他未获取分布式锁的客户端则不执行对应的业
务。

[0047] 此外，本发明一个实施例的分布式锁实现装置还可包括设置模块140。

[0048] 在生成获取分布式锁的业务标识的同时，设置模块140可设置分布式锁的失效时间如三秒，即在三秒之后，该分布式锁失效，从而保证三秒之内只执行一个业务。

[0049] 下面通过一个具体的实施例进行描述。图2是一个分布式系统框架示意图。如图2所示，集群中可包括多个客户端，客户端在3秒之内向REDIS服务器发送相同的业务请求，而
REDIS服务器在接收到上述业务请求后，可执行业务请求对应的脚本。

[0050] 具体脚本内容如下：

[0051] --用户ID Key

[0052] local userKey＝ARGV[1]

[0053] --失效时间

[0054] local expireMilliseconds＝ARGV[2]

[0055] --如果不存在Key，更新Key，同时设置失效时间

[0056] local flag＝redis.call("EXISTS",userKey)

[0057] local time＝redis.call("PTTL",userKey)

[0058] if(time<0or time>3000)then

[0059]      redis.call("PSETEX",userKey,expireMilliseconds,"")

[0060] end

[0061] return flag

[0062] 该脚本逻辑如下：判断当前是否存在用户对应的KEY，即针对该用户是否存在正在执行的业务。如果存在用户对应的KEY，说明分布式锁正在被占用(其中，锁的失效时间是三
秒)，则可向发送业务请求的客户端返回“错误”结果，即未获取分布式锁，从而使客户端不
执行当前业务。如果不存在用户对应的KEY，说明分布式锁未被占用，则可生成一个新的
KEY，并为其设置失效时间三秒，即给客户端分配一个分布式锁，客户端可执行当前业务。设
置失效时间的作用在于，在该时间段内可避免执行其他相同的业务。

[0063] 本发明实施例的分布式锁实现装置，通过在同一时间段内接收来自多个客户端的相同的业务请求，运行与业务请求对应的脚本文件，并生成对应的业务标识，以及根据业务
标识确定执行业务请求对应的业务的客户端，能够避免来自多个客户端的相同业务被重复
执行的问题，节省了资源，提升了服务器性能。

[0064] 在本发明的描述中，需要理解的是，术语“中心”、“纵向”、“横向”、“长度”、“宽度”、“厚度”、“上”、“下”、“前”、“后”、“左”、“右”、“竖直”、“水平”、“顶”、“底”“内”、“外”、“顺时针”、“逆时针”、“轴向”、“径向”、“周向”等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本发明和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本发明的限制。

[0065] 此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者
隐含地包括至少一个该特征。在本发明的描述中，“多个”的含义是至少两个，例如两个，三
个等，除非另有明确具体的限定。

[0066] 在本发明中，除非另有明确的规定和限定，术语“安装”、“相连”、“连接”、“固定”等术语应做广义理解，例如，可以是固定连接，也可以是可拆卸连接，或成一体；可以是机械连接，也可以是电连接；可以是直接相连，也可以通过中间媒介间接相连，可以是两个元件内
部的连通或两个元件的相互作用关系，除非另有明确的限定。对于本领域的普通技术人员
而言，可以根据具体情况理解上述术语在本发明中的具体含义。

[0067] 在本发明中，除非另有明确的规定和限定，第一特征在第二特征“上”或“下”可以是第一和第二特征直接接触，或第一和第二特征通过中间媒介间接接触。而且，第一特征在
第二特征“之上”、“上方”和“上面”可是第一特征在第二特征正上方或斜上方，或仅仅表示
第一特征水平高度高于第二特征。第一特征在第二特征“之下”、“下方”和“下面”可以是第
一特征在第二特征正下方或斜下方，或仅仅表示第一特征水平高度小于第二特征。

[0068] 在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特
点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不
必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任
一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技
术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结
合和组合。

[0069] 尽管上面已经示出和描述了本发明的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本发明的限制，本领域的普通技术人员在本发明的范围内可以对上述
实施例进行变化、修改、替换和变型。