分布式订单号生成方法和系统

技术领域

本申请涉及计算机技术领域，尤其涉及一种分布式订单号生成方法、系统、设备及计算机可读存储介质。

背景技术

随着互联网的发展，网络平台可以为用户提供各类交易。作为网络平台，为方便管理需要为每次交易生成一个订单号。现有的分布式系统，一般根据雪花算法(snowflake)生成订单号。雪花算法强依赖机器时钟，在单机系统上订单号(标识，Identifier)是递增的。但是在具有多节点的分布式系统上，由于各个节点时钟不能保证完全同步，所以订单号有可能不是全局递增，从而可能出现订单号重复的情况。另外，上述基于机器时钟生成订单号的做法不利于实现业务端个性化。

发明内容

本申请的目的是提供一种分布式订单号生成方法、系统、计算机设备及计算机可读存储介质，用于解决以下问题：容易出现重复的订单号和不利于业务端个性化。

本申请实施例的第一方面提供了一种分布式订单号生成方法，所述方法包括：接收业务端的订单号请求，所述订单号请求包括业务端类型信息和订单号数量信息；根据所述业务端类型信息，确定业务端标识数据；获取对应于所述订单号数量信息的多个组合数据，所述多个组合数据从目标队列取出或从数据池取出一个或多个原始组合数据并基于所述一个或多个原始组合数据生成；将所述业务端标识数据分别和所述多个组合数据中的每个组合数据进行拼接，生成多个订单号。

基于第一方面的第二方面，该目标队列为预先配置的多个队列之一；所述获取对应于所述订单号数量信息的多个组合数据，包括：响应于所述订单号请求，从所述多个队列中选择其中一个队列作为所述目标队列；判断所述目标队列的组合数据的数量是否不小于所述订单号数量信息中的订单号数量；若所述目标队列的组合数据的数据量不小于所述订单号数量，则从所述目标队列中取出所述多个组合数据；及若所述目标队列的组合数据的数据量小于所述订单号数量，则通过数据池获取所述多个组合数据。

基于第二方面的第三方面，所述数据池包括多个原始组合数据，每个原始组合数据包括长度均为M的K个原始数据，M、K为正整数；所述通过数据池获取所述多个组合数据，包括：根据所述订单号数量信息，从所述数据池中取出J个原始组合数据，J为正整数；通过在所述J个原始组合数据中的每个原始组合数据的K个原始数据的基础上分别加入长度为N的扩展数据，将所述J个原始组合数据扩展得到J*N

基于第一方面的第四方面，该目标队列为预先配置的多个队列之一；所述方法还包括更新所述多个队列中的各个队列中的组合数据：检测所述各个队列中的组合数据的数量，以确定所述多个队列是否包括待更新队列；及若所述多个队列包括所述待更新队列，则通过所述数据池将预设数量的组合数据加入到所述待更新队列。

基于第四方面的第五方面，所述数据池包括多个原始组合数据，每个原始组合数据包括长度均为M的K个原始数据，M、K为正整数；通过所述数据池将预设数量的组合数据加入到所述待更新队列，包括：从所述数据池中取出L个原始组合数据，L为正整数；通过所述L个原始组合数据中的每个原始组合数据的K个原始数据的基础上分别加入长度为N的扩展数据，将所述L个原始组合数据扩展得到J*N

基于第一方面至第五方面任意一项的第六方面，还包括调整所述业务端标识数据：判断所述数据池中的所有组合数据是否被取出完毕；及若所述数据池中的所有组合数据被取出完毕，则对所述业务端标识数据自增1。

基于第一方面至第五方面任意一项的第七方面，将所述业务端标识数据分别和所述多个组合数据中的每个组合数据进行拼接，生成多个订单号，包括：将所述业务端标识数据和业务端扩展数据分别和所述多个组合数据中的每个组合数据进行拼接，生成多个订单号；其中，每个订单号包括以预定位置顺序组合的所述业务端标识数据、所述多个组合数据中的其中一个组合数据和所述尾段数据，所述业务端扩展数据为可修改数据，以便业务端通过修改所述业务端扩展数据植入标识。

本申请实施例的一个方面又提供了一种分布式订单号生成系统，包括：包括：接收模块，用于接收业务端的订单号请求，所述订单号请求包括业务端类型信息和订单号数量信息；确定模块，用于根据所述业务端类型信息，确定业务端标识数据；获取模块，用于获取对应于所述订单号数量信息的多个组合数据，所述多个组合数据从目标队列取出或从数据池取出一个或多个原始组合数据并基于所述一个或多个原始组合数据生成；拼接模块，用于将所述业务端标识数据分别和所述多个组合数据中的每个组合数据进行拼接，生成多个订单号。

本申请实施例的一个方面又提供了一种计算机设备，所述计算机设备包括存储器、处理器以及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时用于实现上述分布式订单号生成方法的步骤。

本申请实施例的一个方面又提供了一种计算机可读存储介质，所述计算机可读存储介质内存储有计算机程序，所述计算机程序可被至少一个处理器所执行，以使所述至少一个处理器执行上述分布式订单号生成方法的步骤。

本申请实施例的一个方面又提供了一种一种分布式订单号生成系统，包括：队列组，包括并行的多个队列，用于通过所述多个队列存储用于生成订单号的多个组合数据；数据池，用于存放多个原始组合数据；及进程，用于检测各个队列中的组合数据的数量，并检测到其中一个队列中的组合数据的数量小于预设阈值时，则通过所述数据池将预设数量的组合数据加入到所述队列中。

可选的每个原始组合数据包括长度均为M的K个原始数据，M、K为正整数；所述进程，还用于：从所述数据池中取出L个原始组合数据，L为正整数；通过所述L个原始组合数据中的每个原始组合数据的K个原始数据的基础上分别加入长度为N的扩展数据，将所述L个原始组合数据扩展得到J*N

可选的，所述数据池还用于：当目标队列的组合数据的数量小于订单号数量，提供一个或多个原始组合数据以用于生成预设数量的组合数据；其中，所述预设数量的组合数据用于生成不少于所述订单号数量的订单号，所述目标队列是为响应订单号请求从所述多个队列中随机选择的一个队列，且所述订单号数量通过解析所述订单号请求得到。

本申请实施例提供的分布式订单号生成方法、系统、设备及计算机可读存储介质，包括以下优点：

(1)从目标队列直接取出多个组合数据或通过数据池生成多个组合数据，并将业务端标识数据分别和多个组合数据中的每个组合数据进行拼接，从而批量生成订单号。由于“被取出”之后，被取出的组合数据或原始组合数据均属于消耗数据，不会被重复使用，因此。本申请提供的方案，不会出现重复的订单号。另外，也不需要采用雪花算法所需的各个节点的时钟同步，对外部资源依赖少。

(2)在本申请提供的方案中，订单号由业务端标识数据和组合数据拼接而成，通过业务端标识数据有利于利于业务端个性化业务的实现，例如查询业务端来源等。

附图说明

图1示意性示出了根据本申请实施例的环境架构图；

图2示意性示出了根据本申请实施例一的分布式订单号生成方法的流程图；

图3示意性示出了队列的更新步骤；

图4为图3中步骤S302的子步骤流程图；

图5为图2中步骤S204的子步骤流程图；

图6为图5中步骤S506的子步骤流程图；

图7为示意性示出了业务端标识数据的调整步骤；

图8为图2中步骤S206的子步骤流程图；

图9示意性示出了根据本申请实施例二的分布式订单号生成方法的框图；以及

图10示意性示出了根据本申请实施例三的适于实现分布式订单号生成方法的计算机设备的硬件架构示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

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

本发明人发现，现有的分布式系统，一般根据雪花算法(snowflake)生成订单号。雪花算法强依赖机器时钟，在单机系统上订单号(ID)是递增的。但是在具有多节点的分布式系统上，由于各个节点时钟不能保证完全同步，所以订单号有可能不是全局递增，从而可能出现订单号重复的情况，而且对外部的资源依赖过多。另外，基于雪花算法生成的订单号不利于业务端个性化业务的实现，例如不能够根据订单号反推数据存储位置信息(数据所属的库，表)，业务端来源信息等。

有鉴于此，本申请将提供新的分布式订单号生成方案，可以生成无序不重复的分布式订单号，使得分布式订单号支持融入定位分表分库位置信息、业务端标识信息等。

在本申请的描述中，需要理解的是，步骤前的数字标号并不标识执行步骤的前后顺序，仅用于方便描述本申请及区别每一步骤，因此不能理解为对本申请的限制。

图1示出了分布式订单号生成方法的环境架构图。

如图1所示，所述环境示意图可以包括通过网络连接的分布式服务器100和业务端200。分布式服务器100可以位于诸如单个场所之类的数据中心，或者分布在不同的地理位置(例如，在多个场所)中。分布式服务器100可以经由网络提供服务。网络包括各种网络设备，例如路由器，交换机，多路复用器，集线器，调制解调器，网桥，中继器，防火墙，代理设备和/或类似。网络9可以包括物理链路，例如同轴电缆链路，双绞线电缆链路，光纤链路，其组合等。当然，所述网络也可以包括无线链路，诸如蜂窝链路，卫星链路，Wi-Fi链路等。其中：

业务端200，为服务器或用户终端等，可以服务各类交易的订单号业务，例如手办、票务等。下订单过程中，业务端200根据需要为每个订单分配一个订单号。因此，业务端200需要从分布式服务器100批量申请订单号，如可以每次请求1000个订单号以作备用。作为示例，业务端200可以根据预定规则触发上述请求，例如，当业务端200检测到自身仅剩下100个订单号时，则触发上述请求。

分布式服务器100，可以根据业务端200的请求生成一批订单号，并将该批订单号返回给业务端200。

每个订单号为预定的结构。作为示例，一个订单号可以按照长度划分为4段，第一段为业务端标识自增区，第二段和第三段为乱序区域，第四段为业务端扩展区域。以订单号“4008418430491418”为例：“400”对应所述业务端表示自增区，“8418430491”对应所述乱序区域，“418”对应所述业务端扩展区域。其中，在所述业务端扩展区域中的数据“418”可以被业务端200修改。例如业务端200可以根据分库分表规则，生成一个标记位，并用于修改或替换“418”供业务端200反查使用，使得订单号支持融入定位分表分库位置信息等，支持业务端实施个性化业务。

以下介绍“8418430491”的由来：

“8418430491”为一个组合数据(84184，30491)，由数据池的原始组合数据得到，具体如下：第一：随机生成大量的原始组合数据(id1，id2)，设置id1和id2的取值范围均为0-999，因此可以产生一百万个原始组合数据((184，491)则是则一百万原始组合数据之一)。第二：将这一百万个原始组合数据(id1，id2)打乱存入数据库以生成所述数据池。第三：从所述数据池中取出一个或多个原始组合数据，如取出(184，491)。第四：在每段数据的头部加上0到99，将(184，491)扩展为(xx184，xx491)，从而可以通过(184，491)这一个原始组合数据扩展出1万个不重复组合数据(xx184，xx491)。该组合数据(xx184，xx491)中的每段数据由3位扩展为5位(不足5位的在头部补0)。组合数据(84184，30491)为上述这1万个组合数据之一。以上介绍得到“8418430491”的方式之一。通过上述组合数据的得到方式，可以在低运算量的情形产生用于构成订单号的海量乱序数据。该海量乱序数据也确保订单号之间的不连续，从而保证安全性。

分布式服务器100中设有多个队列(如10个队列)。这10个队列用于存放组合数据，每个队列的存放基准为2万个组合数据，每个队列的最大存放容量为2.6万个组合数据。通过常驻进程的脚本以预定频率监听每个队列的组合数据的剩余数量。如果检测到某个队列(如队列X)的组合数据的剩余数量低于1.6万(即，存放基准的80％)，则分布式服务器100会从数据池中取出一个原始组合数据，并基于这个原始组合数据扩展得到1万个组合数据，并将这1万个组合数据填充到队列X中。

当分布式服务器100接收到业务端200的订单号请求(如请求8千个订单号)。分布式服务器300会随机挑选一个队列(如队列Y)，并获知队列Y当前是否存放有8千个以上的组合数据。如果队列Y存放有8千个以上的组合数据，则从队列Y取出8千个组合数据，将取出的8千个组合数据作为第二段的乱序数据和第三段的乱序数据，与第一段的业务端标识数据、第三段的业务端扩展数据进行组装，得到8千个由4段数据构成的订单号，并将这8千个由4段数据构成的订单号返回给业务端200。如果队列Y中的组合数据的数量当前低于8千，则从数据池中取出一个原始组合数据，将这个原始组合数据扩展为1万个组合数据，从这1万个组合数据中取出8千个组合数据返回给业务端200，将剩余的2千个组合数据随机存放到这10个队列的其中一个队列中。通过队列机制，可以提高订单号的生成和返回效率。需要说明的是，当接收到业务端200的订单号请求时，分布式服务器100不会遍历每个队列的组合数据的数量以基于遍历结果选择满足要求(即内部的组合数据的数量不低于业务端200要求的订单号数量信息)的队列，而是从这个10个队列中随机挑选一个队列(如队列Y)。在队列Y不满足条件的情况下，亦不会再寻求其他队列是否满足，而是直接通过数据池中的原始组合数据来生成订单号。这样做的目的在于降低时间复杂度和节省计算机资源。

需要说明的是，图1中的分布式服务器100、网络和业务端200的仅仅是示意性的。根据实际需要，可以具有任意数目的分布式服务器、网络和业务端(服务器等电子设备)。

以下将以计算机设备2为执行主体对本申请的分布式订单生成方法进行介绍。需要说明的是，计算机设备2为分布式服务器100，或为分布式服务器100的计算节点。

实施例一

图2示意性示出了根据本申请实施例一的分布式订单号生成方法的流程图。

如图2所示，该分布式订单号生成方法可以包括步骤S200～S208，其中：

步骤S200，接收业务端的订单号请求，所述订单号请求包括业务端类型信息和订单号数量信息。

不同的业务端对应不同的业务端类型信息。在订单号请求中，通过业务端类型信息来区别具体的业务端。作为示例，该业务端类型信息可以采用数字、字母等字符或字符串进行表示。

所述订单号请求，可以是基于HTTP(S)协议的请求，或基于其他传输的请求。

步骤S202，根据所述业务端类型信息，确定业务端标识数据。

例如，所述业务端类型信息对应为“票务”，则所述业务端标识数据为“4xx”，如“400”。所述业务端类型信息对应为“手办”，则所述业务端标识数据为“5xx”，如“500”。

步骤S204，获取对应于所述订单号数量信息的多个组合数据，所述多个组合数据从目标队列取出或从数据池取出一个或多个原始组合数据并基于所述一个或多个原始组合数据生成。

关于所述多个组合数据：

(一)可以直接从所述目标队列中取出，被取出的多个组合数据在所述目标队列中会被删除。

需要说明的是，所述目标队列都可以是先进先出队列，以可以是其他类型的队列。

所述目标队列为预先配置的多个队列之一。如图3所示，以下提供所述多个队列的组合数据的更新步骤：步骤S300，检测所述各个队列中的组合数据的数量，以确定所述多个队列是否包括待更新队列；及步骤S302，若所述多个队列包括所述待更新队列，则通过所述数据池将预设数量的组合数据加入到所述待更新队列。作为示例，计算机设备2可以配置有常驻进程的脚本，通过该常驻进程的脚本以预定频率检测每个队列的组合数据的剩余数量。如果检测到某个队列(如队列X)的组合数据的剩余数量低于预设数量或占比，则计算机设备2基于所述数据池得到预设数量的组合数据，并将该预定数量的组合数据加入到队列X中。在本实施例中，及时生成组合数据并将生成的组合数据补充到各个队列中，使得各个队列直接有效地提供业务端所需的组合数据，以实现订单号的快速生成和返回。

当检测一个待更新队列时，则需要基于数据池来生成组合数据并将生成的组合数据以补充到所述待更新队列中。以下将对所述数据池和所述更新过程进行详细介绍：

模块所述数据池；

用于存储海量且乱序的原始组合数据，所述海量且乱序的原始组合数据通过如下步骤得到：

步骤一：计算机设备2可以预先随机生成大量的原始组合数据(id1，id2，…idK)。

如上所述，每个原始组合数据由K段原始数据构成，每段原始数据的长度为M，K、M为正整数。

作为示例，如果每段原始数据的长度为3位数(每段原始数据的取值范围为000～999)，则可以生成1000

步骤二：计算机设备2将步骤一生成的原始组合数据打乱存入数据库以生成所述数据池。

②所述待更新队列的更新过程；

如图4所示，所述步骤S302可以包括步骤S400～S404，其中：步骤S400，从所述数据池中取出L个原始组合数据，L为正整数；步骤S402，通过所述L个原始组合数据中的每个原始组合数据的K个原始数据的基础上分别加入长度为N的扩展数据，将所述L个原始组合数据扩展得到J*N

(二)可以基于数据池实时生成所述多个组合数据。

如图5所示，所述步骤S204可以包括步骤S500～S506，其中：步骤S500，响应于所述订单号请求，从所述多个队列中选择其中一个队列作为所述目标队列；步骤S502，判断所述目标队列的组合数据的数量是否不小于所述订单号数量信息中的订单号数量；步骤S504，若所述目标队列的组合数据的数据量不小于所述订单号数量，则从所述目标队列中取出所述多个组合数据；及步骤S506，若所述目标队列的组合数据的数据量小于所述订单号数量，则通过数据池获取所述多个组合数据。在本实施例中，计算机设备2不会遍历每个队列的组合数据的数量以基于遍历结果选择满足要求(即内部的组合数据的数量不低于业务端200要求的订单号数量信息)的队列，而是从所述多个队列中随机挑选一个队列(如队列Y)。在队列Y不满足条件的情况下，亦不会再寻求其他队列是否满足，而是直接通过数据池中的原始组合数据来生成订单号。这样做的目的在于降低时间复杂度和节省计算机资源。

其中，步骤S506中的通过数据池获取所述多个组合数据，可以有多种实现方式。

作为其中一种方式，如图6所示，所述步骤S506可以通过如下步骤实现：步骤S600，根据所述订单号数量信息，从所述数据池中取出J个原始组合数据，J为正整数；步骤S600，通过在所述J个原始组合数据中的每个原始组合数据的K个原始数据的基础上分别加入长度为N的扩展数据，将所述J个原始组合数据扩展得到J*N

步骤S206，将所述业务端标识数据分别和所述多个组合数据中的每个组合数据进行拼接，生成多个订单号。

例如，所述业务端标识数据为“400”，所述多个组合数据包括：(00184，00491)、(01184，00491)、(02184，00491)、…，则将“400”、“00184”和“00491”拼接得到订单号“4000018400491”，将“400”、“01184”和“00491”拼接得到订单号“4000118400491”，将“400”、“02184”和“00491”拼接得到订单号“4000218400491”，…。

所述多个订单号用于返回给所述业务端。

所述业务端接收所述多个订单号，可以为每个订单从所述多个订单号中选择一个订单号。

本申请实施例提供的分布式订单号生成方法，包括以下优点：

(1)从目标队列直接取出多个组合数据或通过数据池生成多个组合数据，并将业务端标识数据分别和多个组合数据中的每个组合数据进行拼接，从而批量生成订单号。由于“被取出”之后，被取出的组合数据或原始组合数据均属于消耗数据，不会被重复使用，因此。本申请提供的方案，不会出现重复的订单号。另外，也不需要采用雪花算法所需的各个节点的时钟同步，对外部资源依赖少和保证系统的稳定性。

(2)在本申请提供的方案中，订单号由业务端标识数据和组合数据拼接而成，通过业务端标识数据有利于利于业务端个性化业务的实现，例如查询业务端来源等。

作为可选方案，数据池中的原始组合数据中有用完的时候，则就可能导致无订单号可用。为解决上述问题，所述业务端标识数据所在字段区域可以被设置为自增区域。如图7所示，所述方法还可以包括用于调整所述业务端标识数据的步骤，包括：步骤S700，判断所述数据池中的所有组合数据是否被取出完毕；及步骤S702，若所述数据池中的所有组合数据被取出完毕，则对所述业务端标识数据自增1。例如，所述业务端类型信息对应为“票务”，则所述业务端标识数据是初始值为“400”的“4xx”。当所述数据池中数据被全部取完，则将业务端标识数据从“400”调整为“401”。可知，在数据池不重新生成新的原始组合数据的情形下，可以通过调整业务端标识数据的方式生成不重复的订单号。以业务端标识数据“4xx”为例，从“400～499”均对应业务端“票务”，因此未破坏业务端的识别作用。

作为可选方案，可以在订单号配置个性化信息，如加入用于定位所属数据库表信息(数据所属的库、表)的信息，使得能够根据订单号反推数据存储位置信息等。如图8所示，所述步骤206还可以进一步包括步骤S800：将所述业务端标识数据和业务端扩展数据分别和所述多个组合数据中的每个组合数据进行拼接，生成多个订单号；其中，每个订单号包括以预定位置顺序组合的所述业务端标识数据、所述多个组合数据中的其中一个组合数据和所述尾段数据，所述业务端扩展数据为可修改数据，以便业务端通过修改所述业务端扩展数据植入标识。该业务端扩展数据通常在订单号尾部，有一个默认值(如，“999”)，业务端可以根据自己的分库分表规则，生成一个标记位。通过标识位替换上述“默认值”，用于反查操作。

为了便于理解，以下提供一个具体操作示例：

步骤①，接收业务端的订单号请求，该订单号请求中包含业务端类型信息、订单号数量信息。进入步骤S902。

步骤②，从多个队列中随机选一个队列作为目标队列，并判断所述目标队列中的组合数据的数量是否满足所述订单号数量信息。如果满足，则进入步骤③，否则进入步骤④。需说明，所述多个队列用于存放组合数据以便能够快速生成订单号返回给业务端。例如，每个队列的存放基准为2万个组合数据，每个队列的最大存放容量为2.6万个组合数据。通过常驻进程的脚本以预定频率检测每个队列的组合数据的剩余数量。如果检测到某个队列(如队列X)的组合数据的剩余数量低于1.6万(即，存放基准的80％)，则会从数据池中取出一个原始组合数据，并基于这个原始组合数据扩展得到1万个组合数据，并将这1万个组合数据加入到队列X中。需说明，如果所述订单号数据量大于队列的存放基准对应的数量，则亦进入步骤④。

步骤③，从所述目标队列中获取对应于所述订单号数量信息的多个组合数据。进入步骤⑤。需说明，所述目标队列可以是先进先出队列，被取出的多个组合数据自动从所述目标队列中删除。

步骤④，从所述数据池取出一个或多个原始组合数据，并根据一个或多个原始组合数据生成大量的组合数据。进入步骤⑤。

步骤⑤，进行订单号的组装以生成多个订单号：例如，将业务端标识数据作为第一段数据、将所述多个组合数据的其中一个组合数据作为中间段数据，将业务端扩展数据(默认值)作为尾段数据。当然，各段数据的固定位置可预先设置。

步骤⑥，将步骤⑤组装得到的多个点单号返回给业务端。业务端可以根据自己的分库分表规则，生成一个标记位。通过标识位替换上述“默认值”，用于反查操作。

实施例二

图9示意性示出了根据本申请实施例二的分布式订单号生成方法的框图，该分布式订单号生成方法可以被分割成一个或多个程序模块，一个或者多个程序模块被存储于存储介质中，并由一个或多个处理器所执行，以完成本申请实施例。本申请实施例所称的程序模块是指能够完成特定功能的一系列计算机程序指令段，以下描述将具体介绍本实施例各程序模块的功能。

如图9所示，该分布式订单号生成系统900可以包括接收模块910、确定模块920、获取模块930、拼接模块940以及返回模块950，其中：

接收模块910，用于接收业务端的订单号请求，所述订单号请求包括业务端类型信息和订单号数量信息；

确定模块920，用于根据所述业务端类型信息，确定业务端标识数据；

获取模块930，用于获取对应于所述订单号数量信息的多个组合数据，所述多个组合数据从目标队列取出或从数据池取出一个或多个原始组合数据并基于所述一个或多个原始组合数据生成；

拼接模块940，用于将所述业务端标识数据分别和所述多个组合数据中的每个组合数据进行拼接，生成多个订单号。

在示例性的实施例中，该目标队列为预先配置的多个队列之一；所述获取模块930，用于：

响应于所述订单号请求，从所述多个队列中选择其中一个队列作为所述目标队列；

判断所述目标队列的组合数据的数量是否不小于所述订单号数量信息中的订单号数量；

若所述目标队列的组合数据的数据量不小于所述订单号数量，则从所述目标队列中取出所述多个组合数据；及

若所述目标队列的组合数据的数据量小于所述订单号数量，则通过数据池获取所述多个组合数据。

在示例性的实施例中，所述数据池包括多个原始组合数据，每个原始组合数据包括长度均为M的K个原始数据，M、K为正整数；所述通过数据池获取所述多个组合数据，包括：

根据所述订单号数量信息，从所述数据池中取出J个原始组合数据，J为正整数；

通过在所述J个原始组合数据中的每个原始组合数据的K个原始数据的基础上分别加入长度为N的扩展数据，将所述J个原始组合数据扩展得到J*N

从所述J*N

若所述J*N

在示例性的实施例中，该目标队列为预先配置的多个队列之一；所述系统还包括队列更新模块(未标识)，用于：更新所述多个队列中的各个队列中的组合数据：

检测所述各个队列中的组合数据的数量，以确定所述多个队列是否包括待更新队列；及

若所述多个队列包括所述待更新队列，则通过所述数据池将预设数量的组合数据加入到所述待更新队列。

在示例性的实施例中，所述数据池包括多个原始组合数据，每个原始组合数据包括长度均为M的K个原始数据，M、K为正整数；通过所述数据池将预设数量的组合数据加入到所述待更新队列，包括：

从所述数据池中取出L个原始组合数据，L为正整数；

通过所述L个原始组合数据中的每个原始组合数据的K个原始数据的基础上分别加入长度为N的扩展数据，将所述L个原始组合数据扩展得到J*N

将所述L*N

在示例性的实施例中，所述系统还包括调整模块队列更新模块(未标识)，用于调整所述业务端标识数据：

判断所述数据池中的所有组合数据是否被取出完毕；及

若所述数据池中的所有组合数据被取出完毕，则对所述业务端标识数据自增1。

在示例性的实施例中，所述拼接模块940，还用于：

将所述业务端标识数据和业务端扩展数据分别和所述多个组合数据中的每个组合数据进行拼接，生成多个订单号；其中，每个订单号包括以预定位置顺序组合的所述业务端标识数据、所述多个组合数据中的其中一个组合数据和所述尾段数据，所述业务端扩展数据为可修改数据，以便业务端通过修改所述业务端扩展数据植入标识。

实施例三

图10示意性示出了根据本申请实施例三的适于实现分布式订单号生成方法的计算机设备的硬件架构示意图。计算机设备2可以是分布式服务器100或分布式服务器100的一部分。本实施例中，计算机设备2是一种能够按照事先设定或者存储的指令，自动进行数值计算和/或信息处理的设备。例如，可以是机架式服务器、刀片式服务器、塔式服务器或机柜式服务器(包括独立的服务器，或者多个服务器所组成的服务器集合群)等。如图10所示，计算机设备2至少包括但不限于：可通过系统总线相互通信链接存储器1010、处理器1020、网络接口1030。其中：

存储器1010至少包括一种类型的计算机可读存储介质，可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，存储器1010可以是计算机设备2的内部存储模块，例如该计算机设备2的硬盘或内存。在另一些实施例中，存储器1010也可以是计算机设备2的外部存储设备，例如该计算机设备2上配备的插接式硬盘，智能存储卡(Smart Media Card，简称为SMC)，安全数字(Secure Digital，简称为SD)卡，闪存卡(FlashCard)等。当然，存储器1010还可以既包括计算机设备2的内部存储模块也包括其外部存储设备。本申请实施例中，存储器1010通常用于存储安装于计算机设备2的操作系统和各类应用软件，例如分布式订单号生成方法的程序代码等。此外，存储器1010还可以用于暂时地存储已经输出或者将要输出的各类数据。

处理器1020在一些实施例中可以是中央处理器(Central Processing Unit，简称为CPU)、控制器、微控制器、微处理器、或其他数据处理芯片。该处理器1020通常用于控制计算机设备2的总体操作，例如执行与计算机设备2进行数据交互或者通信相关的控制和处理等。本实施例中，处理器1020用于运行存储器1010中存储的程序代码或者处理数据。

网络接口1030可包括无线网络接口或有线网络接口，该网络接口1030通常用于在计算机设备2与其他计算机设备之间建立通信链接。例如，网络接口1030用于通过网络将计算机设备2与外部终端相连，在计算机设备2与外部终端之间的建立数据传输通道和通信链接等。网络可以是企业内部网(Intranet)、互联网(Internet)、全球移动通讯系统(GlobalSystem of Mobile communication，简称为GSM)、宽带码分多址(Wideband Code DivisionMultiple Access，简称为WCDMA)、4G网络、5G网络、蓝牙(Bluetooth)、Wi-Fi等无线或有线网络。

需要指出的是，图10仅示出了具有部件1010-1030的计算机设备，但是应理解的是，并不要求实施所有示出的部件，可以替代的实施更多或者更少的部件。

在本实施例中，存储于存储器1010中的分布式订单号生成方法还可以被分割为一个或者多个程序模块，并由一个或多个处理器(本实施例为处理器1020)所执行，以完成本申请。

实施例四

本实施例还提供一种计算机可读存储介质，计算机可读存储介质其上存储有计算机程序，计算机程序被处理器执行时实现实施例中的分布式订单号生成方法的步骤。

本实施例中，计算机可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如，SD或DX存储器等)、随机访问存储器(RAM)、静态随机访问存储器(SRAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、可编程只读存储器(PROM)、磁性存储器、磁盘、光盘等。在一些实施例中，计算机可读存储介质可以是计算机设备的内部存储单元，例如该计算机设备的硬盘或内存。在另一些实施例中，计算机可读存储介质也可以是计算机设备的外部存储设备，例如该计算机设备上配备的插接式硬盘，智能存储卡(Smart Media Card，简称为SMC)，安全数字(Secure Digital，简称为SD)卡，闪存卡(Flash Card)等。当然，计算机可读存储介质还可以既包括计算机设备的内部存储单元也包括其外部存储设备。本实施例中，计算机可读存储介质通常用于存储安装于计算机设备的操作系统和各类应用软件，例如实施例中的分布式订单号生成方法的程序代码等。此外，计算机可读存储介质还可以用于暂时地存储已经输出或者将要输出的各类数据。

实施例五

继续参考图1，本实施例还提供了分布式订单号生成系统，包括：

队列组，包括并行的多个队列，用于通过所述多个队列存储用于生成订单号的多个组合数据；

数据池，用于存放多个原始组合数据；及

进程，用于检测各个队列中的组合数据的数量，并检测到其中一个队列中的组合数据的数量小于预设阈值时，则通过所述数据池将预设数量的组合数据加入到所述队列中。

示例性的，每个原始组合数据包括长度均为M的K个原始数据，M、K为正整数；所述进程，还用于：从所述数据池中取出L个原始组合数据，L为正整数；通过所述L个原始组合数据中的每个原始组合数据的K个原始数据的基础上分别加入长度为N的扩展数据，将所述L个原始组合数据扩展得到J*N

示例性的，所述数据池还用于：当目标队列的组合数据的数量小于订单号数量，提供一个或多个原始组合数据以用于生成预设数量的组合数据；其中，所述预设数量的组合数据用于生成不少于所述订单号数量的订单号，所述目标队列是为响应订单号请求从所述多个队列中随机选择的一个队列，且所述订单号数量通过解析所述订单号请求得到。

需要说明的是，本实施例中的技术细节可以参考其他实施例，本本实施例不再赘述。

显然，本领域的技术人员应该明白，上述的本申请实施例的各模块或各步骤可以用通用的计算装置来实现，它们可以集合中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集合成电路模块，或者将它们中的多个模块或步骤制作成单个集合成电路模块来实现。这样，本申请实施例不限制于任何特定的硬件和软件结合。

需要说明的是，视频作为信息主要传播方式之一，实现自动化、智能化的视频内容处理和分发是处理海量视频的必经之路。类似的还有商品推荐和内容推荐，根据物品信息和用户的点击收藏等行为，为用户推荐感兴趣的物品。在互联网推荐广告中，特征工程将原始数据(用户和物品)空间映射到新的特征向量空间，使模块能够更好地学习数据中的规律。用户与视频、广告主、环境交互的复杂网络也就是原始数据，挖掘有效特征通过模块学习用户和物品间点击的概率分布是提升业务指标的有效策略。在本申请中，挖掘了大量被业界忽视的视频特征，极大提高了预估准确性。

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