CN115794876A - 针对业务数据包的分片处理方法、装置、设备及存储介质 - Google Patents

Abstract

本申请公开了一种针对业务数据包的分片处理方法、装置、设备及存储介质。该方法包括：获取待处理的业务数据包；根据多条用户信息的数量、已转存用户信息的数量和预设数量阈值确定多条用户信息对应的分片标识；按照分片标识将多条用户信息写入缓存数据库中；当分片标识对应的分片中用户信息的数量满足预设数量阈值的要求时，将分片标识对应的分片迁移至目标数据库中。基于分片思想对业务数据包中的用户信息进行两级存储以提高读取性能。在此基础上，作为最终存储的目标数据库可以不局限于使用内存型存储系统，可以支持多种存储类型，可以采用更节省成本的其他类型存储系统。本申请实施例可以应用于云技术、人工智能、智慧交通、车联网等各种场景。

Description

针对业务数据包的分片处理方法、装置、设备及存储介质

技术领域

本申请涉及互联网通信技术领域，尤其涉及一种针对业务数据包的分片处理方法、装置、设备及存储介质。

背景技术

随着互联网通信技术的迅猛发展，互联网产品在为用户提供相关产品服务的同时所面临的业务场景也越来越复杂。以对于业务数据的存储为例，为保证较高的读取速度，相关技术中常将数据直接存储在内存型存储系统(比如机器内存)中，以直接访问该系统进行数据读取。然而，内存型存储系统的成本较高，对于大体量的业务数据上述相关技术中的方案并不适用。因此，需要提供兼顾成本和读取速度的业务数据存储方案。

发明内容

为了解决现有技术应用在存储业务数据时，存储成本高、不适用对大体量的业务数据进行存储等问题，本申请提供了一种针对业务数据包的分片处理方法、装置、设备及存储介质：

根据本申请的第一方面，提供了一种针对业务数据包的分片处理方法，所述方法包括：

获取待处理的业务数据包；其中，所述待处理的业务数据包包括指示指定数据包标识的多条用户信息，所述待处理的业务数据包是分批次发送的多个业务请求中任一所述业务请求所携带的内容，所述多个业务请求均指示所述指定数据包标识；

根据所述多条用户信息的数量、已转存用户信息的数量和预设数量阈值确定所述多条用户信息对应的分片标识；其中，所述已转存用户信息对应的数据包标识为所述指定数据包标识，所述预设数量阈值指示提供分片读取服务的目标数据库对于分片中用户信息的数量的上限；

按照所述分片标识将所述多条用户信息写入缓存数据库中；

当所述分片标识对应的分片中用户信息的数量满足所述预设数量阈值的要求时，将所述分片标识对应的分片迁移至所述目标数据库中。

根据本申请的第二方面，提供了一种针对业务数据包的分片处理装置，所述装置包括：

获取模块：用于获取待处理的业务数据包；其中，所述待处理的业务数据包包括指示指定数据包标识的多条用户信息，所述待处理的业务数据包是分批次发送的多个业务请求中任一所述业务请求所携带的内容，所述多个业务请求均指示所述指定数据包标识；

确定模块：用于根据所述多条用户信息的数量、已转存用户信息的数量和预设数量阈值确定所述多条用户信息对应的分片标识；其中，所述已转存用户信息对应的数据包标识为所述指定数据包标识，所述预设数量阈值指示提供分片读取服务的目标数据库对于分片中用户信息的数量的上限；

缓存模块：用于按照所述分片标识将所述多条用户信息写入缓存数据库中；

迁移模块：用于当所述分片标识对应的分片中用户信息的数量满足所述预设数量阈值的要求时，将所述分片标识对应的分片迁移至所述目标数据库中。

根据本申请的第三方面，提供了一种电子设备，所述电子设备包括处理器和存储器，所述存储器中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由所述处理器加载并执行以实现如第一方面所述的针对业务数据包的分片处理方法。

根据本申请的第四方面，提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由处理器加载并执行以实现如第一方面所述的针对业务数据包的分片处理方法。

根据本申请的第五方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行如第一方面所述的针对业务数据包的分片处理方法。

本申请提供的一种针对业务数据包的分片处理方法、装置、设备及存储介质，具有如下技术效果：

本申请通过获取待处理的业务数据包，然后根据其中多条用户信息的数量、已转存用户信息的数量和预设数量阈值确定多条用户信息对应的分片标识，再按照分片标识将多条用户信息写入缓存数据库中，以及当分片标识对应的分片中用户信息的数量满足预设数量阈值的要求时，将分片标识对应的分片迁移至目标数据库中。其中，待处理的业务数据包是分批次发送的多个业务请求中任一业务请求所携带的内容，多个业务请求指示同一数据包标识，已转存用户信息对应的数据包标识和多条用户信息对应的数据包标识相同。本申请应用于业务方分批次的发送业务请求的场景，其中每个业务请求携带一业务数据包，一个业务数据包包括多条用户信息。基于分片思想对业务数据包中的用户信息进行两级存储。面对不同业务请求所指示的用户信息的数量不同的情形，利用指示分片大小的预设数量阈值对接收到的用户信息进行固定大小的分片整合，并将满足要求的分片从缓存迁移至目标数据库以便于分片读取服务的实现，这样可以提高读取性能。在此基础上，作为最终存储的目标数据库可以不局限于使用内存型存储系统，可以支持多种存储类型，可以采用更节省成本的其他类型存储系统。

附图说明

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

图1是本申请实施例提供的一种应用环境的示意图；

图2是本申请实施例提供的一种针对业务数据包的分片处理方法的流程示意图；

图3是本申请实施例提供的确定指定数据包标识的一种流程示意图；

图4是本申请实施例提供的确定分片标识的一种流程示意图；

图5是本申请实施例提供的号码包系统的分层架构图；

图6是本申请实施例提供的号码包系统的模块架构图；

图7是本申请实施例提供的针对开始指令的响应流程示意图；

图8也是本申请实施例提供的一种针对业务数据包的分片处理方法的流程示意图；

图9是本申请实施例提供的针对结束指令的响应流程示意图；

图10也是本申请实施例提供的号码包系统的模块架构图；

图11是本申请实施例提供的对用户信息进行两级存储的示意图；

图12是本申请实施例提供的对用户信息进行版本维护的示意图；

图13是本申请实施例提供的一种针对业务数据包的分片处理装置的组成框图；

图14是本申请实施例提供的一种电子设备的结构示意图。

具体实施方式

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

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或服务器不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

对本申请实施例进行进一步详细说明之前，对本申请实施例中涉及的名词和术语进行说明，本申请实施例中涉及的名词和术语适用于如下的解释。

数据库(Database，DB)：它可视为电子化的文件柜——存储电子文件的处所，用户可以对文件中的数据进行新增、查询、更新、删除等操作。所谓“数据库”是以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。

分布式系统：它是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。

消息队列：在消息的传输过程中保存消息的容器。

数据实时分片：在一个分布式系统中，对一些持续推送过来的大小不定的数据请求，借助分布式存储系统作为中间缓存，攒成大小固定的数据分片，写入最终的存储中。

SDK(Software Development Kit)：软件开发工具包。

COS(Cloud Object Service)：对象存储服务。

BDB(Berkeley Database)：一种数据库。

Redis(Remote Dictionary Server)：远程字典服务，一种数据库。

Kafka：一种高吞吐量的分布式发布订阅消息系统。

MDB(Microsoft Database)：一种数据库。

APP(Application)：应用软件。

请参阅图1，图1是本申请实施例提供的一种应用环境的示意图，该应用环境中可以包括客户端10和服务端20，服务端20基于分片思想对业务数据包中的用户信息进行两级存储，业务数据包来自于服务端20接收到的业务请求。用户可以通过客户端10向服务端20发送数据更新请求，服务端20根据接收到的数据更新请求对存储的用户信息进行读取以确定与该请求适配的用户信息并返回至客户端10。客户端10与服务端20可以通过有线或无线通信方式进行直接或间接地连接。需要说明的是，图1仅仅是一种示例。

客户端10可以是智能手机、电脑(如台式电脑、平板电脑、笔记本电脑等)、增强现实(augmented reality，AR)/虚拟现实(virtual reality，VR)设备、数字助理、智能可穿戴设备、智能语音交互设备(如智能音响等)、智能家电、车载终端等类型的实体设备，也可以是运行于实体设备中的软体，比如计算机程序。客户端所对应的操作系统可以包括安卓系统(Android系统)、iOS系统(是由苹果公司开发的移动操作系统)、linux系统(一种操作系统)、Microsoft Windows系统(微软视窗操作系统)等。

服务端20可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(Content Delivery Network，内容分发网络)以及大数据和人工智能平台等基础云计算服务的云服务器。其中服务器可以包括有网络通信单元、处理器和存储器等等。服务端可以为对应的客户端提供后台服务。

在实际应用中，可以将本申请提供的针对业务数据包的分片处理方案的执行主体视作一个号码包系统，参见图5-10。如图6所示，待处理的业务数据包的数据来源包括1)通过管理台前端手动上传的数据；2)写至COS的数据；3)推至号码包推送服务的数据。其中1)和2)涉及的数据通过下载服务到的号码包推送服务。本申请提供的方案主要针对3)涉及的数据，当然也适用于1)和2)涉及的数据。

可以将该号码包系统视作一个分布式系统，对一些持续推送过来的大小不定的数据请求，借助分布式存储系统作为中间缓存，攒成大小固定的数据分片，写入最终的存储中。其中分布式存储系统和/或最终的存储可以部署于多个服务器上。因此，如本申请所公开的针对业务数据包的分片处理方法或装置，其中多个服务器可组成为一区块链，而服务器为区块链上的节点。

以下介绍本申请一种针对业务数据包的分片处理方法的具体实施例，图2是本申请实施例提供的一种针对业务数据包的分片处理方法的流程示意图，本申请提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的系统或产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。具体的如图2所示，所述方法可以包括：

S201：获取待处理的业务数据包；其中，所述待处理的业务数据包包括指示指定数据包标识的多条用户信息，所述待处理的业务数据包是分批次发送的多个业务请求中任一所述业务请求所携带的内容，所述多个业务请求均指示所述指定数据包标识；

在本申请实施例中，服务端获取待处理的业务数据包。该待处理的业务数据包来自上游业务方发送的业务请求。上游业务方可以分批次的向服务端发送指示同一业务的多个业务请求，该待处理的业务数据包可以来自多个业务请求中的任一个。由于多个业务请求指示同一业务，那么多个业务请求指示同一数据包标识(包ID)，也即所指示的数据包标识和所指示的业务具有关联关系。多个业务请求分批次的被发送，每批次发送的业务请求所携带的业务数据包中用户信息的数量可以不同，比如业务请求1携带200条用户信息、业务请求2携带300条用户信息。这里服务端获取的待处理的业务数据包包括指示指定数据包标识的多条用户信息。示例性的，上游业务方发送的多个业务请求可以指示“画像业务”，业务请求所携带的业务数据包中的用户信息可以是用户画像标签。一般而言，一条用户信息对应一个用户。需要说明的是，服务端可以接收来自至少两个上游业务方的业务请求，每个上游业务方可以负责至少两个业务，相应的，每个上游业务方可以向服务端发送指示至少两个业务的业务请求。在实际应用中，上游业务方可以与服务端同属一个后台系统，上游业务方也可以隶属第三方。另外，上述“画像业务”可以是针对车联网各场景的应用或者智慧交通方面的应用，上述“用户画像标签”可以指示司乘相关人员的特征。

在一示例性的实施方式中，如图3所示，在获取待处理的业务数据包之前，所述方法还包括：

S301：响应于接收到的所述业务请求，确定所述业务请求对应的第一业务标识、第二业务标识和数据版本信息；

S302：根据所述第一业务标识和所述第二业务标识，在索引数据库查找是否存在相匹配的数据包标识；其中，所述索引数据库用于记录数据包标识与其关联对象间的关系；

S303：当存在时，将所述相匹配的数据包标识作为所述指定数据包标识，以及将所述数据版本信息写入第一目标关联对象中；其中，所述第一目标关联对象为所述索引数据库中所述相匹配的数据包标识的关联对象；

S304：当不存在时，基于所述第一业务标识和所述第二业务标识创建对应的数据包标识以作为所述指定数据包标识，以及将第一业务标识、第二业务标识和所述数据版本信息写入第二目标关联对象中；其中，所述第二目标关联对象为所述索引数据库中所述对应的数据包标识的关联对象。

上游业务方所发送的业务请求携带有第一业务标识、第二业务标识用于描述相关业务信息。服务端基于第一业务标识、第二业务标识在索引数据库(索引redis)查找是否存在相匹配的数据包标识，索引数据库用于记录数据包标识与其关联对象间的关系，比如记录数据包标识与作为关联对象的业务标识组(第一业务标识-第二业务标识)之间的关系。当存在相匹配的数据包标识时，服务端将相匹配的数据包标识作为指定数据包标识，以及将数据版本信息写入第一目标关联对象中，第一目标关联对象为索引数据库中相匹配的数据包标识的关联对象。示例性的，第一业务标识为appID，第二业务标识为业务标签A。若存在相匹配的数据包标识，则说明索引redis中记录有包ID：xxxxxx与业务标识组：appID-业务标签A之间的映射关系。包ID：xxxxxx是相匹配的数据包标识、指定数据包标识，业务标识组是该数据包标识的关联对象。可以理解，以业务标识组：appID-业务标签A作为检索词，可以在索引redis中检索到包ID：xxxxxx。相应的，将数据版本信息也写入上述关联对象中。

当不存在相匹配的数据包标识时，服务端基于第一业务标识和第二业务标识创建对应的数据包标识以作为指定数据包标识，以及将第一业务标识、第二业务标识和数据版本信息写入第二目标关联对象中，第二目标关联对象为索引数据库中对应的数据包标识的关联对象。结合上面的示例，若不存在相匹配的数据包标识，则说明索引redis中没有记录与业务标识组：appID-业务标签A存在映射关系的包ID。可以理解，以业务标识组：appID-业务标签A作为检索词，无法在索引redis中检索到相关包ID。由此，为业务标识组创建对应的数据包标识，并利用索引redis记录该数据包标识与业务标识组、数据版本信息间的关系，其中业务标识组、数据版本信息作为该数据包标识的关联对象。数据包标识的创建、匹配，帮助建立了数据包标识维度的业务数据包分片处理方案，可以方便的对上游业务方提供的业务标识进行转换，能够准确捕捉上游业务方提供的业务标识所指示的业务精度。

上游业务方分批次的向服务端发送指示同一业务的多个业务请求，这些业务请求可以指示同一版本，也可以指示不同版本。比如，分批次向服务端发送的指示业务甲的业务请求100-150指示版本V2.2，分批次向服务端发送的指示业务甲的业务请求151-222指示版本V2.3。即便指示同一业务，当业务请求指示不同版本时，记录数据版本信息可以帮助后续对于属于同一版本的业务数据包进行递增式的分片标识分配操作，可以提高后续对于分批次发送的多个业务请求分别携带的业务数据包的分片整合能力。

上游业务方所发送的业务请求携带有第一业务标识、第二业务标识、业务数据包和数据版本信息。经上述指定数据包标识确定之后，可以用该指定数据包标识表征相关业务请求所携带的业务数据包。相应的，这里待处理的业务数据包包括的多条用户信息指示该指定数据包标识。

在实际应用中，上游业务方分批次的向服务端发送指示同一业务的多个业务请求，对于其中指示同一版本的多个业务请求，上游业务方可以在向服务端发送这些业务请求之前，向服务端发送开始指令。如果将本申请提供的针对业务数据包的分片处理方案的执行主体视作一个号码包系统，该系统包括索引redis、号码包推送服务、号码包管理服务和号码包写服务。开始指令旨在通知号码包系统业务方即将开始推送数据，请求号码包系统分配包ID。参见图7，开始指令携带有带上appID(对应上述第一业务标识)、thirdID(对应上述第二业务标识)、数据版本等，请求号码包推送服务的开始接口。号码包推送服务根据appID+thirdID在索引redis里查询包ID，1)如果这个包之前推送过，这里可以查到包ID，那么在索引redis记录下本次推送的索引信息(比如数据版本信息)，然后给业务方返回查询到的包ID；2)如果是第一次推，这里则查不到包ID，那么请求号码包管理服务新增包ID，然后在索引redis记录下本次推送的索引信息(比如新增的包ID、appID+thirdID以及数据版本信息)，给业务方返回新增的包ID。需要说明的是，对于索引redis中所记录的信息可以视作号码包元信息，对于信息记录涉及的操作可以视作原子操作。

上游业务方利用开始指令请求到了包ID，可以开始分批次的向服务端发送指示同一业务的多个业务请求，这些业务请求所携带的内容可以仅有业务数据包、包ID，也可以加上数据版本信息、第一业务标识、第二业务标识。参见图8，写数据请求(业务请求)由业务方通过写数据接口推送而来，每个写数据请求里携带一定数量的用户信息，业务方通过多次调用写数据接口来完成数据推送。

在一示例性的实施方式中，在所述获取待处理的业务数据包之后，所述方法还包括下述步骤：首先，拼接所述用户信息所携带的用户标识、所对应的所述指定数据包标识和所指示的数据版本信息，得到所述用户信息对应的特征对象；然后，基于所述用户信息对应的特征对象，在所述缓存数据库和所述目标数据库中查找是否存在特征对象相匹配的用户信息；最后，当存在时，从所述多条用户信息中移除所述用户信息。

考虑到上游业务方出于自身原因可能进行相关用户信息的重复发送，以及上游业务方在调用相关接口向服务端进行数据发送时，可能因超时等原因导致对相关用户信息的重复发送，因此对待处理的业务数据包进行用户信息的去重处理，对重复的用户信息进行有效过滤，避免将重复信息引入相关分片，保证用于分片存储的缓存数据库和目标数据库不因重复信息造成存储资源浪费和存储成本增加。

一般而言，一条用户信息对应一个用户，用户信息所携带的用户标识指示了用户维度。对用户信息所携带的用户标识、用户信息所对应的指定数据包标识和所指示的数据版本信息进行拼接，得到该用户信息对应的特征对象。结合前述步骤S301-S304中对于“指定数据包标识”以及“数据版本信息”的相关记载，特征对象中不仅融入了用户维度的信息，还融入了业务维度、版本维度的信息，由此特征对象能够实现对用户信息更准确的表征，以特征对象作为用户信息去重的匹配对象也可以保证去重的准确性和效率。基于用户信息对应的特征对象，可以利用布隆过滤器在缓存数据库和目标数据库中查找是否存在特征对象相匹配的用户信息。当存在相匹配的用户信息时，从待处理的业务数据包的多条用户信息中移除该用户信息，以实现去重。示例性的，待处理的业务数据包中的用户信息x，用户信息x对应特征对象x。可以理解用户信息x携带有作为变量1的用户ID、作为变量2的包ID以及作为变量3的版本号，特征对象x是利用上述三个变量拼接得到的。利用特征对象x与缓存数据库和目标数据库中当前存储的用户信息对应的特征对象匹配。若存在，则说明缓存数据库或目标数据库中已经存在该用户信息x。

在实际应用中，参见图6、8，如果将本申请提供的针对业务数据包的分片处理方案的执行主体视作一个号码包系统，该系统包括号码包写服务和去重服务。去重服务。可以由号码包写服务获取待处理的业务数据包，由号码包写服务判断是否需要对该待处理的业务数据包进行去重处理，当判断需要进行去重处理时则请求去重服务来进行去重处理。对于号码包写服务，若待处理的业务数据包指示相关业务或者相关版本的首个业务数据包，那么可以判断不需要进行去重处理。

在一示例性的实施方式中，服务端可以从消息队列中取出待处理的业务数据包。所述消息队列用于存储接收到的业务请求所携带的业务数据包，所述接收到的业务请求中各业务请求所指示的数据包标识有至少两个。

这里的消息队列可以来自Kafka，利用消息队列存储接收到的业务请求所携带的业务数据包，可以起到削峰的作用，可以不受上游业务方推送速度的影响。这里的接收到的业务请求不限于同一上游业务方分批次发送的多个业务请求，还包括不同上游业务方分批次发送的多个业务请求。

在实际应用中，参见图6、8-10，如果将本申请提供的针对业务数据包的分片处理方案的执行主体视作一个号码包系统，该系统包括号码包推送服务、Kafka和号码包写服务。号码包推送服务接收到来自上游业务方发送的业务请求，将其中的业务数据包发送到Kafka。号码包写服务作为消费者可以从Kafka获取待处理的业务数据包以消费数据。为适应写服务性能的变化，可以根据需要增加或者减少作为消费者的号码包写服务的数量，一个号码包写服务可以视作一个或者一组机器设备。

S202：根据所述多条用户信息的数量、已转存用户信息的数量和预设数量阈值确定所述多条用户信息对应的分片标识；其中，所述已转存用户信息对应的数据包标识为所述指定数据包标识，所述预设数量阈值指示提供分片读取服务的目标数据库对于分片中用户信息的数量的上限；

在本申请实施例中，服务端根据多条用户信息的数量、已转存用户信息的数量和预设数量阈值确定多条用户信息对应的分片标识，也即为待处理的业务数据包确定对应的分片标识。不同业务数据包所包括的用户信息的数量不同，利用分片的思想将指示同一数据包标识的用户信息进行整合以存储，可以利用指示分片的预设数量阈值来规范用户信息的存储结构，以形成便于提高读服务性能的分片。在已知待存储的用户信息的数量、已存储的用户信息的数量和一个分片中用户信息数量上限的情况下，为待存储的用户信息分配分片标识。利用已存储的用户信息的数量和一个分片中用户信息数量上限，可以获知已形成的分片的标识、尚在形成中的分片的标识，从而结合待存储的用户信息的数量，为待存储的用户信息确定对应的分片标识。分片标识可以理解为待存储的用户信息将作为哪个序号的分片的构成对象。

相较于缓存数据库，目标数据库可以视作提供分片读取服务的底层存储。上述预设数量阈值受限于目标数据库的类型，不同类型的目标数据库对于分片中用户信息的数量的上限规定不同。待处理的业务数据包来自于服务端接收到的一业务请求，在确定待处理的业务数据包中多条用户信息对应的目标数据库时，可以执行下述步骤：确定该业务请求对应的业务标识；基于预设配置信息确定对应该业务标识的目标数据库；其中，该预设配置信息记录了预设业务标识与候选数据库之间的映射关系。这里的业务标识可以是上述步骤S301-S304中提及的第一业务标识：appID。预设配置信息所记录的映射关系，综合考虑了上游业务方的相关业务情况(比如安全性要求、实时性要求)以及候选数据库的相关指标优势(比如成本、性能)。利用预设配置信息来确定目标数据库，可以提高目标数据库的确定效率，同时所确定的目标数据库也能满足上游业务方的相关业务要求。当然，预设配置信息可以根据需要进行更新。可以在确定目标数据库之后，将目标数据库信息与业务数据包进行关联。相应的，通过待处理的业务数据包可以获知其所指示的目标数据库信息，从而获取目标数据库对应的预设数量阈值以进行分片标识确定。目标数据库对应的预设数量阈值可以是根据其可承受且不需要其进行自动分片的数据量来设置的。

此外，不同类型的目标数据库所对应的指标优势(分数区间1-5,“5”说明优势最大，“1”说明优势最小)可参照下表1：

选型	成本	性能	多版本	可维护性	容灾	资源隔离
							Redis	1	5	3	5	5	5
COS	5	4	5	5	5	2
							BDB	2	3	4	5	5	5
Dcache	2	3	3	5	5	3
							权重	0.2	0.3	0.1	0.1	0.1	0.1

表1

在一示例性的实施方式中，如图4所示，所述根据所述多条用户信息的数量、已转存用户信息的数量和预设数量阈值确定所述多条用户信息对应的分片标识，包括：

S401：将所述多条用户信息的数量写入索引数据库中所述指定数数据包标识的关联对象中；其中，所述索引数据库用于记录数据包标识与其关联对象间的关系；

S402：在所述索引数据库中确定指示所述指定数据包标识的所述已转存用户信息的数量；

S403：利用所述索引数据库确定所述已转存用户信息的数量和所述多条用户信息的数量的相加结果；

S404：利用所述索引数据库确定所述相加结果和所述预设数量阈值的相除结果，以及将所述相除结果作为所述多条用户信息对应的分片标识进行存储。

如图11所示，对于“索引数据库用于记录数据包标识与其关联对象间的关系”，可以参考前述步骤S301-S304中的相关记载，不再赘述。多条用户信息的数量(也即待转存用户信息的数量)p(p为大于0的整数)，服务端可以将其写入索引redis中指定数据包标识的关联对象中。服务端可以在索引redis中确定指示指定数据包标识的已转存用户信息的数量q(q为大于等于0的整数)，已转存用户信息的数量作为指定数据包标识的关联对象存在。服务端利用索引redis确定已转存用户信息的数量和多条用户信息的数量的相加结果p+q。服务端利用索引redis确定相加结果和预设数量阈值的相除结果(p+q)/n＝m，可以将相除结果m作为多条用户信息对应的分片标识存储于指定数据包标识的关联对象中，其中n为大于0的整数，m为大于等于0的整数。需要说明的是，若相除运算存在余数，这里的相除结果指示商值。

示例性的，分片标识可以以序号的形式呈现，序号可以从0开始递增。若预设数量阈值(也即分片大小)n取1000、q＝1200、p＝200，那么m＝1400/1000、m取1。可以理解，为多个用户信息分配的分片标识1，当前已存在分片标识0。将相除结果作为多条用户信息对应的分片标识进行存储的意义可以是利用索引redis记录当前所开启的分片数量。进一步的，可以更新q＝1400。当然，对于待转存用户信息的数量p大于预设数量阈值n的情形，若p＝1500，那么待转存用户信息中的任意799条用户信息对应分片标识为m＝(1200+799)/1000、m取1，待转存用户信息中的其余701条用户信息对应分片标识为m＝(1200+799+701)/1000、m取2。

此外，序号从0开始递增限于同一版本的范畴。当待转存的用户信息指示包ID：yyyyyy、版本V3.0时，若当前V3.0下的分片标识已由0递增至了20，那么为该待转存的用户信息确定分片标识是基于该“20”的。当待转存的用户信息指示包ID：yyyyyy、版本V4.0，若当前V3.0下的分片标识已由0递增至了20，那么为该待转存的用户信息确定分片标识是由V4.0下的分片标识“0”重新开始的。对于用户信息的版本维护可参见图12。

引入索引数据库用于记录数据包标识维度下的相关信息，也为相关信息的查询提供了方便。由于不同业务数据包所包括的用户信息的数量不同，在利用分片的思想将指示同一数据包标识的用户信息进行整合时，利用索引数据库作为相关信息的提供方保证了确定分片标识的准确性。

在实际应用中，参见图6、8-9、11，如果将本申请提供的针对业务数据包的分片处理方案的执行主体视作一个号码包系统，该系统包括号码包写服务和索引redis。号码包写服务将获取的待处理的业务数据包的相关信息(比如上述多条用户信息的数量)写入索引redis。

S203：按照所述分片标识将所述多条用户信息写入缓存数据库中；

在本申请实施例中，服务端按照分片标识将多条用户信息写入缓存数据库中。缓存数据库作为一中转对象，其中存储有已形成的分片、尚在形成中的分片。比如，多条用户信息对应的分片标识为2，说明多条用户信息将用于2号分片的形成。多条用户信息可以独立完成2号分片的形成，也可以和其他用户信息共同完成2号分片的形成。其他用户信息可以是已经存储于缓存数据库的用户信息，也可以是后续将存储于缓存数据库的用户信息。

在实际应用中，参见图6、8、10-11，如果将本申请提供的针对业务数据包的分片处理方案的执行主体视作一个号码包系统，该系统包括号码包写服务和数据缓存redis。号码包写服务将获取的待处理的业务数据包的多条用户信息写入数据缓存redis。

S204：当所述分片标识对应的分片中用户信息的数量满足所述预设数量阈值的要求时，将所述分片标识对应的分片迁移至所述目标数据库中。

在本申请实施例中，当分片标识对应的分片中用户信息的数量满足预设数量阈值的要求时，服务端将分片标识对应的分片迁移至目标数据库中。在分片形成后，可以认为该分片满足了迁移条件，从而将其从作为中转对象的缓存数据库迁移至作为最终存储对象的目标数据库中。参见图10，本申请提供的针对业务数据包的分片处理方案实现了读写轻重分离，写的时候按分片组织，读的时候一次读一整个分片，一个分片在存储中可视作一个大字符串，从而保证了较高的读速度的实现。

考虑到对于分片是否形成的判断所存在的难度，可以通过下述至少一个条件的满足来判定分片标识对应的分片中用户信息的数量满足预设数量阈值的要求：

1)当开始在所述缓存数据库中写入指示相邻分片标识的用户信息时，判定所述分片标识对应的分片中用户信息的数量满足所述预设数量阈值的要求；其中，所述相邻分片标识的确定时机晚于所述分片标识的确定时机。

考虑到确定分片标识的递增逻辑，在为10的分片标识和为11的分片标识中，后者的确定时机晚于前者的确定时机。在缓存数据库中11号分片是作为10号分片的相邻分片的存在。如果当前写入的用户信息用于形成11号分片，可以说明10号分片已经形成，10号分片中用户信息的数量满足预设数量阈值的要求，可以对10号分片进行迁移了。

2)当当前时间与前次写入指示所述分片标识的用户信息的时间的差值大于预设时间阈值时，判定所述分片标识对应的分片中用户信息的数量满足所述预设数量阈值的要求；

上游业务方分批次的向服务端发送指示同一业务的多个业务请求，一般来说各批次间的时间差不会太大，尤其当该多个业务请求指示同一版本时。同时，服务端对于业务请求所携带的业务数据包的处理也是相对及时的。如果当前时间t1与前次在缓存数据库中写入指示某一分片标识的用户信息的时间t0的差值t1-t0大于预设时间阈值T(比如1分钟、2分钟)，可以说明该分片标识对应的分片已经形成，该分片标识对应的分片中用户信息的数量满足预设数量阈值的要求，可以对该分片进行迁移了。或者说明，已经将上游业务方分批次发送的指示同一业务的多个业务请求分别所携带的业务数据包转存完毕，或者已经将上游业务方分批次发送的指示同一业务且指示同一版本的多个业务请求分别所携带的业务数据包转存完毕，即便该分片标识对应的分片中用户信息的数量不满足预设数量阈值的要求，也可以对该分片进行迁移了。

3)当所述多条用户信息指向结束标志时，判定所述分片标识对应的分片中用户信息的数量满足所述预设数量阈值的要求；

对于上游业务方分批次发送的指示同一业务的多个业务请求分别所携带的业务数据包，其中用户信息之和可能不是预设数据阈值(也即分片大小)的整数倍，那么存在“已经将上游业务方分批次发送的指示同一业务的多个业务请求分别所携带的业务数据包转存完毕，或者已经将上游业务方分批次发送的指示同一业务且指示同一版本的多个业务请求分别所携带的业务数据包转存完毕，但该分片标识对应的分片中用户信息的数量不满足预设数量阈值的要求”的情形。当多条用户信息指向结束标志时，可以说明已实现了上述的转存完毕，即便该分片标识对应的分片中用户信息的数量不满足预设数量阈值的要求，也可以对该分片进行迁移了。

利用上述1)-3)可以及时有效的进行分片是否形成、迁移条件是否满足的判定，从而保证迁移的时效性。当缓存数据库使用存型存储系统时，考虑到内存型存储系统的高成本，及时的迁移可以提高在兼顾成本和存储数据量下缓存数据库的可用性。

在实际应用中，上游业务方分批次的向服务端发送指示同一业务的多个业务请求，对于其中指示同一版本的多个业务请求，上游业务方可以在向服务端发送这些业务请求之后，向服务端发送结束指令。如果将本申请提供的针对业务数据包的分片处理方案的执行主体视作一个号码包系统，该系统包括索引redis、号码包推送服务、号码包写服务、Kafka、检查服务、数据缓存redis。结束指令旨在通知号码包系统业务方推送数据完毕。参见图6、8、10-11，结束指令携带有带上appID(对应上述第一业务标识)、thirdID(对应上述第二业务标识)、数据版本、用户信息总数等，请求号码包推送服务的结束接口。比如，上游业务方分批次的向服务端发送指示同一业务且指示同一版本的多个业务请求为业务请求31-66，这里的用户信息总数指示业务请求31-66分别所携带的用户信息之和。号码包推送服务可以将该用户信息总数写入索引redis中相关包ID的关联对象中，以便于与已转存用户信息的数量进行核对。号码包推送服务可以将该结束指令发送至Kafka，具体可以生成结束指令对应的结束标志，并建立结束标志与相关待处理的业务数据包的关联关系。相应的，号码包写服务消费数据时，读取到该结束指令，将该结束指令写入索引redis中相关包ID的关联对象中，记录于索引redis的结束指令可以引导检查服务针对数据缓存redis中的用户信息进行分片是否形成、迁移条件是否满足的判定，从而及时进行分片迁移。检查服务所进行的分片迁移过程包括从数据缓存redis中读取满足迁移条件的分片，然后调用存储SDK的写接口将分片写到最终存储中。

最终存储对象的目标数据库可以不局限于使用内存型存储系统，可以支持多种存储类型，可以采用更节省成本的其他类型存储系统。这样可以更好的兼顾成本和存储多版本数据的需求。本申请实施例提供的针对业务数据包的分片处理方案，为了实现对大数据量进行高速读取，对存储过程与存储结构进行优化。把业务方推送过来的携带数据大小不固定的业务请求，转换成数据大小固定的分片，这样一次读取一整个分片以提高读性能。其中分片大小均匀，这样可以保证在读的时候，对于按分片个数调度的场景，调度速度稳定。分片大小可控，根据不同底层存储特性采取不同的分片大小，提高读数据的吞吐量。为适应读服务性能的变化，可以根据需要增加或者减少进行分片读取的机器设备。同时方案中引入内存型存储系统redis作为中间缓存(缓存数据库)，数据最终可以写入磁盘型存储系统，可以在保证高速读取的前提下最大限度的降低成本。该方案实现了一个所有数据实时分片过程，适用于保证高速读取大量数据，且实现成本相对较低的场景。该实现了对于大数据量高速读取的效果，目前测试(以上游业务方推送新闻的场景时实时读取用户信息为例)发现，可以1分钟读完5亿条用户信息，峰值速度可达912w条用户信息/每秒。

由以上本申请实施例提供的技术方案可见，本申请实施例中通过获取待处理的业务数据包，然后根据其中多条用户信息的数量、已转存用户信息的数量和预设数量阈值确定多条用户信息对应的分片标识，再按照分片标识将多条用户信息写入缓存数据库中，以及当分片标识对应的分片中用户信息的数量满足预设数量阈值的要求时，将分片标识对应的分片迁移至目标数据库中。其中，待处理的业务数据包是分批次发送的多个业务请求中任一业务请求所携带的内容，多个业务请求指示同一数据包标识，已转存用户信息对应的数据包标识和多条用户信息对应的数据包标识相同。本申请应用于业务方分批次的发送业务请求的场景，其中每个业务请求携带一业务数据包，一个业务数据包包括多条用户信息。基于分片思想对业务数据包中的用户信息进行两级存储。面对不同业务请求所指示的用户信息的数量不同的情形，利用指示分片大小的预设数量阈值对接收到的用户信息进行固定大小的分片整合，并将满足要求的分片从缓存迁移至目标数据库以便于分片读取服务的实现，这样可以提高读取性能。在此基础上，作为最终存储的目标数据库可以不局限于使用内存型存储系统，可以支持多种存储类型，可以采用更节省成本的其他类型存储系统。

本申请实施例还提供了一种针对业务数据包的分片处理装置，如图13所示，该针对业务数据包的分片处理装置1300包括：

获取模块1301：用于获取待处理的业务数据包；其中，所述待处理的业务数据包包括指示指定数据包标识的多条用户信息，所述待处理的业务数据包是分批次发送的多个业务请求中任一所述业务请求所携带的内容，所述多个业务请求均指示所述指定数据包标识；

确定模块1302：用于根据所述多条用户信息的数量、已转存用户信息的数量和预设数量阈值确定所述多条用户信息对应的分片标识；其中，所述已转存用户信息对应的数据包标识为所述指定数据包标识，所述预设数量阈值指示提供分片读取服务的目标数据库对于分片中用户信息的数量的上限；

缓存模块1303：用于按照所述分片标识将所述多条用户信息写入缓存数据库中；

迁移模块1304：用于当所述分片标识对应的分片中用户信息的数量满足所述预设数量阈值的要求时，将所述分片标识对应的分片迁移至所述目标数据库中。

需要说明的，所述装置实施例中的装置与方法实施例基于同样的发明构思。

本申请实施例提供了一种电子设备，该电子设备包括处理器和存储器，该存储器中存储有至少一条指令或至少一段程序，该至少一条指令或该至少一段程序由该处理器加载并执行以实现如上述方法实施例所提供的针对业务数据包的分片处理方法。

进一步地，图14示出了一种用于实现本申请实施例所提供的针对业务数据包的分片处理方法的电子设备的硬件结构示意图，所述电子设备可以参与构成或包含本申请实施例所提供的针对业务数据包的分片处理装置。如图14所示，电子设备140可以包括一个或多个(图中采用1402a、1402b，……，1402n来示出)处理器1402(处理器1402可以包括但不限于微处理器MCU或可编程逻辑器件FPGA等的处理装置)、用于存储数据的存储器1404、以及用于通信功能的传输装置1406。除此以外，还可以包括：显示器、输入/输出接口(I/O接口)、通用串行总线(USB)端口(可以作为I/O接口的端口中的一个端口被包括)、网络接口、电源和/或相机。本领域普通技术人员可以理解，图14所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，电子设备140还可包括比图14中所示更多或者更少的组件，或者具有与图14所示不同的配置。

应当注意到的是上述一个或多个处理器1402和/或其他数据处理电路在本文中通常可以被称为“数据处理电路”。该数据处理电路可以全部或部分的体现为软件、硬件、固件或其他任意组合。此外，数据处理电路可为单个独立的处理模块，或全部或部分的结合到电子设备140(或移动设备)中的其他元件中的任意一个内。如本申请实施例中所涉及到的，该数据处理电路作为一种处理器控制(例如与接口连接的可变电阻终端路径的选择)。

存储器1404可用于存储应用软件的软件程序以及模块，如本申请实施例中所述的针对业务数据包的分片处理方法对应的程序指令/数据存储装置，处理器1402通过运行存储在存储器144内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的一种针对业务数据包的分片处理方法。存储器1404可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器1404可进一步包括相对于处理器1402远程设置的存储器，这些远程存储器可以通过网络连接至电子设备140。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输装置1406用于经由一个网络接收或者发送数据。上述的网络具体实例可包括电子设备140的通信供应商提供的无线网络。在一个实例中，传输装置1406包括一个网络适配器(NetworkInterfaceController，NIC)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实施例中，传输装置1406可以为射频(RadioFrequency，RF)模块，其用于通过无线方式与互联网进行通讯。

显示器可以例如触摸屏式的液晶显示器(LCD)，该液晶显示器可使得用户能够与电子设备140(或移动设备)的用户界面进行交互。

本申请的实施例还提供了一种计算机可读存储介质，所述存储介质可设置于电子设备之中以保存用于实现方法实施例中一种针对业务数据包的分片处理方法相关的至少一条指令或至少一段程序，该至少一条指令或该至少一段程序由该处理器加载并执行以实现上述方法实施例提供的针对业务数据包的分片处理方法。

可选地，在本实施例中，上述存储介质可以位于计算机网络的多个网络服务器中的至少一个网络服务器。可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

需要说明的是：上述本申请实施例先后顺序仅仅为了描述，不代表实施例的优劣。且上述对本申请特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

本申请中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置和电子设备实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。

以上所述仅为本申请的较佳实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种针对业务数据包的分片处理方法，其特征在于，所述方法包括：

获取待处理的业务数据包；其中，所述待处理的业务数据包包括指示指定数据包标识的多条用户信息，所述待处理的业务数据包是分批次发送的多个业务请求中任一所述业务请求所携带的内容，所述多个业务请求均指示所述指定数据包标识；

根据所述多条用户信息的数量、已转存用户信息的数量和预设数量阈值确定所述多条用户信息对应的分片标识；其中，所述已转存用户信息对应的数据包标识为所述指定数据包标识，所述预设数量阈值指示提供分片读取服务的目标数据库对于分片中用户信息的数量的上限；

按照所述分片标识将所述多条用户信息写入缓存数据库中；

当所述分片标识对应的分片中用户信息的数量满足所述预设数量阈值的要求时，将所述分片标识对应的分片迁移至所述目标数据库中。

2.根据权利要求1所述的方法，其特征在于，所述根据所述多条用户信息的数量、已转存用户信息的数量和预设数量阈值确定所述多条用户信息对应的分片标识，包括：

将所述多条用户信息的数量写入索引数据库中所述指定数数据包标识的关联对象中；其中，所述索引数据库用于记录数据包标识与其关联对象间的关系；

在所述索引数据库中确定指示所述指定数据包标识的所述已转存用户信息的数量；

利用所述索引数据库确定所述已转存用户信息的数量和所述多条用户信息的数量的相加结果；

利用所述索引数据库确定所述相加结果和所述预设数量阈值的相除结果，以及将所述相除结果作为所述多条用户信息对应的分片标识进行存储。

3.根据权利要求1或2任一项所述的方法，其特征在于，在获取待处理的业务数据包之前，所述方法还包括：

响应于接收到的所述业务请求，确定所述业务请求对应的第一业务标识、第二业务标识和数据版本信息；

根据所述第一业务标识和所述第二业务标识，在索引数据库查找是否存在相匹配的数据包标识；其中，所述索引数据库用于记录数据包标识与其关联对象间的关系；

当存在时，将所述相匹配的数据包标识作为所述指定数据包标识，以及将所述数据版本信息写入第一目标关联对象中；其中，所述第一目标关联对象为所述索引数据库中所述相匹配的数据包标识的关联对象；

当不存在时，基于所述第一业务标识和所述第二业务标识创建对应的数据包标识以作为所述指定数据包标识，以及将第一业务标识、第二业务标识和所述数据版本信息写入第二目标关联对象中；其中，所述第二目标关联对象为所述索引数据库中所述对应的数据包标识的关联对象。

4.根据权利要求1或2任一项所述的方法，其特征在于，所述方法还包括：

响应于接收到的所述业务请求，确定所述业务请求对应的业务标识；

基于预设配置信息确定对应所述业务标识的所述目标数据库；其中，所述预设配置信息记录了预设业务标识与候选数据库之间的映射关系。

5.根据权利要求1或2任一项所述的方法，其特征在于，在所述获取待处理的业务数据包之后，所述方法还包括：

拼接所述用户信息所携带的用户标识、所对应的所述指定数据包标识和所指示的数据版本信息，得到所述用户信息对应的特征对象；

基于所述用户信息对应的特征对象，在所述缓存数据库和所述目标数据库中查找是否存在特征对象相匹配的用户信息；

当存在时，从所述多条用户信息中移除所述用户信息。

6.根据权利要求1或2任一项所述的方法，其特征在于，所述方法还包括：

当开始在所述缓存数据库中写入指示相邻分片标识的用户信息时，判定所述分片标识对应的分片中用户信息的数量满足所述预设数量阈值的要求；或者，

当当前时间与前次写入指示所述分片标识的用户信息的时间的差值大于预设时间阈值时，判定所述分片标识对应的分片中用户信息的数量满足所述预设数量阈值的要求；或者，

当所述多条用户信息指向结束标志时，判定所述分片标识对应的分片中用户信息的数量满足所述预设数量阈值的要求；

其中，所述相邻分片标识的确定时机晚于所述分片标识的确定时机。

7.根据权利要求1或2任一项所述的方法，其特征在于，所述获取待处理的业务数据包，包括：

从消息队列中取出所述待处理的业务数据包；其中，所述消息队列用于存储接收到的业务请求所携带的业务数据包，所述接收到的业务请求中各业务请求所指示的数据包标识有至少两个。

8.一种针对业务数据包的分片处理装置，其特征在于，所述装置包括：

获取模块：用于获取待处理的业务数据包；其中，所述待处理的业务数据包包括指示指定数据包标识的多条用户信息，所述待处理的业务数据包是分批次发送的多个业务请求中任一所述业务请求所携带的内容，所述多个业务请求均指示所述指定数据包标识；

确定模块：用于根据所述多条用户信息的数量、已转存用户信息的数量和预设数量阈值确定所述多条用户信息对应的分片标识；其中，所述已转存用户信息对应的数据包标识为所述指定数据包标识，所述预设数量阈值指示提供分片读取服务的目标数据库对于分片中用户信息的数量的上限；

缓存模块：用于按照所述分片标识将所述多条用户信息写入缓存数据库中；

迁移模块：用于当所述分片标识对应的分片中用户信息的数量满足所述预设数量阈值的要求时，将所述分片标识对应的分片迁移至所述目标数据库中。

9.一种电子设备，所述电子设备包括处理器和存储器，所述存储器中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由所述处理器加载并执行以实现如权利要求1-7任一所述的针对业务数据包的分片处理方法。

10.一种计算机可读存储介质，所述存储介质中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由处理器加载并执行以实现如权利要求1-7任一所述的针对业务数据包的分片处理方法。

Images