一种商品处理方法、装置、电子设备及计算机存储介质

技术领域

本发明涉及医药供应链技术领域，尤其涉及一种商品处理方法、装置、电子设备及计算机存储介质。

背景技术

现有的药房系统配货业务多系统，涉及到多系统库存的同步调用和异步调用，在多系统数据并发处理订单时，基于redis、数据表、zookeeper做分布式锁实现，以将用户提交的订单信息中的商品进行上锁操作。但通过上述的方式进行分布式锁实现，容易导致资源浪费与系统业务不稳定而且响应慢。

发明内容

有鉴于此，本发明实施例提供一种商品处理方法、装置、电子设备及计算机存储介质，以解决现有技术中存在的资源浪费与系统业务不稳定而且响应慢的问题。

为实现上述目的，本发明实施例提供如下技术方案：

本发明实施例第一方面示出的商品处理方法，所述方法包括：

在接收到用户基于应用渠道提交的订单信息时，基于所述订单信息中的商品的商品信息和用户账户信息，确定所述商品处于第一次待被锁定；

利用第一版本号分布式锁算法确定是否获取到所述订单信息中商品的商品锁；所述第一版本号分布式锁算法包括普通版本号分布式锁算法和比较并替换CAS自旋版本号分布式锁算法；

若获取到，基于所述订单信息，确定所述订单信息中商品的版本号；

在确定基于所述商品锁对所述商品进行锁操作之后，基于锁属性参数确定与所述商品对应的锁参数，所述锁属性参数是在获取商品锁的过程中基于所述版本号生成的；

在所述锁属性参数中锁持有时间内接收到用户基于所述应用渠道提交的支付完成指令时，基于所述锁参数释放版本号。

可选的，还包括：

基于所述用户账户查询信息，查询是否存在已锁定的与所述用户账户信息对应的其他订单；

若不存在，确定所述商品处于第一次待被锁定；

若存在，基于所述其他订单中的商品与所述商品对应的商品信息判断是否存在商品信息一致的商品；

若不存在，则确定所述商品均处于第一次待被锁定；

若存在，将存在商品信息一致的商品作为重入商品。

可选的，还包括：

利用第二版本号分布式锁算法确定是否获取到所述订单信息中商品的商品锁，第二版本号分布式锁算法包括可重入版本号分布式锁算法。

可选的，所述利用第二版本号分布式锁算法确定是否获取到所述订单信息中商品的商品锁，包括：

确定所述商品被锁定的次数是否超过所述商品的库存数量；

若未超过，确定所述商品可获取对应的商品锁；

若超过，确定所述商品无法获取对应的商品锁。

可选的，若第一版本号分布式锁算法为普通版本号分布式锁算法，所述利用第一版本号分布式锁算法确定是否获取到所述订单信息中商品的商品锁，包括：

利用第一版本号分布式锁算法确定所述订单信息中的商品是否存在库存；

若存在，确定所述订单信息中商品可获取对应的商品锁。

可选的，若第一版本号分布式锁算法为CAS自旋版本号分布式锁算法，所述利用第一版本号分布式锁算法确定是否获取到所述订单信息中商品的商品锁，包括：

利用CAS自旋版本号分布式锁算法对所述商品进行CAS处理，确定所述商品是否已被锁定；

若确定所述商品未被锁定，确定所述商品被锁定的次数是否超过所述商品的库存数量；

若确定所述商品已被锁定，确定所述商品被锁定的次数是否等于或小于所述商品的库存数量；

若所述商品被锁定的次数未超过所述商品的库存数量，或，所述商品被锁定的次数小于所述商品的库存数量，则确定所述商品可获取对应的商品锁；

若所述商品被锁定的次数等于所述商品的库存数量，则确定所述商品无法获取对应的商品锁。

本发明实施例第二方面示出的一种商品处理装置，所述装置包括：

第一确定单元，用于在接收到用户基于应用渠道提交的订单信息时，基于所述订单信息中的商品的商品信息和用户账户信息，确定所述商品处于第一次待被锁定；

锁获取单元，用于利用第一版本号分布式锁算法确定是否获取到所述订单信息中商品的商品锁，所述第一版本号分布式锁算法包括普通版本号分布式锁算法和CAS自旋版本号分布式锁算法；

第二确定单元，用于若获取到，基于所述订单信息，确定所述订单信息中商品的版本号；

第三确定单元，用于在确定基于所述商品锁对所述商品进行锁操作之后，基于锁属性参数确定与所述商品对应的锁参数，所述锁属性参数是在获取商品锁的过程中基于所述版本号生成的；

释放单元，用于在所述锁属性参数中锁持有时间内接收到用户基于所述应用渠道提交的支付完成指令时，基于所述锁参数释放版本号。

可选的，若第一版本号分布式锁算法为普通版本号分布式锁算法的所述锁获取单元，具体用于：利用第一版本号分布式锁算法确定所述订单信息中的商品是否存在库存；若存在，确定所述订单信息中商品可获取对应的商品锁。

本发明实施例第三方面示出了一种电子设备，所述电子设备用于运行程序，其中，所述程序运行时执行如本发明实施例第一方面示出的商品处理方法。

本发明实施例第四方面示出了一种计算机存储介质，所述存储介质包括存储程序，其中，在所述程序运行时控制所述存储介质所在设备执行如本发明实施例第一方面示出的商品处理方法。

基于上述本发明实施例提供的一种商品处理方法、装置、电子设备及计算机存储介质，在接收到用户提供的订单信息时，确定该订单信息中的商品处于第一次待被锁定，之后根据普通版本号分布式锁算法或CAS自旋版本号分布式锁算法确定是否存在商品的商品锁，并通过，基于订单信息生成识别商品的唯一版本号，本方案通过商品锁能够对商品进行锁操作；接着若在锁属性参数中锁持有时间内接收到用户基于应用渠道提交的支付完成指令时，释放锁。可见，本方案通过对持有相同版本号的锁对象线程进行释放，能够避免被其他线程锁对象错误释放。通过上述方式能够保住资源浪费与系统业务的稳定，而且能够提高应用的响应。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本发明实施例示出的医药供应链的架构示意图；

图2为本发明实施例示出的一种商品处理方法的流程示意图；

图3为本发明实施例示出的生成版本号的流程图；

图4为本发明实施例示出的另一种商品处理方法的流程示意图；

图5为本发明实施例示出的一种商品处理装置的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

需要说明的是，在本发明中涉及“第一”、“第二”等的描述仅用于描述目的，而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。另外，各个实施例之间的技术方案可以相互结合，但是必须是以本领域普通技术人员能够实现为基础，当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在，也不在本发明要求的保护范围之内。

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

为了方便理解，以下对本发明实施例中出现的术语进行解释说明：

锁key：用来记录锁的唯一标识，只有一个线程可以获取到该锁。

锁线程号：记录当前线程号(线程id)，辅助版本号控制锁的获取和释放。

版本号：记录当前持有锁的版本号，由上面1.1定义亿级版本号的生成方法与洗牌策略提供的静态方法获取。

信号游标：记录重入锁的重入次数，默认初始值为0。

锁获取成功标识：true和false值，默认false，true表示拿到锁，false表示获取锁失败。

锁获取次数：记录获取到锁或没有获取到锁，竞争了多少次CAS，默认初始值为0。

锁获取超出次数：锁CAS的循环超出次数，默认Integer最大值，超出次数后，停止获取。

锁获取超出时间：锁获取的超时时间，默认(十分钟)，超出时间后，停止获取。

锁获取到时间：锁获取到的时间。

锁持有时间：拿到锁后，锁的持有时长，超过该时长，锁自动释放，其他线程可以竞争获取该锁。

锁持有超出时间：获取到锁的时间+锁持有时间＝锁持有超出时间。

Redis客户端：分布式锁的组件，创建锁对象时，由spring组件类自动获取容器里redis客户端bean赋值给分布式锁对象的客户端属性。

分布式锁主要是解决并发时，不同服务之间的资源竞争，在并发阶段释放锁时，稍有疏漏就有可能将他人获取到的锁给释放掉，没有好的使用自旋、重入、锁升级等策略。

参见图1，为本发明实施例示出的医药供应链的架构示意图，该医药供应链包括服务器10和用户终端20。

服务器10可通过不同的应用渠道30与用户终端20连接。

其中，所述用户终端20的数量为多个，具体包括用户终端21，用户终端22……用户终端2n，n为大于等于1的正整数。

基于上述本发明实施例示出的医药供应链，具体实现医药商品处理方法的过程，包括：

服务器10在接收到用户基于用户终端20中的任意一应用渠道30提交的医药购买订单信息时，基于所述订单信息中的商品的商品信息和用户账户信息，确定所述商品处于第一次待被锁定；利用第一版本号分布式锁算法确定是否获取到所述订单信息中商品的商品锁；所述第一版本号分布式锁算法包括普通版本号分布式锁算法和比较并替换CAS自旋版本号分布式锁算法；若获取到，基于所述订单信息，确定所述订单信息中商品的版本号；在确定基于所述商品锁对所述商品进行锁操作之后，基于锁属性参数确定与所述商品对应的锁参数，所述锁属性参数是在获取商品锁的过程中基于所述版本号生成的；在所述锁属性参数中锁持有时间内接收到用户基于所述应用渠道提交的支付完成指令时，基于所述锁参数释放版本号。

在本发明实施例中，在确定用户提交订单但未支付成功，基于订单信息中的商品的商品信息和用户账户信息，确定所述商品处于第一次待被锁定时，利用第一版本号分布式锁算法确定是否获取到所述订单信息中商品的商品锁；如果获取到锁，会为锁对象，及订单中的商品生成对应的版本号，后续锁对象在释放锁时，只有持有这个版本号的锁对象线程才能释放，避免被其他线程锁对象错误释放。通过上述方式能够保住资源浪费与系统业务的稳定，而且能够提高应用的响应。

基于上述示出医药供应链的架构示意图，参见图2，为本发明实施例示出一种商品处理方法的流程示意图，该方法包括：

步骤S201：在接收到用户基于应用渠道提交的订单信息时，基于所述订单信息中的商品的商品信息和用户账户信息，确定所述商品处于第一次待被锁定。

在步骤S201中，所述订单信息中商品的数量至少为1个。

可选的，用户可通过各种应用渠道进行商品购买，购买成功的过程分为提交订单和支付商品对应的金额；用户可通过任意一应用渠道对商品进行购买，并提交携带有商品的商品信息和用户账户信息订单信息。

在具体实现步骤S201的过程中，通过所述订单信息中的商品的商品信息和用户账户信息，确定所述用户在该渠道没有其他的提交且未支付的订单，或是，所述用户在该渠道的其他提交且未支付的订单中未存在当前订单信息中的商品，确定所述商品处于第一次待被锁定。

步骤S202：利用第一版本号分布式锁算法确定是否获取到所述订单信息中商品的商品锁，若获取到，则执行步骤S203，若未获取到，则确定所述商品无法获取到对应的商品锁，此时将该订单中的商品释放。

在步骤S202中，第一版本号分布式锁算法包括普通版本号分布式锁算法和CAS自旋版本号分布式锁算法。

需要说明的是，若第一版本号分布式锁算法为普通版本号分布式锁算法，具体实现步骤S202利用第一版本号分布式锁算法确定是否获取到所述订单信息中商品的商品锁的过程，包括：

步骤S11：利用第一版本号分布式锁算法确定所述订单信息中的商品是否存在库存，若存在，则执行步骤S12，若否，则确定所述商品无法获取到对应的商品锁，此时将该订单中的商品释放。

可选的，普通版本号分布式锁主要属性有锁标识key、锁线程号、版本号、锁获取成功标识、锁获取次数、锁获取超出次数(默认1)、锁获取到时间、锁持有时间、锁持有超出时间、和redis客户端。

其中，每一商品对应一个线程。

在本发明实施例中，在创建普通分布式锁时，对象构造器自动取IOC(InversionofControl，控制反转)容器的Redis bean赋值当前锁对象的redis客户端属性，比如将锁标识key和锁持有时间等传递给该锁。

在具体实现步骤S11的过程中，在获取锁时，使用redis setNx方法确定所述订单信息中的商品是否存在库存，若存在，返回锁获取成功标识为成功true，并执行步骤S12，若否，返回锁获取不成功标识为失败false，则确定所述商品无法获取到对应的商品锁，此时将该订单中的商品释放。

需要说明的是，利用redis setNx方法在获取锁时，生成对应的锁属性参数，锁属性参数包括锁key的值为锁线程号+版本号，锁获取次数+1，设置set成功则表示获取到锁，锁获取成功标识为true，赋值当前时间为锁获取到时间，赋值锁持有超出时间为锁获取到时间+锁持有时间，set失败则表示未获取到锁，锁获取不成功标识为false，根据经验或实际情况设置的锁持有超出时间。

在本发明实施例中，若商品的数量为1个时，锁获取次数为1；若商品的数量为N，N为大于等于2的正整数时，首先对N＝1的商品进行锁获取的处理，即执行步骤11的过程，在获取到锁时，锁获取次数+1；接着对首先对N＝2的商品进行锁获取的处理，即执行步骤11的过程，在获取到锁时，锁获取次数+1+1；依次类推，依次获取每一商品的锁，即执行步骤S11的具体过程，直到确定所述订单中的每一商品均上锁，若存在任意一个商品上锁失败，即返回锁获取不成功标识为失败false时，此时将该订单中的商品释放。

步骤S12：确定所述订单信息中商品可获取对应的商品锁。

在具体实现步骤S12的过程中，为所述订单信息中的商品上锁，并执行步骤S203。

需要说明的是，若第一版本号分布式锁算法为CAS自旋版本号分布式锁算法，具体实现步骤S202利用第一版本号分布式锁算法确定是否获取到所述订单信息中商品的商品锁的过程，包括：

步骤S21：利用比较并交换CAS自旋版本号分布式锁算法对所述商品进行CAS处理，若确定该商品存在已被锁定的情况，并执行步骤S22，若确定该商品不存在已被锁定的情况，则直接执行步骤S23。

在具体实现步骤S21的过程中，利用比较并交换CAS自旋版本号分布式锁算法对商品的状态进行比较，若确定该商品存在未被锁定的情况，并执行步骤S22，若确定该商品存在已被锁定的情况，则直接执行步骤S23。

可选的，若确定该商品存在已被锁定的情况，且已被锁定的商品与所述订单信息中的商品为同一用户的商品，可利用比较并交换CAS自旋版本号分布式锁算法将所述商品对应的版本号替换已被锁定的商品的版本号。

步骤S22：确定所述商品被锁定的次数是否超过所述商品的库存数量，若未超过，返回锁获取成功标识为成功true，并执行步骤S24，若超过，返回锁获取不成功标识为失败false，并确定所述商品无法获取到对应的商品锁，即执行步骤S25，此时将该订单中的商品释放。

在具体实现步骤S22的过程中，在获取锁时，使用redis setNx方法确定所述商品被锁定的次数是否超过所述商品的库存数量，若未超过，返回锁获取成功标识为成功true，并执行步骤S24，若超过，返回锁获取不成功标识为失败false，并确定所述商品无法获取到对应的商品锁，即执行步骤S25，此时将该订单中的商品释放。

步骤S23：确定所述商品被锁定的次数是否等于或小于所述商品的库存数量。

在具体实现步骤S23的过程中，在获取锁时，使用redis setNx方法确定所述商品被锁定的次数是否超过所述商品的库存数量，若小于，返回锁获取成功标识为成功true，并执行步骤S24，若等于，可将循环次数+1得到当前循环次数，并记录当前时间，执行步骤S25。

需要说明的是，利用redis setNx方法在获取锁时，生成对应的锁属性参数，锁属性参数包括标识key为锁key，锁key的值为锁线程号+锁版本号，每一获取一次锁，锁获取次数+1，设置set成功则表示获取到锁，锁获取成功标识为true，赋值当前时间为锁获取到时间，赋值锁持有超出时间为锁获取到时间+锁持有时间，set失败则表示未获取到锁，锁获取不成功标识为false，根据经验或实际情况设置的锁持有超出时间。

步骤S24：确定所述商品可获取对应的商品锁。

步骤S25：确定所述商品无法获取到对应的商品锁。

可选的，在开始获取锁时，记录锁开始获取时间，

可选的，在执行步骤S25之前，还包括：判断当前循环次数是否小于锁获取超出次数，并且当前循环获取锁时间小于获取锁超出时间；若前循环次数小于锁获取超出次数，并且当前循环获取锁时间小于获取锁超出时间，则循环索取锁，即循环执行步骤S21至步骤S25的过程，反之，则确定锁获取成功标识为false，并执行步骤S25。

其中，当前循环获取锁时间为锁开始获取时间与每一获取锁失败时，记录，即步骤S23示出的当前时间的差。

需要说明的是，CAS自旋是指持有锁的线程，即已锁定的商品与等待竞争锁的线程，即正在获取锁的商品之间不需要做内核态和用户态之间的切换进入阻塞状态，只需要循环等待持有锁的线程释放锁，从而避免了用户进程和内核切换的消耗。

可选的，每次获取的锁都会累计存储下来，可以用来做锁资源竞争分析，或其他数据分析。

在本发明实施例中，若商品的数量为1个时，锁获取次数为1，即直接执行步骤S21至步骤S25的过程；若商品的数量为N，N为大于等于2的正整数时，依次对每一商品进行步骤S21至步骤S25的处理。

需要说明的是，一个商品锁只能对一个商品，或同一类型的商品进行锁定，订单中每一的商品可存在一个对应的商品锁。

步骤S203：基于所述订单信息，确定所述订单信息中商品的版本号。

需要说明的是，订单若存在一个商品，则有一个与所述商品对应的版本号，若存在多个商品，则每一商品均存在一个与之对应的版本号。

版本号由订单提交时的当前日期(年月日)与远程字典服务redis的incr增长值组成。

订单信息中还可能包括商品的资源标签flag，其中，所述资源标签flag是用户在提交订单时系统根据用户的账户为商品分发的资源标签flag。

在具体实现步骤S203的过程中，若确定所述订单信息中存在商品的资源标签flag，将所述商品的资源标签flag发送给redis锁管理器；接着利用Redis Incr命令对所述Incr中储存的数字值Incr值增一，确定Incr值是否大于Integer.MAX_VALUE最大整数值2

若确定所述订单信息中未存在商品的资源标签flag，随机生成对应的默认default标签，将所述商品的默认default标签发送给redis锁管理器；接着利用Redis Incr命令对所述Incr中储存的数字值Incr值增一，确定Incr值是否大于Integer.MAX_VALUE最大整数值2

需要说明的是，将返回的Incr值，资源标签flag和当前日期yyyyMMdd组成，然后转换成Long值，即得到对应的版本号。

当前日期yyyyMMdd为字符串格式。

Integer.MAX_VALUE范围已经可以支撑锁资源日流量到20亿以上。

可选的，在获取版本号之后，将其进行缓存累计获取次数，以便后续运维人员进行数据分析等。

步骤S204：在确定基于所述商品锁对所述商品进行锁操作之后，基于所述版本号和锁属性参数确定与所述商品对应的锁参数。

在步骤S204中，所述锁属性参数是在获取商品锁的过程中产生的。

需要说明的是，利用redis setNx方法在获取锁时，生成对应的锁属性参数，锁属性参数包括标识key为锁key，锁key的值为锁线程号+锁版本号，每一获取一次锁，锁获取次数+1，设置set成功则表示获取到锁，锁获取成功标识为true，赋值当前时间为锁获取到时间，赋值锁持有超出时间为锁获取到时间+锁持有时间，set失败则表示未获取到锁，锁获取不成功标识为false，根据经验或实际情况设置的锁持有超出时间。

其中，锁线程号是根据该商品在订单中的顺序设置的，若为顺序第一的商品，该锁线程号可设置为1。

在具体实现步骤S204的过程中，通过获取到的商品锁对所述获取到锁的商品进行上锁处理，以防止其他用户通过其他渠道购买该商品；在确定基于所述商品锁对所述商品进行锁操作之后，获取锁时得到的锁属性参数中的锁获取成功标识、当前锁对象的线程号+锁版本号和锁获取到时间作为锁参数，并发送给Redis进行存储，并其存储至商品锁中。

可选的，在对商品进行上锁操作之后，各个渠道对应该商品的库存数会减少，若支付失败自动释放商品资源，各个渠道对应该商品的库存数会恢复。

步骤S205：在预设锁持有时间内接收到用户基于所述应用渠道提交的支付完成指令时，基于所述锁参数释放版本号。

在具体实现步骤S205的过程中，检测接收到支付完成指令的当前时间是否小于锁持有超出时间，若小于，确定用户在预设锁持有时间内基于所述应用渠道完成对订单的支付，判断所述Redis中存储的获取成功标识是否为true，以确定要释放的订单是否为所述用户订单中的商品；再获取所述Redis中存储的value值，与商品锁中的当前锁对象的线程号+锁版本号是否一致，符合以上条件使用redis del将锁key，也就是说，将版本号释放，并还原获取锁原来的赋值。

需要说明的是，若不符合任意一以上条件，则自动释放商品资源，各个渠道对应该商品的库存数会恢复。

可选的，当另一个线程锁对象，即另一商品也获取该同一把锁时，只有当前获取到锁的锁对象线程释放后，另一个线程锁对象才能获取到该锁，并为另一个线程锁对象生成新的递增版本号，避免版本号相同的锁出现而引起一些可预知与未知问题。

在本发明实施例中，在确定用户提交订单但未支付成功，基于订单信息中的商品的商品信息和用户账户信息，确定所述商品处于第一次待被锁定时，利用第一版本号分布式锁算法确定是否获取到所述订单信息中商品的商品锁；如果获取到锁，会为锁对象，及订单中的商品生成对应的版本号，后续锁对象在释放锁时，只有持有这个版本号的锁对象线程才能释放，避免被其他线程锁对象错误释放。通过上述方式能够保住资源浪费与系统业务的稳定，而且能够提高应用的响应。

基于上述本发明实施例示出的商品处理方法，本发明实施例还示出另一商品处理方法的流程示意图，如图4所示，该方法包括：

步骤S401：在接收到用户基于应用渠道提交的订单信息时，基于所述用户账户查询信息，查询是否存在已锁定的与所述用户账户信息对应的其他订单，若不存在，执行步骤S403，若存在，执行步骤S402。

在具体实现步骤S401的过程中，在接收到用户基于应用渠道提交的订单信息时，通过自身的用户账户查询该用户账户是否存在已锁定的其他订单，若存在，执行步骤S403，若不存在，执行步骤S402。

步骤S402：基于所述其他订单中的商品信息与所述商品对应的商品信息判断是否存在商品信息一致的商品，若不存在，则执行步骤S403至步骤S404，若存在，则执行步骤S405至步骤S406。

在具体实现步骤S402的过程中，比较所述其他订单中的商品信息与所述商品对应的商品信息，在确定存在商品信息不一致的商品时，执行步骤S403至步骤S404，在确定存在商品信息一致的商品时，步骤S405至步骤S406。

步骤S403：确定所述商品处于第一次待被锁定。

步骤S404：利用第一版本号分布式锁算法确定是否获取到所述订单信息中商品的商品锁，若获取到，则执行步骤S407，若未获取到，则确定所述商品无法获取到对应的商品锁，此时将该订单中的商品释放。

在步骤S404中，第一版本号分布式锁算法包括普通版本号分布式锁算法和CAS自旋版本号分布式锁算法。

需要说明的是，具体实现步骤S404的过程与上述步骤S202的具体实现过程相同，可相互参见。

步骤S405：将存在商品信息一致的商品作为重入商品。

步骤S406：利用第二版本号分布式锁算法确定是否获取到所述订单信息中商品的商品锁，若获取到，则执行步骤S407，若未获取到，则确定所述商品无法获取到对应的商品锁，此时将该订单中的商品释放。

在步骤S406中，第二版本号分布式锁算法包括可重入版本号分布式锁算法。

步骤S31：确定所述商品被锁定的次数是否超过所述商品的库存数量，若未超过，返回锁获取成功标识为成功true，并执行步骤S32，若超过，返回锁获取不成功标识为失败false，并确定所述商品无法获取到对应的商品锁，即执行步骤S33，此时将该订单中的商品释放。

在具体实现步骤S31的过程中，在获取锁时，使用redis setNx方法确定所述商品被锁定的次数是否超过所述商品的库存数量，若未超过，返回锁获取成功标识为成功true，并执行步骤S32，若超过，返回锁获取不成功标识为失败false，并确定所述商品无法获取到对应的商品锁，即执行步骤S33，此时将该订单中的商品释放。

需要说明的是，利用redis setNx方法在获取锁时，生成对应的锁属性参数，锁属性参数包括标识key为锁key，锁key的值为锁线程号+锁版本号，每一获取一次锁，锁获取次数+1，设置set成功则表示获取到锁，锁获取成功标识为true，赋值当前时间为锁获取到时间，赋值锁持有超出时间为锁获取到时间+锁持有时间，set失败则表示未获取到锁，锁获取不成功标识为false，根据经验或实际情况设置的锁持有超出时间。

可选的，CAS可重入版本号分布式锁获取成功后，锁属性参数的信号游标+1，下次本锁对象再进行锁时，不再走上面获取锁流程，只对信号游标+1。

步骤S32：确定所述商品可获取对应的商品锁。

步骤S33：确定所述商品无法获取到对应的商品锁。

可选的，在开始获取锁时，记录锁开始获取时间，

可选的，在执行步骤S33之前，还包括：判断当前循环次数是否小于锁获取超出次数，并且当前循环获取锁时间小于获取锁超出时间；若前循环次数小于锁获取超出次数，并且当前循环获取锁时间小于获取锁超出时间，则循环索取锁，即循环执行步骤S31至步骤S33的过程，反之，则确定锁获取成功标识为false，并执行步骤S33。

其中，当前循环获取锁时间为锁开始获取时间与每一获取锁失败时，记录，即步骤S33示出的当前时间的差。

可选的，每次获取的锁都会累计存储下来，可以用来做锁资源竞争分析，或其他数据分析。

步骤S407：基于所述订单信息，确定所述订单信息中商品的版本号。

步骤S408：在确定基于所述商品锁对所述商品进行锁操作之后，基于锁属性参数确定与所述商品对应的锁参数，所述锁属性参数是在获取商品锁的过程中基于所述版本号生成的。

步骤S409：在所述锁属性参数中锁持有时间内接收到用户基于所述应用渠道提交的支付完成指令时，基于所述锁参数释放版本号。

需要说明的是，步骤S407至步骤S409的过程与上述步骤S203至步骤S205的具体实现过程相同，可相互参见。

在本发明实施例中，在确定用户提交订单但未支付成功，基于订单信息中的商品的商品信息和用户账户信息，确定所述商品处于第一次待被锁定时，利用第一版本号分布式锁算法确定是否获取到所述订单信息中商品的商品锁；如果获取到锁，会为锁对象，及订单中的商品生成对应的版本号，后续锁对象在释放锁时，只有持有这个版本号的锁对象线程才能释放，避免被其他线程锁对象错误释放。通过上述方式能够保住资源浪费与系统业务的稳定，而且能够提高应用的响应。

基于上述本发明实施例示出的一种商品处理方法，本发明实施例还对应示出了一种商品处理装置，如图5所示，为本发明实施例示出的一种商品处理装置的结构示意图，该装置包括：

第一确定单元501，用于在接收到用户基于应用渠道提交的订单信息时，基于所述订单信息中的商品的商品信息和用户账户信息，确定所述商品处于第一次待被锁定，所述订单信息中商品的数量至少为1个。

锁获取单元502，用于利用第一版本号分布式锁算法确定是否获取到所述订单信息中商品的商品锁，第一版本号分布式锁算法包括普通版本号分布式锁算法和CAS自旋版本号分布式锁算法。

第二确定单元503，用于若获取到，基于所述订单信息，确定所述订单信息中商品的版本号。

第三确定单元504，用于在确定基于所述商品锁对所述商品进行锁操作之后，基于锁属性参数确定与所述商品对应的锁参数，所述锁属性参数是在获取商品锁的过程中基于所述版本号生成的。

释放单元505，用于在所述锁属性参数中锁持有时间内接收到用户基于所述应用渠道提交的支付完成指令时，基于所述锁参数释放版本号。

需要说明的是，上述本发明实施例公开的商品处理装置中的各个单元具体的原理和执行过程，与上述本发明实施示出的商品处理方法相同，可参见上述本发明实施例公开的商品处理方法中相应的部分，这里不再进行赘述。

在本发明实施例中，在确定用户提交订单但未支付成功，基于订单信息中的商品的商品信息和用户账户信息，确定所述商品处于第一次待被锁定时，利用第一版本号分布式锁算法确定是否获取到所述订单信息中商品的商品锁；如果获取到锁，会为锁对象，及订单中的商品生成对应的版本号，后续锁对象在释放锁时，只有持有这个版本号的锁对象线程才能释放，避免被其他线程锁对象错误释放。通过上述方式能够保住资源浪费与系统业务的稳定，而且能够提高应用的响应。

可选的，基于上述示出的商品处理装置，还包括：处理单元，用于：基于所述用户账户查询信息，查询是否存在已锁定的与所述用户账户信息对应的其他订单；若不存在，确定所述商品处于第一次待被锁定；若存在，基于所述其他订单中的商品与所述商品对应的商品信息判断是否存在商品信息一致的商品；若不存在，则确定所述商品均处于第一次待被锁定；若存在，将存在商品信息一致的商品作为重入商品。

可选的，基于上述示出的商品处理装置，锁获取单元502，还用于：利用第二版本号分布式锁算法确定是否获取到所述订单信息中商品的商品锁，第二版本号分布式锁算法包括可重入版本号分布式锁算法。

可选的，基于上述示出的商品处理装置，所述利用第二版本号分布式锁算法确定是否获取到所述订单信息中商品的商品锁的锁获取单元502，具体用于：确定所述商品被锁定的次数是否超过所述商品的库存数量；若未超过，确定所述商品可获取对应的商品锁；若超过，确定所述商品无法获取对应的商品锁。

可选的，基于上述示出的商品处理装置，若第一版本号分布式锁算法为普通版本号分布式锁算法，所述利用第一版本号分布式锁算法确定是否获取到所述订单信息中商品的商品锁的锁获取单元502，具体用于：

利用第一版本号分布式锁算法确定所述订单信息中的商品是否存在库存；

若存在，确定所述订单信息中商品可获取对应的商品锁。

可选的，基于上述示出的商品处理装置，若第一版本号分布式锁算法为CAS自旋版本号分布式锁算法，所述利用第一版本号分布式锁算法确定是否获取到所述订单信息中商品的商品锁的锁获取单元502，具体用于：

利用CAS自旋版本号分布式锁算法对所述商品进行CAS处理，确定所述商品是否已被锁定；

若确定所述商品未被锁定，确定所述商品被锁定的次数是否超过所述商品的库存数量；

若确定所述商品已被锁定，确定所述商品被锁定的次数是否等于或小于所述商品的库存数量；

若所述商品被锁定的次数未超过所述商品的库存数量，或，所述商品被锁定的次数小于所述商品的库存数量，则确定所述商品可获取对应的商品锁；

若所述商品被锁定的次数等于所述商品的库存数量，则确定所述商品无法获取对应的商品锁。

本发明实施例还公开了一种电子设备，该电子设备用于运行数据库存储过程，其中，所述运行数据库存储过程时执行上述图2和图3公开的一种商品处理方法。

本发明实施例还公开了一种计算机存储介质，所述存储介质包括存储数据库存储过程，其中，在所述数据库存储过程运行时控制所述存储介质所在设备执行上述图2和图3公开的一种商品处理方法。

在本公开的上下文中，计算机存储介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。