CN106060060A - 客户端获取锁的方法及系统 - Google Patents

Abstract

本发明公开了一种客户端获取锁的方法及系统，属于网络技术领域。该方法包括：第一客户端向服务器发送锁获取请求；服务器接收锁获取请求，并向第一客户端发送锁获取成功响应；第一客户端获取锁；第二客户端向服务器发送锁获取请求；服务器接收锁获取请求，并向第二客户端发送锁获取失败响应；第二客户端获取锁失败。从而，本发明在分布式环境中基于key‑value内存数据库实现互斥锁，以解决在并发环境下资源竞争的问题，避免数据库长期被锁定，进而导致连接耗尽的问题。

Description

客户端获取锁的方法及系统

技术领域

本发明主要涉及网络技术领域，尤其涉及客户端获取锁的方法及系统。

背景技术

随着终端向智能化发展，越来越多的智能应用也如雨后春笋般地涌现，提高了人们的使用体验。在日常使用中，常常出现这样的场景，在使用视界应用时，在用户A分享一则消息时，用户B、用户C、用户D在同一时刻看到这一消息，并进行点赞操作。然而，在用户A的客户端并没有收到用户B、用户C和用户D的点赞或者评论，仅仅收到其中一名用户的点赞或者评论。这是因为在目前的视界积分统计中，采用的是实时显示积分，当用户点赞、评论完立刻就能看到自己的积分增长。然而，当多个用户同时点赞、评论时，就会造成并发问题，当用户在同一时刻高频率点击、或者利用http模拟工具模拟http请求向服务器发起并发请求，会导致并发问题。例如，目前的积分为100，三个点赞请求在同一时间并发的时候，会导致三个请求获取的初值均为100，然后在100的基础上累加1个积分进行更新，导致三个点赞的动作实际上只增加了一个积分，最终结果为101，实际上是103分。

针对这一问题，现有的解决方法是采用悲观锁(例如MySQL)对数据进行锁定，在业务处理完之后再释放锁，供下个用户请求使用。但是，这种做法的缺点在使用悲观锁进行锁定的时候，将会长期锁定一个数据库连接，直到业务处理完才释放，当线上用户众多时，这种数据库锁将会导致数据库被大量占用，造成数据库无连接可用，影响系统正常运行。

因此，有必要提出一种客户端获取锁的定方法及系统，避免上述情况的发生。

发明内容

本发明的主要目的在于提出一种客户端获取锁的方法及系统，旨在解决悲观锁长期锁定数据库导致数据库被大量占用的问题。

为实现上述目的，本发明提供的一种客户端获取锁的方法，所述方法包括：第一客户端向服务器发送锁获取请求；所述服务器接收所述锁获取请求，并向所述第一客户端发送锁获取成功响应；所述第一客户端获取锁；第二客户端向所述服务器发送锁获取请求；所述服务器接收所述锁获取请求，并向所述第二客户端发送锁获取失败响应；所述第二客户端获取锁失败。

可选地，所述方法还包括：当所述服务器向所述第一客户端发送锁获取失败响应时，则所述第一客户端获取所述锁失败。

可选地，所述方法还包括：当达到所述锁的有效时长，则释放所述锁。

可选地，当所述第二客户端获取锁失败时，所述方法还包括：等待所述第一客户端释放所述锁并进行重试。

可选地，所述第二客户端发送的所述锁获取请求中携带第一时间戳，所述服务器根据所述锁获取请求，对第二客户端响应第二时间戳，所述方法还包括：所述第二客户端判断所述第一时间戳是否大于所述第二时间戳，若是，则判定超时，且所述第二客户端获取锁。

此外，为实现上述目的，本发明还提出一种客户端获取锁的系统，所述系统包括服务器和与所述服务器连接的第一客户端和第二客户端，其中，所述第一客户端，用于向服务器发送锁获取请求；所述服务器，用于接收所述锁获取请求，并向所述第一客户端发送锁获取成功响应；所述第一客户端，还用于根据所述锁获取成功响应而获取锁；当所述第一客户端获取锁时，所述第二客户端，用于向所述服务器发送锁获取请求；所述服务器，还用于接收所述锁获取请求，并向所述第二客户端发送锁获取失败响应；所述第二客户端，还用于根据所述获取失败响应而获取所述锁失败。

可选地，所述服务器，还用于向所述第一客户端发送锁获取失败响应，相应地，所述第一客户端，还用于根据所述锁获取失败响应而获取所述锁失败。

可选地，所述第一客户端，还用于当达到所述锁的有效时长，则释放所述锁。

可选地，当所述第二客户端获取锁失败时，所述第二客户端还用于等待所述第一客户端释放所述锁并进行重试。

可选地，所述第二客户端发送的所述锁获取请求中携带第一时间戳，所述服务器根据所述锁获取请求，对第二客户端响应第二时间戳，所述第二客户端还用于判断所述第一时间戳是否大于所述第二时间戳，若是，则判定超时，且所述第二客户端获取锁。

本实施例的客户端获取锁的方法及系统，通过第一客户端向服务器发送锁获取请求，服务器接收该锁获取请求，并向第一客户端发送锁获取成功响应，则第一客户端获取锁，当第二客户端再次发起所获取请求时，服务器向第二客户端发送锁获取失败响应，则第二客户端获取锁失败。从而，本实施例在分布式环境中基于key-value内存数据库实现互斥锁，以解决在并发环境下资源竞争的问题，避免数据库长期被锁定，进而导致连接耗尽的问题。

附图说明

图1为本发明第一实施例提供的客户端获取锁的方法的流程示意图；

图2为本发明第二实施例提供的客户端获取锁的方法的流程示意图；

图3为本发明第三实施例提供的客户端获取锁的方法的流程示意图；

图4为本发明提供的客户端获取锁的系统的结构示意图。

本发明目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

现在将参考附图描述实现本发明各个实施例的移动终端。在后续的描述中，使用用于表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本发明的说明，其本身并没有特定的意义。因此，"模块"与"部件"可以混合地使用。

本发明各个实施例运行于分布式环境，多个客户端通过计算机网络访问各节点上的共享资源。另外，本实施例的客户端是基于redis(Remote Dictionary Server)提供的存储系统，与服务器交互实现分布式锁的获取，当某一客户端持有锁并在释放锁或者意外终止使用时，其他客户端才能够获取锁。

其中，本发明各个实施例中的客户端可以以各种形式来实施。例如，本发明中描述的客户端可以包括诸如移动电话、智能电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、导航装置等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。

进一步地，redis是一个key-value(键值对)的存储系统，和Memcached类似，它支持存储的value类型相对更多，包括string(字符串)、list(链表)、set(集合)、zset(sortedset--有序集合)和hash(哈希类型)。这些数据类型都支持push/pop、add/remove及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，redis支持各种不同方式的排序。与memcached一样，为了保证效率，数据都是缓存在内存中。区别的是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件，并且在此基础上实现了master-slave(主从)同步。

如图1所示，本发明第一实施例提出一种客户端获取锁的方法，所述方法包括：

S110，第一客户端向服务器发送锁获取请求。

具体地，第一客户端向服务器触发分布式锁(以下简称锁)获取请求。所述锁获取请求以redis的SETNX操作进行触发，其中，SETNX的含义是如果已经存在这个key则不做任何动作，如果不存在这个key则插入这个键值对。本领域技术人员可以理解的是，也可以采用其他操作进行触发，本实施例不作具体限定。

进一步地，锁获取请求中携带有以锁名为key，以该key对应的时间戳为value的key value参数。其中，锁名为与第一客户端相关的字符串，时间戳为第一客户端的当前时间(current time)与第一客户端设定的超时时间(lock timeout)之和。

在其他实施例中，也可以设定锁名为foo等，相应地，第一客户端向服务器发送的锁获取请求可以以如下命令进行获取：

SETNX lock.foo<current time+lock timeout+1>。

S120，服务器接收所述锁获取请求，并向第一客户端发送锁获取成功响应。

具体地，服务器接收第一客户端发送的锁获取请求时，提取锁获取请求中的时间戳，根据该时间戳，得到是否获取到该锁的结果并向第一客户端反馈不同的操作结果。例如，设定成功获取到锁的操作结果为1，设定没有获取到锁的操作结果为1之外的其他值，如0。在本实施例中，服务器为获取到锁的操作结果的情况，则将“1”反馈给第一客户端。

S130，第一客户端获取锁。

具体地，第一客户端接收到操作结果为“1”时，则代表第一客户端成功获取锁，表面锁名为key的锁已经被锁定，第一客户端进而可以根据该操作结果进行相应的操作，相应地，其他客户端则无法获取该锁。

当第一客户端完成锁的操作时，可以通过删除锁的操作来释放该锁。以锁名为foo为例，第一客户端可以采用如下命令释放锁：

DEL lock.foo。

在其他实施例中，若服务器接收第一客户端发送的锁获取请求时，提取锁获取请求中的时间戳，根据该时间戳，得到没有获取到该锁的结果并向第一客户端反馈“0”，即服务器向第一客户端发送锁获取失败响应。

当第一客户端接收到操作结果为“0”时，则代表第一客户端获取锁失败，说明有其他客户端持有该锁。

S140，第二客户端向所述服务器发送第二锁获取请求。

具体地，第二客户端向服务器触发第二锁获取请求。所述第二锁获取请求以redis的SETNX操作进行触发，其中，SETNX的含义是如果已经存在这个key则不做任何动作，如果不存在这个key则插入这个键值对。

进一步地，第二锁获取请求中携带有以锁名为foo，以该key对应的时间戳为value的key value参数。其中，锁名为与第二客户端相关的字符串，时间戳为第二客户端的当前时间(current time)与第二客户端设定的超时时间(lock timeout)之和。更具体地，第二客户端向服务器发送的锁获取请求可以以如下命令进行获取：

SETNX lock.foo<current time+lock timeout+1>。

S150，服务器接收第二锁获取请求，并向所述第二客户端发送锁获取失败响应。

具体地，由于锁被第一客户端持有，则服务器得到没有获取到该锁的结果并向第二客户端反馈“0”，即服务器向第二客户端发送锁获取失败响应。

S160，第二客户端获取锁失败。

本实施例的客户端获取锁的方法，通过第一客户端向服务器发送锁获取请求，服务器接收该锁获取请求，并向第一客户端发送锁获取成功响应，则第一客户端获取锁，当第二客户端向服务器发送第二锁获取请求，该服务器接收锁获取请求，并向第二客户端发送锁获取失败响应，则第二客户端获取锁失败。从而，本实施例在分布式环境中基于key-value内存数据库实现互斥锁，以解决在并发环境下资源竞争的问题，避免数据库长期被锁定，进而导致连接耗尽的问题。

请参照图2，本发明第二实施例进一步提供一种客户端获取锁的方法。在第二实施例中，所述方法包括S210-S260，其中，S210-S250与第一实施例中的S110-S150相类似，本发明在此不再赘述。

S210，第一客户端向服务器发送第一锁获取请求。

S220，服务器接收所述第一锁获取请求，并向第一客户端发送锁获取成功响应。

S230，第一客户端获取锁。

S240，第二客户端向所述服务器发送第二锁获取请求。

S250，服务器接收第二锁获取请求，并向所述第二客户端发送锁获取失败响应。

S260，第二客户端获取锁失败，等待所述第一客户端释放所述锁并进行重试。

具体地，第二客户端可以根据预设的时间进行重试以等待第一客户端释放锁。

在其他实施例中，第二客户端也可以等待锁超时而自动释放锁时，再进行重试。

更具体地，可以根据客户端程序的处理速度设定重试时间和超时时间，即：若客户端程序处理的速度快，则代表客户端释放锁的速度比较快，进而可以调低重试时间和超时时间，例如重试时间可以设为100毫秒(ms)，超时时间可以设为500ms；若客户端程序处理的速度慢，则代表客户端释放锁的速度比较慢，进而可以调高重试时间和超时时间，例如重试时间可以设为300ms，超时时间可以设为1000ms。

本实施例提供的客户端获取锁的方法，若第二客户端获取锁失败，则第二客户端等待第一客户端释放锁或者锁超时并进行重试。从而，本实施例的客户端获取锁的方法更有效地解决了在并发环境下资源竞争的问题，避免数据库长期被锁定，进而导致连接耗尽的问题。

请参照图3，本发明第三实施例进一步提供一种客户端获取锁的方法。在第三实施例中，所述客户端获取锁的方法包括S310-S380，其中，S310-S350与第二实施例中的S210-S250相类似，本发明在此不再赘述。

S310，第一客户端向服务器发送第一锁获取请求。

S320，服务器接收所述第一锁获取请求，并向第一客户端发送锁获取成功响应。

S330，第一客户端获取锁。

S340，第二客户端向服务器发送第二锁获取请求。

S350，服务器接收第二锁获取请求，并向所述第二客户端发送锁获取失败响应。

具体地，第二锁获取请求中携带有以锁名为foo，以该key对应的第一时间戳为value的key value参数。

S360，第二客户端判断所述第一时间戳是否大于第二时间戳，若是，则进入S370，若否，则进入S380。

具体地，服务器根据所述锁获取请求，对第二客户端响应第二时间戳，且第二客户端判定第一时间戳是否大于第二时间戳，若是，则进入S370，若否，则进入S380。

更具体地，第二客户端可以采用如下命令进行判断：

GETSET lock.foo<current Unix time+lock timeout+1>

其中，在GETSET操作中，先对给定的key设为value，并返回key的初始值，并对锁foo设置一个超时时间，并返回原有的超时时间的值。通过GETSET操作，若第一时间戳大于第二时间戳，则进入S370；若第二时间戳小于第二时间戳，则进入S380。

S370，判定超时，且第二客户端获取锁。

S380，判定未超时，且第二客户端获取锁失败。

在本实施例中，若第一客户端在解锁之前先判断锁是否已经超时，若第一客户端所持有的锁被判定为超时，则第一客户端不需要通过删除锁的操作而释放锁。

进一步地，在其他实施例中，若在第二客户端向服务器发送第二锁获取请求之前，出现第三客户端向服务器发送第三锁获取请求，且第三客户端获取锁，则第二客户端接收的第二时间戳为未超时的值，且第二客户端获取锁失败，需要再次等待第三客户端释放所述锁或者锁超时并进行重试。

本实施例提供的客户端获取锁的方法，通过第二客户端判断第二客户端发出的锁获取请求中的第一时间戳是否大于服务器响应该锁获取请求的第二时间戳，若是，则判定超时，且所述第二客户端获取锁。从而，本实施例的客户端获取锁的方法能够更稳健地获取分布式锁，有效解决了数据库被长期锁定而导致数据库被大量占用的问题。

本发明进一步提供一种客户端获取锁的系统。

参照图4，图4为本发明第四实施例提供的客户端获取锁的系统的结构示意图。

本实施例一种客户端获取锁的系统，包括服务器410、与服务器410通过计算机网络进行连接的第一客户端420和第二客户端430。其中，

第一客户端420，用于向服务器410发送锁获取请求。

具体地，第一客户端420向服务器410触发分布式锁(以下简称锁)获取请求。所述锁获取请求以redis的SETNX操作进行触发，其中，SETNX的含义是如果已经存在这个key则不做任何动作，如果不存在这个key则插入这个键值对。本领域技术人员可以理解的是，也可以采用其他操作进行触发，本实施例不作具体限定。

进一步地，锁获取请求中携带有以锁名为key，以该key对应的时间戳为value的key value参数。其中，锁名为与第一客户端420相关的字符串，时间戳为第一客户端420的当前时间(current time)与第一客户端420设定的超时时间(lock timeout)之和。

在其他实施例中，也可以设定锁名为foo等，相应地，第一客户端420向服务器410发送的锁获取请求可以以如下命令进行获取：

SETNX lock.foo<current time+lock timeout+1>。

服务器410，用于接收所述锁获取请求，并向第一客户端420发送锁获取成功响应。

具体地，服务器410接收第一客户端420发送的锁获取请求时，提取锁获取请求中的时间戳，根据该时间戳，得到是否获取到该锁的结果并向第一客户端420反馈不同的操作结果。例如，设定成功获取到锁的操作结果为1，设定没有获取到锁的操作结果为1之外的其他值，如0。在本实施例中，服务器410为获取到锁的操作结果的情况，则将“1”反馈给第一客户端420。

第一客户端410，还用于根据所述锁获取成功响应而获取锁。

具体地，第一客户端420接收到操作结果为“1”时，则代表第一客户端420成功获取锁，表面锁名为key的锁已经被锁定，第一客户端420进而可以根据该操作结果进行相应的操作，相应地，其他客户端则无法获取该锁。

当第一客户端420完成锁的操作时，可以通过删除锁的操作来释放该锁。以锁名为foo为例，第一客户端420可以采用如下命令释放锁：

DEL lock.foo。

在其他实施例中，若服务器410接收第一客户端420发送的锁获取请求时，提取锁获取请求中的时间戳，根据该时间戳，得到没有获取到该锁的结果并向第一客户端420反馈“0”，即服务器410向第一客户端420发送锁获取失败响应。

当第一客户端420接收到操作结果为“0”时，则代表第一客户端420获取锁失败，说明有其他客户端持有该锁。

第二客户端430，用于向所述服务器410发送第二锁获取请求。

具体地，第二客户端430向服务器410触发第二锁获取请求。所述第二锁获取请求以redis的SETNX操作进行触发，其中，SETNX的含义是如果已经存在这个key则不做任何动作，如果不存在这个key则插入这个键值对。

进一步地，第二锁获取请求中携带有以锁名为foo，以该key对应的时间戳为value的key value参数。其中，锁名为与第二客户端430相关的字符串，时间戳为第二客户端430的当前时间(current time)与第二客户端430设定的超时时间(lock timeout)之和。更具体地，第二客户端430向服务器410发送的锁获取请求可以以如下命令进行获取：

SETNX lock.foo<current time+lock timeout+1>。

服务器410，用于接收第二锁获取请求，并向所述第二客户端430发送锁获取失败响应。

具体地，由于锁被第一客户端420持有，则服务器410得到没有获取到该锁的结果并向第二客户端430反馈“0”，即服务器410向第二客户端430发送锁获取失败响应。

第二客户端430，还用于根据所述锁获取失败响应而获取锁失败。

本实施例的客户端获取锁的系统，通过第一客户端420向服务器410发送锁获取请求，服务器410接收该锁获取请求，并向第一客户端420发送锁获取成功响应，则第一客户端420获取锁，当第二客户端430再向服务器410发送第二锁获取请求，该服务器410接收锁获取请求，并向第二客户端430发送锁获取失败响应，则第二客户端430获取锁失败。从而，本实施例在分布式环境中基于key-value内存数据库实现互斥锁，以解决在并发环境下资源竞争的问题，避免数据库长期被锁定，进而导致连接耗尽的问题。

如图4所示，本发明第二实施例进一步提供一种客户端获取锁的系统。在第二实施例中的客户端获取锁的系统与第一实施例的区别仅在于：所述系统还包括第二客户端430。本实施例的客户端获取锁的系统的具体实现方式如下：

第二客户端430，还用于当获取锁失败时，等待所述第一客户端420释放所述锁并进行重试。

具体地，第二客户端430可以根据预设的时间进行重试以等待第一客户端420释放锁。

在其他实施例中，第二客户端430也可以等待锁超时而自动释放锁时，再进行重试。

更具体地，可以根据客户端程序的处理速度设定重试时间和超时时间，即：若客户端程序处理的速度快，则代表客户端释放锁的速度比较快，进而可以调低重试时间和超时时间，例如重试时间可以设为100毫秒(ms)，超时时间可以设为500ms；若客户端程序处理的速度慢，则代表客户端释放锁的速度比较慢，进而可以调高重试时间和超时时间，例如重试时间可以设为300ms，超时时间可以设为1000ms。

本实施例提供的客户端获取锁的系统，若第二客户端430获取锁失败，则第二客户端430等待第一客户端420释放锁或者锁超时并进行重试。从而，本实施例的客户端获取锁的系统更有效地解决了在并发环境下资源竞争的问题，避免数据库长期被锁定，进而导致连接耗尽的问题。

请进一步参照图4，本发明第三实施例进一步提供一种客户端获取锁的系统。本实施例的客户端获取锁的系统的具体实现方式如下：

第一客户端420，用于向服务器410发送第一锁获取请求。

服务器410，用于接收所述第一锁获取请求，并向第一客户端420发送锁获取成功响应。

第一客户端420获取锁。

第二客户端430，用于向所述服务器410发送第二锁获取请求。

服务器410，用于接收第二锁获取请求，并向所述第二客户端430发送锁获取失败响应。

具体地，第二锁获取请求中携带有以锁名为foo，以该key对应的第一时间戳为value的key value参数。

上述服务器410、第一客户端420、第二客户端430与第二实施例中对应的实现方式相类似，本实施例不再赘述。

第二客户端430，还用于判断所述第一时间戳是否大于第二时间戳，若是，则判定超时，且第二客户端430获取锁；若否，则判定未超时，且第二客户端430获取锁失败。

具体地，服务器410根据所述锁获取请求，对第二客户端430响应第二时间戳，且第二客户端430判定第一时间戳是否大于第二时间戳，若是，则判定超时，且第二客户端430获取锁；若否，则判定未超时，且第二客户端430获取锁失败。

更具体地，第二客户端430可以采用如下命令进行判断：

GETSET lock.foo<current Unix time+lock timeout+1>

其中，在GETSET操作中，先对给定的key设为value，并返回key的初始值，并对锁foo设置一个超时时间，并返回原有的超时时间的值。通过GETSET操作，若第一时间戳大于第二时间戳，则判定超时，且第二客户端430获取锁；若第二时间戳小于第二时间戳，则判定未超时，且第二客户端430获取锁失败。

在本实施例中，若第一客户端420在解锁之前先判断锁是否已经超时，若第一客户端420所持有的锁被判定为超时，则第一客户端420不需要通过删除锁的操作而释放锁。

进一步地，在其他实施例中，若在第二客户端430向服务器410发送第二锁获取请求之前，出现第三客户端向服务器410发送第三锁获取请求，且第三客户端获取锁，则第二客户端430接收的第二时间戳为未超时的值，且第二客户端430获取锁失败，需要再次等待第三客户端释放所述锁或者锁超时并进行重试。

本实施例提供的客户端获取锁的系统，通过第二客户端430判断第二客户端430发出的锁获取请求中的第一时间戳是否大于服务器410响应该锁获取请求的第二时间戳，若是，则判定超时，且所述第二客户端430获取锁。从而，本实施例的客户端获取锁的系统，能够更稳健地获取分布式锁，有效解决了数据库被长期锁定而导致数据库被大量占用的问题。

需要说明的是，在本文中，术语“包括”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种客户端获取锁的方法，其特征在于，所述方法包括：

第一客户端向服务器发送锁获取请求；

所述服务器接收所述锁获取请求，并向所述第一客户端发送锁获取成功响应；

所述第一客户端获取锁；

第二客户端向所述服务器发送锁获取请求；

所述服务器接收所述锁获取请求，并向所述第二客户端发送锁获取失败响应；

所述第二客户端获取锁失败。

2.根据权利要求1所述的客户端获取锁的方法，其特征在于，所述方法还包括：

当所述服务器向所述第一客户端发送锁获取失败响应时，则所述第一客户端获取所述锁失败。

3.根据权利要求1-2任一项所述的客户端获取锁的方法，其特征在于，所述方法还包括：

当达到所述锁的有效时长，则释放所述锁。

4.根据权利要求1所述的客户端获取锁的方法，其特征在于，当所述第二客户端获取锁失败时，所述方法还包括：等待所述第一客户端释放所述锁并进行重试。

5.根据权利要求1所述的客户端获取锁的方法，其特征在于，所述第二客户端发送的所述锁获取请求中携带第一时间戳，所述服务器根据所述锁获取请求，对第二客户端响应第二时间戳，所述方法还包括：

所述第二客户端判断所述第一时间戳是否大于所述第二时间戳，若是，则判定超时，且所述第二客户端获取锁。

6.一种客户端获取锁的系统，其特征在于，所述系统包括服务器和与所述服务器连接的第一客户端和第二客户端，其中，

所述第一客户端，用于向服务器发送锁获取请求；

所述服务器，用于接收所述锁获取请求，并向所述第一客户端发送锁获取成功响应；

所述第一客户端，还用于根据所述锁获取成功响应而获取锁；

当所述第一客户端获取锁时，所述第二客户端，用于向所述服务器发送锁获取请求；

所述服务器，还用于接收所述锁获取请求，并向所述第二客户端发送锁获取失败响应；

所述第二客户端，还用于根据所述获取失败响应而获取所述锁失败。

7.根据权利要求6所述的客户端获取锁的系统，其特征在于，所述服务器，还用于向所述第一客户端发送锁获取失败响应，相应地，所述第一客户端，还用于根据所述锁获取失败响应而获取所述锁失败。

8.根据权利要求6或7任一项所述的客户端获取锁的系统，其特征在于，所述第一客户端，还用于当达到所述锁的有效时长，则释放所述锁。

9.根据权利要求6所述的客户端获取锁的系统，其特征在于，当所述第二客户端获取锁失败时，所述第二客户端还用于等待所述第一客户端释放所述锁并进行重试。

10.根据权利要求6所述的客户端获取锁的系统，其特征在于，所述第二客户端发送的所述锁获取请求中携带第一时间戳，所述服务器根据所述锁获取请求，对第二客户端响应第二时间戳，所述第二客户端还用于判断所述第一时间戳是否大于所述第二时间戳，若是，则判定超时，且所述第二客户端获取锁。