分布式锁实现方法和装置的制造方法
【技术领域】
[0001 ]本发明涉及计算机技术领域，尤其涉及一种分布式锁实现方法和装置。
【背景技术】
[0002]目前，即时通讯类软件均支持多个客户端同时登录，例如:QQ软件，可支持手机客户端、平板电脑客户端、PC客户端同时登录，方便了用户的使用。但是随之而来的问题是，如果多个客户端同时向服务器发送相同的业务请求，例如发送心跳包，服务器无法确定该业务请求来自哪一个客户端，可能会产生重复执行业务的问题，造成了资源的浪费，导致服务器性能降低。
【发明内容】
[0003]本发明旨在至少在一定程度上解决相关技术中的技术问题之一。为此，本发明的一个目的在于提出一种分布式锁实现方法，能够避免来自多个客户端的相同业务被重复执行的问题，节省了资源，提升了服务器性能。
[0004]本发明的第二个目的在于提出一种分布式锁实现装置。
[0005]为了实现上述目的，本发明第一方面实施例提出了一种分布式锁实现方法，包括:SI，在同一时间段内接收来自多个客户端的相同的业务请求;S2，运行与所述业务请求对应的脚本文件，并生成对应的业务标识；以及S3，根据所述业务标识确定执行所述业务请求对应的业务的客户端。
[0006]本发明实施例的分布式锁实现方法，通过在同一时间段内接收来自多个客户端的相同的业务请求，运行与业务请求对应的脚本文件，并生成对应的业务标识，以及根据业务标识确定执行业务请求对应的业务的客户端，能够避免来自多个客户端的相同业务被重复执行的问题，节省了资源，提升了服务器性能。
[0007]本发明第二方面实施例提出了一种分布式锁实现装置，包括:接收模块，用于在同一时间段内接收来自多个客户端的相同的业务请求;运行模块，用于运行与所述业务请求对应的脚本文件，并生成对应的业务标识；以及确定模块，用于根据所述业务标识确定执行所述业务请求对应的业务的客户端。
[0008]本发明实施例的分布式锁实现装置，通过在同一时间段内接收来自多个客户端的相同的业务请求，运行与业务请求对应的脚本文件，并生成对应的业务标识，以及根据业务标识确定执行业务请求对应的业务的客户端，能够避免来自多个客户端的相同业务被重复执行的问题，节省了资源，提升了服务器性能。
【附图说明】
[0009]图1是根据本发明一个实施例的分布式锁实现方法的流程图。
[0010]图2是根据本发明一个实施例的分布式系统框架示意图。
[0011]图3是根据本发明一个实施例的分布式锁实现装置的结构示意图。
【具体实施方式】
[0012]下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本发明，而不能理解为对本发明的限制。
[0013]下面参考附图描述本发明实施例的分布式锁实现方法和装置。
[0014]图1是根据本发明一个实施例的分布式锁实现方法的流程图。
[0015]如图1所示，分布式锁实现方法可包括:
[0016]SI，在同一时间段内接收来自多个客户端的相同的业务请求。
[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[I]
[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.calI("PSETEX",userKey,expireMiIliseconds，"")
[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