业务数据处理方法、装置、设备及存储介质与流程

1.本公开涉及计算机技术领域，尤其涉及一种业务数据处理方法、装置、设备及存储介质。


背景技术：

2.为了保持客户端的数据一致性，需要从后台获取业务数据进行数据更新。相关技术中，往往通过拉取后台的全量业务数据进行数据更新。而在一些面向企业(tob)场景下，全量业务数据的数据量往往比较大，如此对后台的压力非常大，也降低了系统的吞吐量。


技术实现要素：

3.本公开提供了一种业务数据处理、装置、设备及存储介质，以解决现有技术中至少一种技术问题。
4.根据本技术的第一方面，本公开提供了一种业务数据处理方法，包括：
5.在满足业务数据拉取条件的情况下，获取存储在接收端中本地业务数据对应的第一版本信息；
6.从业务数据库中，获取至少一个候选业务数据；所述业务数据库中各业务数据的存储数据结构包括业务数据的标识信息、用于表征业务数据的创建版本号的创建版本信息、用于表征业务数据的当前版本号的第二版本信息、以及用于表征业务数据的存储状态的数据状态信息；所述候选业务数据的第二版本信息对应的版本号大于所述第一版本信息对应的版本号；
7.基于所述候选业务数据对应的标识信息，从所述业务数据库中查询各候选业务数据的创建版本信息和对应的数据状态信息；
8.根据所述第一版本信息、每个候选业务数据的创建版本信息和对应数据状态信息，对所述候选业务数据进行过滤处理，获得目标业务数据；
9.将所述目标业务数据发送至所述接收端，以使所述接收端基于所述目标业务数据进行业务数据更新。
10.根据本技术的第二方面，提供了一种业务数据处理装置，所述装置包括：
11.第一获取模块，用于在满足业务数据拉取条件的情况下，获取存储在接收端中本地业务数据对应的第一版本信息；
12.第二获取模块，用于从业务数据库中，获取至少一个候选业务数据；所述业务数据库中各业务数据的存储数据结构包括业务数据的标识信息、用于表征业务数据的创建版本号的创建版本信息、用于表征业务数据的当前版本号的第二版本信息、以及用于表征业务数据的存储状态的数据状态信息；所述候选业务数据的第二版本信息对应的版本号大于所述第一版本信息对应的版本号；
13.查询模块，用于基于所述候选业务数据对应的标识信息，从所述业务数据库中查询各候选业务数据的创建版本信息和对应的数据状态信息；
14.过滤处理模块，用于根据所述第一版本信息、每个候选业务数据的创建版本信息和对应数据状态信息，对所述候选业务数据进行过滤处理，获得目标业务数据；
15.发送模块，用于将所述目标业务数据发送至所述接收端，以使所述接收端基于所述目标业务数据进行业务数据更新。
16.根据本技术的第三方面，提供了一种电子设备，所述电子设备包括处理器和存储器，所述存储器中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由所述处理器加载并执行以实现上述任一所述的方法。
17.根据本技术的第四方面，提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令或至少一段程序，所述至少一条指令或所述至少一段程序由处理器加载并执行以实现上述任一所述的方法。
18.根据本技术的第五方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述任一所述的方法。
19.本公开提供的一种业务数据处理方法、装置、设备及存储介质，具有如下技术效果：
20.本公开实施例通过在满足业务数据拉取条件的情况下，获取存储在接收端中本地业务数据对应的第一版本信息；获取至少一个候选业务数据，并基于候选业务数据对应的标识信息，从业务数据库中查询各候选业务数据的创建版本信息和对应的数据状态信息；根据所述第一版本信息、每个候选业务数据的创建版本信息和对应数据状态信息，对所述候选业务数据进行过滤处理，获得目标业务数据；将所述目标业务数据发送至所述接收端，以使所述接收端基于所述目标业务数据进行业务数据更新。从而由于候选业务数据中用于表征当前版本的第二版本信息对应的版本号大于第一版本信息对应的版本号，基于第一版本信息、每个候选业务数据用于表征创建版本号的创建版本信息和用于表征业务数据的存储状态的数据状态信息，对候选业务数据进行过滤处理来得到目标业务数据，从而目标业务数据是经过过滤处理的有效数据，使得接收端基于该目标业务数据进行数据更新时，减少了更新的数据量，节省用户流量，提升设备吞吐能力。
附图说明
21.为了更清楚地说明本公开实施例或现有技术中的技术方案和优点，下面将对实施例或现有技术描述中所需要使用的附图作简单的介绍，显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它附图。
22.图1是本公开实施例提供的一种业务数据处理方法的硬件环境的示意图；
23.图2是本公开实施例提供的一种业务数据处理方法的流程示意图；
24.图3是本公开实施例提供的一种业务数据处理方法的流程示意图；
25.图4是本公开实施例提供的一种业务数据处理方法的部分流程示意图；
26.图5是本公开实施例提供的一种业务数据处理方法的部分流程示意图；
27.图6是本公开实施例提供的一种业务数据处理装置的框架示意图；
28.图7是本公开提供的一种用于实现本公开实施例所提供的方法的设备的硬件结构示意图。
具体实施方式
29.为了使本技术领域的人员更好地理解本公开方案，下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分的实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本公开保护的范围。
30.为使本公开的目的、技术方案和优点更加清楚，下面将结合附图对本公开实施方式作进一步地详细描述。
31.云计算(cloud computing)指it基础设施的交付和使用模式，指通过网络以按需、易扩展的方式获得所需资源；广义云计算指服务的交付和使用模式，指通过网络以按需、易扩展的方式获得所需服务。这种服务可以是it和软件、互联网相关，也可是其他服务。云计算是网格计算(grid computing)、分布式计算(distributed computing)、并行计算(parallel computing)、效用计算(utility computing)、网络存储(network storage technologies)、虚拟化(virtualization)、负载均衡(load balance)等传统计算机和网络技术发展融合的产物。
32.随着互联网、实时数据流、连接设备多样化的发展，以及搜索服务、社会网络、移动商务和开放协作等需求的推动，云计算迅速发展起来。不同于以往的并行分布式计算，云计算的产生从理念上将推动整个互联网模式、企业管理模式发生革命性的变革。
33.云存储(cloud storage)是在云计算概念上延伸和发展出来的一个新的概念，分布式云存储系统(以下简称存储系统)是指通过集群应用、网格技术以及分布存储文件系统等功能，将网络中大量各种不同类型的存储设备(存储设备也称之为存储节点)通过应用软件或应用接口集合起来协同工作，共同对外提供数据存储和业务访问功能的一个存储系统。
34.目前，存储系统的存储方法为：创建逻辑卷，在创建逻辑卷时，就为每个逻辑卷分配物理存储空间，该物理存储空间可能是某个存储设备或者某几个存储设备的磁盘组成。客户端在某一逻辑卷上存储数据，也就是将数据存储在文件系统上，文件系统将数据分成许多部分，每一部分是一个对象，对象不仅包含数据而且还包含数据标识(id，id entity)等额外的信息，文件系统将每个对象分别写入该逻辑卷的物理存储空间，且文件系统会记录每个对象的存储位置信息，从而当客户端请求访问数据时，文件系统能够根据每个对象的存储位置信息让客户端对数据进行访问。
35.存储系统为逻辑卷分配物理存储空间的过程，具体为：按照对存储于逻辑卷的对象的容量估量(该估量往往相对于实际要存储的对象的容量有很大余量)和独立冗余磁盘阵列(raid，redundant array of independent disk)的组别，预先将物理存储空间划分成分条，一个逻辑卷可以理解为一个分条，从而为逻辑卷分配了物理存储空间。
36.本公开实施例可应用于云技术、人工智能、智慧交通、辅助驾驶等各种场景。
37.以下介绍本公开一种业务数据处理方法的具体实施例，请参阅图1，图1是本公开
实施例提供的一种业务数据处理方法的硬件环境的示意图，如图1所示，该硬件环境可以至少包括终端10、终端20和服务器30。
38.终端10和终端20可以为搭载具有即时通信功能的应用程序的设备，终端10和终端20可以通过该应用程序进行业务通信，服务器30可以用于为终端10提供后台的业务数据服务。
39.仅作为示例，在一些面向企业(tob)场景下，终端10可以是服务人员所对应的设备，终端20可以是服务人员的服务对象所对应的设备，该服务对象可以包括但不限于为企业客户。在终端10与终端20之间进行业务通信过程中，终端10对应的服务人员，可以在应用程序中通过不同的标签给对应的服务对象进行标记处理，以区分不同服务对象。
40.上述终端10可以是智能手机、电脑、智能语音交互设备、智能家电、车载终端、智能可穿戴设备、数字助理、增强现实设备、虚拟现实设备等实体设备或者运行于实体设备中的应用程序，但并不局限于此。
41.上述服务器20可以包括独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、cdn、以及大数据和人工智能平台等基础云计算服务的云服务器。终端以及服务器可以通过有线或无线通信方式进行直接或间接地连接，该终端及服务器可为区块链上的节点。本公开在此不做限制。
42.需要说明的是，在实际应用中，上述业务数据处理方法也可以在终端中实现，或者由终端和服务器共同实现。
43.当然，本公开实施例提供的方法并不限用于图1所示的硬件环境中，还可以用于其它可能的硬件环境，本公开实施例并不进行限制。对于图1所示的硬件环境的各个设备所能实现的功能将在后续的方法实施例中一并进行描述，在此先不过多赘述。
44.图2是本公开实施例提供的一种业务数据处理方法的流程示意图。本公开提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。该业务数据处理方法的执行主体可以是本公开实施例提供的业务数据处理装置，或者集成了该数据处理装置的服务器，其中，该业务数据处理装置可以采用硬件或者软件的方式实现。以执行主体为上述图1中的服务器为例进行说明，如图2所示，该方法可以包括：
45.s101：在满足业务数据拉取条件的情况下，获取存储在接收端中本地业务数据对应的第一版本信息。
46.其中，第一版本信息是指接收端中的本地业务数据的最新版本信息。第一版本信息可以通过版本号(例如v0、v1等)、序列号(例如1、2等)等进行表示，本公开对此不作具体限定。
47.本地业务数据可以存储在接收端对应的本地数据库中。该本地业务数据包括但不限于为标签数据、标签相关数据等至少一种。示例性的，在一些面向企业(tob)场景下，该标签数据可以包括但不限于为客户等级、产品品牌、产品预算、产品用途等中至少一种。标签相关数据可以包括标签对应产品的媒体数据，例如标签相关的推荐文章、推荐广告、推荐视频、产品活动等。
48.其中，用户等级是潜在客户的优质级别，其可以划分为一般、重要和核心等等级子标签。或者，可以划分为包括一级、二级和三级等等级子标签。
49.产品品牌可以是潜在客户关注或感兴趣的产品对应的具体品牌名称，该产品品牌与产品类型相关，例如，可以分为汽车品牌、智能家电品牌、医疗设备品牌、工业设备品牌等中至少一种。以汽车品牌为例，可以设置丰x、宝x、本x等不同品牌子标签。
50.产品预算是潜在用户计划对产品的资金投入范围，不同的资金投入范围可以通过不同的标签来表示。产品用途是潜在用户计划使用产品的用途，例如家用、商务等用途子标签。
51.需要说明的是，上述标签数据并不限于此。例如，标签数据还可以包括标签分组信息，该标签分组信息用于反映标签所在的组信息，例如标签组1、标签组2、标签组3......，不同的标签组可以具有不同的标签属性。示例的，标签组1是产品a对应的组、标签组2是产品b对应的组、标签组3是产品c和d对应的组等。
52.示例性的，例如，服务器可以监听本地存储的业务数据是否发生数据变更，该数据变更包括但不限于新增、修改、删除等操作。若监听到本地存储的业务数据发生变更，则可以确定满足业务数据拉取条件。服务器可以向接收端发送数据变更通知，接收端响应于该数据变更通知，将本地业务数据对应的第一版本信息反馈至服务器，以使得服务器根据该第一版本信息进行接收端中本地业务数据执行被动数据更新。
53.又例如，接收端可以通过用于拉取业务数据对应的获取页面，向服务器主动发送业务数据获取请求。服务器在接收到该业务数据获取请求时，即可确定满足业务数据拉取条件。该业务数据获取请求中可以包括本地业务数据对应的第一版本信息，服务器基于该业务数据获取请求中的第一版本信息，对接收端中本地业务数据执行主动数据更新。
54.s103：从业务数据库中，获取至少一个候选业务数据。
55.其中，所述业务数据库中各业务数据的存储数据结构包括业务数据的标识信息、用于表征业务数据的创建版本号的创建版本信息、用于表征业务数据的当前版本号的第二版本信息、以及用于表征业务数据的存储状态的数据状态信息。
56.在服务器对应的业务数据库中，存储的业务数据的数据结构可以包括：数据id(数据标识)、name(数据名称)、status(状态)、seq_s(当前版本信息)和createseq(创建时的版本信息)等字段。示例性的，服务器存储的业务数据可以表示为{id,name,status,seq_s,createseq}。
57.其中，在服务器侧，业务数据的标识信息是用于表征业务数据存储的唯一标识，其可以由字符串组成，本公开对此不作具体限定。
58.当前版本信息(也即第二版本信息)是指服务端对应的业务数据库中存储的业务数据的最新版本信息。第二版本信息与接收端侧的第一版本信息具有相同的数据格式，可以通过版本号(例如v0、v1等)、序列号(例如1、2等)等进行表示，本公开对此不作具体限定。
59.创建版本信息为业务数据在服务器对应的业务数据库中创建时的版本信息。该创建版本信息与第一版本信息具有相同的数据格式，例如可以通过版本号(例如v0、v1等)、序列号(例如1、2等)等进行表示。创建版本信息与第二版本信息可以相同，也可以不同。示例性的，对于数据k，在t0时刻，其创建版本信息为“版本n”，对应的第二版本信息也为“版本n”，其中，n为整数数。若在t1时刻，对数据k进行了例如增、删、改等至少一种数据操作，此
时，其创建版本信息为“版本n”，对应的第二版本信息也为“版本m”，m为大于n的正整数。
60.数据状态信息用于反映候选业务数据在服务器的状态，该数据状态信息(记为status)可以包括删除状态和正常状态。示例性的，在业务数据存储时，若某条数据进行了删除操作，则可以采用“1”表示删除状态，也即表明该条数据在业务数据库中已经被删除。若对某条数据未进行任何操作或进行了除删除操作之外的其他操作，则采用“0”表示正常状态，也即表明该条数据仍然保留在对应的业务数据库中。
61.以业务数据为企业标签a为例，在创建该企业标签a时，按照上述数据结构，其在服务器存储为：{a,标签a,0,1,1}。若在t2时刻，将该企业标签a删除，此时该企业标签a的当前版本(seq_s)从“版本1”变为“版本4”，数据状态信息(status)由“0”变为“1”，则其在服务器的存储调整为{a,标签a,1,4,1}。
62.其中，候选业务数据是指满足预设拉取条件的业务数据。该预设拉取条件可以包括数据校验通过的业务数据、版本信息较高的业务数据等等。
63.示例性的，候选业务数据的第二版本信息对应的版本号大于接收端本地存储的第一版本信息对应的版本号。
64.在一些实施方式中，所述从业务数据库中，获取至少一个候选业务数据可以包括：从业务数据库中，查询存储的待拉取业务数据的第二版本信息；基于所述第一版本信息和所述第二版本信息，从待拉取业务数据中确定至少一个候选业务数据。
65.示例性的，若接收端中存储的本地业务数据对应的第一版本信息的版本号为seq_n，服务器中存储m条待拉取业务数据，其各自的第二版本信息的版本号按从小到大的顺序可以表示为{seq_0、seq_1、...seq_m}，m为大于n的整数。根据版本信息，从待拉取业务数据中将版本信息对应的版本号，大于第一版本信息seq_n对应的版本号中对应的业务数据筛选处理，也即将第二版本信息为{seq_n 1、...seq_m}对应的待拉取业务数据，作为候选业务数据。而对于待拉取业务数据中将版本信息对应的版本号，小于等于第一版本信息seq_n对应的版本号中对应的业务数据进行剔除处理，也即将第二版本信息为{seq_0、...seq_n}对应的待拉取业务数据进行剔除，无需进行后续的数据过滤和业务更新步骤。
66.上述实施例，通过比较待拉取业务数据的第二版本信息与接收端中本地业务数据对应的第一版本信息，基于比较结果，从待拉取业务数据中确定至少一个候选业务数据，如此可以实现仅对相对于接收端中的增量数据进行更新，避免对全量数据进行后续过滤和业务更新步骤，可大大减少更新数据量和流量消耗，提高了业务数据更新效率和系统吞吐量。
67.s105：基于候选业务数据对应的标识信息，从业务数据库中查询各候选业务数据的创建版本信息和对应的数据状态信息。
68.在实际应用中，服务器获取到至少一个候选业务数据之后，可以在相应的业务数据库中，基于该候选业务数据对应的标识信息，查询这些候选业务数据的的创建版本信息和对应的数据状态信息，例如查询结果可以表示为{(seq_1，0),(seq_2，1)...(seq_t，0)}，其中，seq_1～seq_t表示创建版本信息，“0”和“1”分别表示删除状态和正常状态。
69.s107：根据所述第一版本信息、每个候选业务数据的创建版本信息和对应数据状态信息，对所述候选业务数据进行过滤处理，获得目标业务数据。
70.在一可选实施方式中，如图3所示，所述根据所述第一版本信息、每个候选业务数据对应的创建版本信息和数据状态信息，对所述候选业务数据进行过滤处理，获得目标业
务数据包括：
71.s201：将数据状态信息为删除状态所对应的候选业务数据，作为第一业务数据。
72.可选地，可以遍历每条候选业务数据的数据状态信息，将数据状态信息为删除状态所对应的候选业务数据作为第一业务数据，将数据状态信息为正常状态所对应的候选业务数据作为第二业务数据。也就是说，基于数据状态信息可以将候选业务数据划分为第一业务数据和第二业务数据两部分，对于第一业务数据，需要进行后续的过滤处理步骤，而对于第二业务数据，可以无需进行后续的过滤处理步骤，即可发送至接收端，以使接收端基于第二业务数据进行业务数据更新。
73.s203：根据所述第一业务数据对应的创建版本信息和所述第一版本信息，确定待删除业务数据。
74.可选地，所述创建版本信息包括创建版本号(记为createseq)，所述第一版本信息包括第一版本号(记为seq_n)。
75.所述根据所述第一业务数据对应的创建版本信息和所述第一版本信息，确定待删除业务数据包括：比较所述第一业务数据对应的创建版本号和所述第一版本号的大小；将创建版本号大于第一版本号所对应的第一业务数据，作为待删除业务数据。
76.上述实施例通过基于版本号的大小来确定待删除业务数据，并将创建版本号大于第一版本号且表示删除状态的第一业务数据，作为待删除业务数据，减少业务数据的计算量，提高业务更新速率，提高用户使用体验感。
77.s205：剔除所述候选业务数据中的所述待删除业务数据，获得目标业务数据。
78.可选地，从候选业务数据中剔除掉所确定的待删除业务数据，将经剔除后的候选业务数据作为目标业务数据。
79.为了便于理解，结合下面的例子进行说明：
80.假如服务器依次创建标签1，标签2，标签3，然后删除标签1，再创建标签4，然后删除标签4，此时，服务器中有4条标签数据，其中2条已经被删除。服务器中存储的业务数据如表1所示：
[0081][0082][0083]
表1
[0084]
假如接收端中本地业务数据的最新版本是“0”，若采用传统增量更新协议会拉取到4条数据，分别是标签1(删除)，标签2(正常)，标签3(正常)，标签4(删除)。而采用本公开的业务数据处理方法只会拉取到2条数据，分别是标签2(正常)，标签3(正常)。
[0085]
假如接收端中本地业务数据的最新版本是“2”，若采用传统增量更新协议会拉取
到3条数据，分别是标签1(删除)，标签3(正常)，标签4(删除)。优而采用本公开的业务数据处理方法只会拉取到2条数据，分别是标签1(删除)，标签3(正常)。
[0086]
上述通过在第一业务数据对应的数据状态信息为删除状态的情况下，根据第一业务数据对应的创建版本信息和接收端中的最新版本信息，对候选业务数据进行过滤处理，使得获得的目标业务数据有效减少了无效数据，提高了更新数据的准确性，保证了业务系统的运行稳定和可靠性。
[0087]
s109：将目标业务数据发送至所述接收端，以使接收端基于所述目标业务数据进行业务数据更新。
[0088]
在实际应用中，服务器获取到目标业务数据之后，可以将该目标业务数据发送至接收端，以使得接收端基于所述目标业务数据进行业务数据更新。
[0089]
继续上面的例子，若接收端中本地业务数据的最新版本是0，从服务器拉取到的目标业务数据为标签2(正常)，标签3(正常)，由于标签2和标签3的树状态均为正常状态，接收端增加标签2，标签3，以实现业务数据更新。若接收端中本地业务数据的最新版本是0，从服务器拉取到的目标业务数据为标签1(删除)，标签3(正常)，由于标签1的数据状态为删除状态，标签3的数据态为正常状态，则接收端删除本地的标签1对应的数据，仅增加标签3的数据，以进行业务数据更新。
[0090]
本公开实施例由于候选业务数据中用于表征当前版本的第二版本信息对应的版本号大于第一版本信息对应的版本号，基于第一版本信息、每个候选业务数据用于表征创建版本号的创建版本信息和用于表征业务数据的存储状态的数据状态信息，对候选业务数据进行过滤处理来得到目标业务数据，从而目标业务数据是经过过滤处理的有效数据，使得接收端基于该目标业务数据进行数据更新时，减少了更新的数据量，节省用户流量，提升设备吞吐能力。
[0091]
在一些实施方式中，如图4所示，所述在满足业务数据拉取条件的情况下，获取存储在接收端中本地业务数据对应的第一版本信息可以包括：
[0092]
s301：监听到存储的业务数据发生数据变更时，确定满足业务数据拉取条件；
[0093]
s303：从候选接收端中确定预设数量的接收端；
[0094]
s305：获取所确定的接收端中存储的本地业务数据对应的第一版本信息。
[0095]
具体地，服务器监听本地存储的业务数据是否发生数据变更，该数据变更包括但不限于新增、修改、删除等操作。若监听到本地存储的业务数据发生变更，则确定满足业务数据拉取条件。服务器可以从多个候选接收端中，筛选出预设数量的接收端。该预设数量包括但不限于为企业活跃用户数量、最近使用标签数据的n(n为正整数)个接收端、后台负载计算通知量阈值、随机数量等。接着，服务器获取所确定的接收端中存储的本地业务数据对应的第一版本信息。
[0096]
示例性的，在实际应用中，在企业通信软件中，若监听到业务数据库的“车辆”标签对应的业务数据进行了数据变更，则从候选接收端中确定使用该“车辆”标签的n个目标接收端，则从所确定的n个目标接收端中获取存储的本地业务数据对应的第一版本信息，进而基于该第一版本信息以及业务数据库中业务数据的存储数据结构，确定至少一个与车辆标签相关的候选业务数据。并根据每个目标接收端对应的第一版本信息、每个候选业务数据的创建版本信息和对应数据状态信息，对候选业务数据进行过滤处理，获得每个目标接收
端对应的目标业务数据。之后，服务器根据每个目标接收端对应的目标业务数据，向对应的接收端进行业务数据分发，以使得各目标接收端按照各自获取的目标业务数据进行业务数据更新。例如，向目标接收终端1发送针对a品牌车的购车券1的业务数据，向目标接收终端2发送针对b品牌车的购车券2的业务数据，等等。目标接收终端1和目标接收终端2可以根据接收到的购车券发送至合适的潜在客户。
[0097]
上述通过监听到存储的业务数据发生数据变更时，确定满足业务数据拉取条件；从候选接收端中确定预设数量的接收端；获取所确定的接收端中存储的本地业务数据对应的第一版本信息；从而实现了服务器对预设数量的目标接收端的及时更新下发，提高数据的及时性，也避免了大量的目标接收端同步向服务器请求更新数据所给服务器带来的压力，同时也避免对全量接收端对应的用户带来的打扰，且能提高业务数据更新下发的有效性和数据更新效果。
[0098]
在另一些实施方式中，如图5所示，所述在满足业务数据拉取条件的情况下，获取存储在接收端中本地业务数据对应的第一版本信息可以包括：
[0099]
s401：响应于接收端发送的业务拉取请求，检测存储的业务数据中是否存在业务增量数据；所述业务拉取请求包括所述接收端中存储的本地业务数据对应的第一版本信息；
[0100]
s403：在确定存在业务增量数据的情况下，确定满足业务数据拉取条件；
[0101]
s405：从所述业务拉取请求中，解析出存储在所述接收端中本地业务数据对应的第一版本信息。
[0102]
具体地，用户可以通过接收端登录业务数据对应的获取页面，主动向服务器发送业务数据获取请求，该业务拉取请求包括所述接收端中存储的本地业务数据对应的第一版本信息。服务器响应于接收端发送的业务拉取请求，检测存储的业务数据中是否存在业务增量数据，该业务增量数据可以通过服务器存储的业务数据的版本信息和接收端中的本地业务数据的版本信息来识别，当检测到两者的版本信息不同，则确定服务器中存在业务增量数据。此时，在确定存在业务增量数据的情况下，确定满足业务数据拉取条件。服务器可以从所述业务拉取请求中，解析出存储在接收端中本地业务数据对应的第一版本信息。
[0103]
上述通响应于接收端发送的业务拉取请求，检测存储的业务数据中是否存在业务增量数据；所述业务拉取请求包括所述接收端中存储的本地业务数据对应的第一版本信息；在确定存在业务增量数据的情况下，确定满足业务数据拉取条件；从所述业务拉取请求中，解析出存储在所述接收端中本地业务数据对应的第一版本信息，从而实现了对增量数据的主动更新，并且结合上述的被动更新，可以通过接收端主动和被动双重多种更新时机，进一步保证接收端数据的实时性。
[0104]
在一可选实施方式中，继续如图5所示，所述业务拉取请求还包括所述接收端中本地业务数据的第一数据量；所述方法还包括：
[0105]
s407：在确定不存在业务增量数据的情况下，获取存储的全量业务数据对应的第二数据量；
[0106]
s409：在确定所述第一数据量与所述第二数据量不一致的情况下，将存储的全量业务数据作为目标业务数据。
[0107]
具体地，服务器在收到接收端发送的业务拉取请求，该业务拉取请求除了包括存
储的本地业务数据的第一版本信息之外，还包括接收端中本地业务数据的第一数据量(例如，企业标签数量)。服务器在检测到不存在业务增量数据的情况下，获取本地存储的全量业务数据对应的第二数据量。接着，比较第一计算量和第二计算量是否一致，若确定两者不一致，则判断接收端中存在脏数据。此时，将服务器中存储的全量业务数据作为目标业务数据，并将该目标业务数据发送给接收端，以使得接收端用全量业务数据覆盖本地业务数据，实现了对接收端的数据矫正，避免脏数据所带来的不良影响，进一步提高了增量数据的准确性。
[0108]
下述为本公开装置实施例，可以用于执行本公开方法实施例。对于本公开装置实施例中未披露的细节，请参照本公开方法实施例。
[0109]
请参考图6，其示出了本公开实施例提供的一种业务数据处理装置的结构框图。该装置具有实现上述方法示例中的功能，所述功能可以由硬件实现，也可以由硬件执行相应的软件实现。所述业务数据处理装置可以包括：
[0110]
第一获取模块510，用于在满足业务数据拉取条件的情况下，获取存储在接收端中本地业务数据对应的第一版本信息；
[0111]
第二获取模块520，用于用于从业务数据库中，获取至少一个候选业务数据；所述业务数据库中各业务数据的存储数据结构包括业务数据的标识信息、用于表征业务数据的创建版本号的创建版本信息、用于表征业务数据的当前版本号的第二版本信息、以及用于表征业务数据的存储状态的数据状态信息；所述候选业务数据的第二版本信息对应的版本号大于所述第一版本信息对应的版本号；
[0112]
查询模块530，用于基于所述候选业务数据对应的标识信息，从所述业务数据库中，并查询各候选业务数据的创建版本信息和对应的数据状态信息；
[0113]
过滤处理模块540，用于根据所述第一版本信息、每个候选业务数据的创建版本信息和对应数据状态信息，对所述候选业务数据进行过滤处理，获得目标业务数据；
[0114]
发送模块550，用于将所述目标业务数据发送至所述接收端，以使所述接收端基于所述目标业务数据进行业务数据更新。
[0115]
在一可选实施例，所述第二获取模块包括：
[0116]
查询子模块，用于从业务数据库中，查询存储的待拉取业务数据的第二版本信息；
[0117]
第一确定子模块，用于基于所述第一版本信息和所述第二版本信息，从待拉取业务数据中确定至少一个候选业务数据。
[0118]
在一可选实施例，所述过滤处理模块包括：
[0119]
第二确定子模块，用于将数据状态信息为删除状态所对应的候选业务数据，作为第一业务数据；
[0120]
第三确定子模块，用于在第一业务数据对应的数据状态信息为删除状态的情况下，根据所述第一业务数据对应的创建版本信息和所述第一版本信息，确定待删除业务数据；
[0121]
删除子模块，用于剔除所述候选业务数据中的所述待删除业务数据，获得目标业务数据。
[0122]
在一可选实施例，所述创建版本信息包括创建版本号，所述第一版本信息包括第一版本号；所述删除子模块包括：
[0123]
比较单元，用于比较所述第一业务数据对应的创建版本号和所述第一版本号的大小；
[0124]
确定单元，用于将创建版本号大于第一版本号所对应的第一业务数据，作为待删除业务数据。
[0125]
在一可选实施例，所述第一获取模块包括：
[0126]
监听子模块，用于监听到存储的业务数据发生数据变更时，确定满足业务数据拉取条件；
[0127]
第四确定子模块，用于从候选接收端中确定预设数量的接收端；
[0128]
第一获取子模块，用于获取所确定的接收端中存储的本地业务数据对应的第一版本信息。
[0129]
在一可选实施例，所述第一获取模块包括：
[0130]
检测子模块，用于响应于接收端发送的业务拉取请求，检测存储的业务数据中是否存在业务增量数据；所述业务拉取请求包括所述接收端中存储的本地业务数据对应的第一版本信息；
[0131]
第五确定子模块，用于在确定存在业务增量数据的情况下，确定满足业务数据拉取条件；
[0132]
解析子模块，用于从所述业务拉取请求中，解析出存储在所述接收端中本地业务数据对应的第一版本信息。
[0133]
在一可选实施例，所述业务拉取请求还包括所述接收端中本地业务数据的第一数据量；所述装置还包括：
[0134]
第三获取模块，用于在确定不存在业务增量数据的情况下，获取存储的全量业务数据对应的第二数据量；
[0135]
确定模块，用于在确定所述第一数据量与所述第二数据量不一致的情况下，将存储的全量业务数据作为目标业务数据。
[0136]
上述实施例中提供的装置可执行本公开实施例中的对应方法，具备执行该方法相应的功能模块和有益效果。未在上述实施例中详尽描述的技术细节，可参见本技术任意实施例所提供的方法。
[0137]
本公开实施例提供了一种计算机设备，该设备可以包括处理器和存储器，该存储器中存储有至少一条指令、至少一段程序、代码集或指令集，该至少一条指令、该至少一段程序、该代码集或指令集由该处理器加载并执行以实现如上述方法实施例任一所述的方法。
[0138]
本公开实施例还提供了一种计算机可读存储介质，所述存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、至少一段程序、代码集或指令集由处理器加载并执行上述方法实施例任一所述的方法。
[0139]
本公开实施例还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行本实施例上述任一方法。
[0140]
进一步地，图7示出了一种用于实现本公开实施例所提供的方法的设备的硬件结
构示意图，所述设备可以为计算机终端、移动终端或其它设备，所述设备还可以参与构成或包含本公开实施例所提供的装置。如图7所示，计算机终端7可以包括一个或多个(图中采用72a、72b，
……
，72n来示出)处理器72(处理器72可以包括但不限于微处理器mcu或可编程逻辑器件fpga等的处理装置)、用于存储数据的存储器74、以及用于通信功能的传输装置76。除此以外，还可以包括：显示器、输入/输出接口(i/o接口)、通用串行总线(usb)端口(可以作为i/o接口的端口中的一个端口被包括)、网络接口、电源和/或相机。本领域普通技术人员可以理解，图7所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，计算机终端7还可包括比图7中所示更多或者更少的组件，或者具有与图7所示不同的配置。
[0141]
应当注意到的是上述一个或多个处理器72和/或其他数据处理电路在本文中通常可以被称为“数据处理电路”。该数据处理电路可以全部或部分的体现为软件、硬件、固件或其他任意组合。此外，数据处理电路可为单个独立的处理模块，或全部或部分的结合到计算机终端7(或移动设备)中的其他元件中的任意一个内。如本公开实施例中所涉及到的，该数据处理电路作为一种处理器控制(例如与接口连接的可变电阻终端路径的选择)。
[0142]
存储器74可用于存储应用软件的软件程序以及模块，如本公开实施例中所述的方法对应的程序指令/数据存储装置，处理器72通过运行存储在存储器74内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的一种神经网络处理方法。存储器74可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器74可进一步包括相对于处理器72远程设置的存储器，这些远程存储器可以通过网络连接至计算机终端7。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
[0143]
传输装置76用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端7的通信供应商提供的无线网络。在一个实例中，传输装置76包括一个网络适配器(network interface controller，nic)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置76可以为射频(radio frequency，rf)模块，其用于通过无线方式与互联网进行通讯。
[0144]
显示器可以例如触摸屏式的液晶显示器(lcd)，该液晶显示器可使得用户能够与计算机终端7(或移动设备)的用户界面进行交互。
[0145]
需要说明的是：上述本公开实施例先后顺序仅仅为了描述，不代表实施例的优劣。且上述对本公开特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
[0146]
本公开中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置和服务器实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
[0147]
本领域普通技术人员可以理解实现上述实施例的全部或部分步骤可以通过硬件来完成，也可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读
存储介质中，上述提到的存储介质可以是只读存储器，磁盘或光盘等。
[0148]
以上所述仅为本公开的较佳实施例，并不用以限制本公开，凡在本公开的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本公开的保护范围之内。