CN108241718A - 一种数据并行处理的方法及服务器 - Google Patents

Abstract

本发明公开了一种数据并行处理的方法及服务器，其中，所述方法包括：从数据库中加载第一数据到内存中，所述第一数据为对应当前第一时刻的最新数据；当检测到所述数据库出现数据处理阻塞时，从所述内存中读取第二数据，所述第二数据为对应上一个第二时刻的旧数据；根据所述第二数据进行计费处理，得到待提交给所述数据库的待提交数据，将所述待提交数据放到缓冲区；根据从所述缓冲区不断读取得到的所述待提交数据进行数据库的异步持久化处理。

Description

一种数据并行处理的方法及服务器

技术领域

本发明涉及数据处理技术，尤其涉及一种数据并行处理的方法及服务器。

背景技术

数据处理中，最简单的处理逻辑通常是顺序执行的，比如，有a、b、c三个步骤，其处理逻辑为先执行步骤a，再执行步骤b，最后执行步骤c。然而，顺序执行的处理逻辑看似简单，但是在实际应用中存在各种问题，比如，读写场景中，写入和读取按照顺序串行处理，效率低下。又如，以计费业务处理操作为例，每次处理计费任务时，1)首先进行数据加载，比如会从数据库里加载信息推荐方(如广告主)的余额数据和与信息推荐相关的预算和消耗等信息到内存中，以用于后续的计费处理。2)通过计费处理得到实际的消耗。3)执行计费处理后，进行数据库持久化操作，更新数据库中的余额数据和消耗数据。

可见，上述操作是串行执行的，1)-3)中前一个步骤未执行完，后一个步骤无法进行，而随着业务的进一步发展，需要处理的数据越来越多，这将会导致数据加载和进行数据库持久化操作的时间越来越长。另外，有些需要处理的数据是前台和后台共用的，如果前台的数据库并发访问量大，就会导致数据库的读写操作被阻塞住，进而影响到整个计费业务处理的正常执行，不仅处理效率低下，而且还会影响计费处理的准确率。然而，相关技术中，对于该问题，尚无有效解决方案。

发明内容

有鉴于此，本发明实施例提供了一种数据并行处理的方法及服务器，至少解决了现有技术存在的问题。

本发明实施例的技术方案是这样实现的：

本发明实施例的一种数据并行处理的方法，所述方法包括：

从数据库中加载第一数据到内存中，所述第一数据为对应当前第一时刻的最新数据；

当检测到所述数据库出现数据处理阻塞时，从所述内存中读取第二数据，所述第二数据为对应上一个第二时刻的旧数据；

根据所述第二数据进行计费处理，得到待提交给所述数据库的待提交数据，将所述待提交数据放到缓冲区；

根据从所述缓冲区不断读取得到的所述待提交数据进行数据库的异步持久化处理。

上述方案中，所述方法还包括：

从所述数据库中加载至少两类数据到内存中；

所述至少两类数据包括：预算数据和消耗数据；

所述预算数据用于表征由终端用户写入的符合预期业务需求的数据类型；

所述消耗数据用于表征与所述预算数据相关消耗的数据类型。

上述方案中，所述方法还包括：

通过所述计费处理线程对所述消耗数据进行维护时，从所述内存中读取当前时刻之前的第一消耗数据、当前时刻的第二消耗数据、对应所述缓冲区内待提交数据块的第三消耗数据；

将所述第一消耗数据依次加上所述第三消耗数据和所述第二消耗数据进行校验。

上述方案中，所述方法还包括：

将所述待提交数据放到缓冲区后，通过所述计费处理线程对以异步方式获取到的所述预算数据进行计费，得到实际的消耗数据。

上述方案中，所述方法还包括：

当检测到所述将待提交数据放到缓冲区的操作为失败时，执行容错回退策略，返回所述计费处理线程，以再次提交所述待提交数据。

上述方案中，所述方法还包括：

将所述缓冲区的至少一个待提交数据按照等效合并策略进行数据合并。

上述方案中，所述待提交数据包括：消耗数据和计费明细数据。

本发明实施例的一种服务器，所述服务器包括：

加载单元，用于从数据库中加载第一数据到内存中，所述第一数据为对应当前第一时刻的最新数据；

读取单元，用于当检测到所述数据库出现数据处理阻塞时，从所述内存中读取第二数据，所述第二数据为对应上一个第二时刻的旧数据；

计费单元，用于根据所述第二数据进行计费处理，得到待提交给所述数据库的待提交数据，将所述待提交数据放到缓冲区；

回写处理单元，用于根据从所述缓冲区不断读取得到的所述待提交数据进行数据库的异步持久化处理。

上述方案中，所述加载单元，进一步用于：

从所述数据库中加载至少两类数据到内存中；

所述至少两类数据包括：预算数据和消耗数据；

所述预算数据用于表征由终端用户写入的符合预期业务需求的数据类型；

所述消耗数据用于表征与所述预算数据相关消耗的数据类型。

上述方案中，所述计费单元，进一步用于：

通过所述计费处理线程对所述消耗数据进行维护时，从所述内存中读取当前时刻之前的第一消耗数据、当前时刻的第二消耗数据、对应所述缓冲区内待提交数据块的第三消耗数据；

将所述第一消耗数据依次加上所述第三消耗数据和所述第二消耗数据进行校验。

上述方案中，所述计费单元，进一步用于：

将所述待提交数据放到缓冲区后，通过所述计费处理线程对以异步方式获取到的所述预算数据进行计费，得到实际的消耗数据。

上述方案中，所述服务器还包括：回退单元，用于：

当检测到所述将待提交数据放到缓冲区的操作为失败时，执行容错回退策略，返回所述计费处理线程，以再次提交所述待提交数据。

上述方案中，所述服务器还包括：合并单元，用于：

将所述缓冲区的至少一个待提交数据按照等效合并策略进行数据合并。

上述方案中，所述待提交数据包括：消耗数据和计费明细数据。

本发明实施例的数据并行处理的方法包括：从数据库中加载第一数据到内存中，所述第一数据为对应当前第一时刻的最新数据；当检测到所述数据库出现数据处理阻塞时，从所述内存中读取第二数据，所述第二数据为对应上一个第二时刻的旧数据；根据所述第二数据进行计费处理，得到待提交给所述数据库的待提交数据，将所述待提交数据放到缓冲区；根据从所述缓冲区不断读取得到的所述待提交数据进行数据库的异步持久化处理。

采用本发明实施例，加载过程中，是从数据库中加载第一数据到内存中，所述第一数据为对应当前第一时刻的最新数据，而当计费过程中，是当检测到所述数据库出现数据处理阻塞时，从所述内存中读取第二数据，所述第二数据为对应上一个第二时刻的旧数据，即不是等加载完成才执行计费处理，而是一种异步处理机制。根据所述第二数据进行计费处理，得到待提交给所述数据库的待提交数据后，将所述待提交数据放到缓冲区，根据从所述缓冲区不断读取得到的所述待提交数据进行数据库的异步持久化处理，即计费过程和回写数据库的过程也是一种异步机制。通过这种异步处理机制实现的多个处理过程的并行处理，避免了数据库的读写操作被阻塞住的情况，也不会影响到整个计费业务处理的正常执行，大大处理了效率，而且提高了计费处理的准确率。

附图说明

图1为本发明实施例中进行信息交互的各方硬件实体的示意图；

图2为本发明实施例一方法的实现流程示意图；

图3为本发明实施例又一方法的实现流程示意图；

图4为本发明实施例又一方法的实现流程示意图；

图5为本发明实施例一系统架构组成示意图；

图6为现有计费系统的数据处理示意图；

图7为应用本发明实施例一数据库线程和计费线程相分离场景的系统架构图。

具体实施方式

下面结合附图对技术方案的实施作进一步的详细描述。

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

在下面的详细说明中，陈述了众多的具体细节，以便彻底理解本发明。不过，对于本领域的普通技术人员来说，显然可在没有这些具体细节的情况下实践本发明。在其他情况下，没有详细说明公开的公知方法、过程、组件、电路和网络，以避免不必要地使实施例的各个方面模糊不清。

另外，本文中尽管多次采用术语“第一”、“第二”等来描述各种元件(或各种阈值或各种应用或各种指令或各种操作)等，不过这些元件(或阈值或应用或指令或操作)不应受这些术语的限制。这些术语只是用于区分一个元件(或阈值或应用或指令或操作)和另一个元件(或阈值或应用或指令或操作)。例如，第一操作可以被称为第二操作，第二操作也可以被称为第一操作，而不脱离本发明的范围，第一操作和第二操作都是操作，只是二者并不是相同的操作而已。

本发明实施例中的步骤并不一定是按照所描述的步骤顺序进行处理，可以按照需求有选择的将步骤打乱重排，或者删除实施例中的步骤，或者增加实施例中的步骤，本发明实施例中的步骤描述只是可选的顺序组合，并不代表本发明实施例的所有步骤顺序组合，实施例中的步骤顺序不能认为是对本发明的限制。

本发明实施例中的术语“和/或”指的是包括相关联的列举项目中的一个或多个的任何和全部的可能组合。还要说明的是：当用在本说明书中时，“包括/包含”指定所陈述的特征、整数、步骤、操作、元件和/或组件的存在，但是不排除一个或多个其他特征、整数、步骤、操作、元件和/或组件和/或它们的组群的存在或添加。

本发明实施例的智能终端(如移动终端)可以以各种形式来实施。例如，本发明实施例中描述的移动终端可以包括诸如移动电话、智能电话、笔记本电脑、数字广播接收器、个人数字助理(PDA，Personal Digital Assistant)、平板电脑(PAD)、便携式多媒体播放器(PMP，Portable Media Player)、导航装置等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。下面，假设终端是移动终端。然而，本领域技术人员将理解的是，除了特别用于移动目的的元件之外，根据本发明的实施方式的构造也能够应用于固定类型的终端。

图1为本发明实施例中进行信息交互的各方硬件实体的示意图，图1中包括：终端设备1，服务器2。其中，终端设备1由终端设备11-14构成，终端设备通过有线网络或者无线网络与服务器进行信息交互。终端设备包括手机、台式机、PC机、一体机等类型。采用本发明实施例，终端设备是数据的提供方，具体的处理逻辑在服务器侧，数据加载过程中，不是等当前数据都加载完成才执行计费处理，而是通过异步处理机制在数据加载过程和计费过程间实现并行处理。类似的，通过设置缓冲区来存储计费处理后得到的待提交给数据库的该待提交数据，回写数据库的过程中，从所述缓冲区得到该待提交数据即可进行数据库的异步持久化处理，从而通过异步处理机制在计费过程和回写数据库过程间实现并行处理。服务器的处理逻辑10如图1所示，处理逻辑10包括：S1、从数据库中加载第一数据到内存中，该第一数据至少包括消耗数据和预算数据两种类型，所述第一数据为对应当前第一时刻的最新数据。S2、当检测到所述数据库出现数据处理阻塞时，从所述内存中读取第二数据，该第二数据至少包括消耗数据和预算数据两种类型，所述第二数据相对所述第一数据而言，是旧的数据，也就是说，第一数据是当前时刻正在加载的数据，而第二数据是当前时刻之前的上一个时刻已经加载完成的数据。即：从所述内存中读取相对于第一数据上一个时刻的第二数据。S3、根据所述第二数据进行计费处理，得到待提交给所述数据库的待提交数据，将所述待提交数据放到缓冲区。S4、根据从所述缓冲区不断读取得到的所述待提交数据进行数据库的异步持久化处理。

上述图1的例子只是实现本发明实施例的一个系统架构实例，本发明实施例并不限于上述图1所述的系统结构，基于上述图1所述的系统架构，提出本发明方法各个实施例。

本发明实施例的一种数据并行处理的方法，如图2所示，所述方法包括：从数据库中加载第一数据到内存中，所述第一数据为对应当前第一时刻的最新数据(101)。在数据加载过程中，上一个时刻的数据相对于当前数据而言，可以认为是旧的数据，而当前数据为新的数据，根据从内存中读取的数据进行计费处理时，不需要等当前数据全部加载完毕才执行该处理过程。需要指出的是，这里的“第一数据”和后续的“第二数据”只是为了对不同时刻的加载数据进行区分，并没有限定的意思。也就是说，从数据库加载到内存中的数据包括当前加载的最新数据、和相对该最新数据而言之前加载的旧数据，而不论数据的“新”或“旧”，其数据类型都至少包括消耗数据和预算数据。可见，从所述数据库中加载至少两类数据到内存中，所述至少两类数据包括：预算数据和消耗数据。其中，所述预算数据用于表征由终端用户写入的符合预期业务需求的数据类型，而所述消耗数据用于表征与所述预算数据相关消耗的数据类型。当检测到所述数据库出现数据处理，比如数据读写处理阻塞时，从所述内存中读取第二数据，所述第二数据为对应上一个第二时刻的旧数据(102)。根据所述第二数据进行计费处理，得到待提交给所述数据库的待提交数据，将所述待提交数据放到缓冲区(103)。根据从所述缓冲区不断读取得到的所述待提交数据进行数据库的异步持久化处理(104)。

采用本发明实施例，在加载数据库的时候，如果数据库出现阻塞，可以使用上一次从数据库加载到内存的数据进行计费，计费处理线程不必等待数据库完全加载。计费处理线程在提交数据库的时候，不必等待数据库提交成功，而是可以通过将需要提交的数据放到缓冲区的缓冲队列中直接返回，然后由数据库线程从该缓冲区的缓冲队列中不断读取待提交数据进行异步持久化操作。通过上述步骤实现了数据库操作和计费业务处理分离，具体可以将数据库处理线程和计费业务的处理线程分离，可以使得计费业务处理既不会因为数据库的读写操作而被阻塞，也能提高计费业务的处理效率和准确度，在一个实际应用中，还可以及时生成停播列表以减少超播，进而提升收入。

本发明实施例的一种数据并行处理的方法，如图3所示，所述方法包括：从数据库中加载第一数据到内存中，所述第一数据为对应当前第一时刻的最新数据(201)。在数据加载过程中，上一个时刻的数据相对于当前数据而言，可以认为是旧的数据，而当前数据为新的数据，根据从内存中读取的数据进行计费处理时，不需要等当前数据全部加载完毕才执行该处理过程。需要指出的是，这里的“第一数据”和后续的“第二数据”只是为了对不同时刻的加载数据进行区分，并没有限定的意思。也就是说，从数据库加载到内存中的数据包括当前加载的最新数据、和相对该最新数据而言之前加载的旧数据，而不论数据的“新”或“旧”，其数据类型都至少包括消耗数据和预算数据。可见，从所述数据库中加载至少两类数据到内存中，所述至少两类数据包括：预算数据和消耗数据。其中，所述预算数据用于表征由终端用户写入的符合预期业务需求的数据类型，而所述消耗数据用于表征与所述预算数据相关消耗的数据类型。当检测到所述数据库出现数据处理，比如数据读写处理阻塞时，从所述内存中读取第二数据，所述第二数据为对应上一个第二时刻的旧数据(202)。对所述内存中读取的消耗数据进行业务处理时，具体是通过计费处理线程对所述消耗数据进行维护，从所述内存中读取当前时刻之前的第一消耗数据(如过时的消耗数据)、当前时刻的第二消耗数据(如当前计费线程用的消耗数据)、对应所述缓冲区内待提交数据块的第三消耗数据(如缓冲区内的待提交块的消耗数据)(203)。将所述第一消耗数据依次加上所述第三消耗数据和所述第二消耗数据进行校验(204)。在实际应用中，由于消耗字段只会由计费处理线程来修改，因此完全可以放在内存中进行维护，没有必要通过每次加载数据库来获取最新的消耗，而后续的回写数据库操作，只是为了把内存中的数据进行持久化操作。根据所述第二数据进行计费处理，得到待提交给所述数据库的待提交数据，将所述待提交数据放到缓冲区(205)。根据从所述缓冲区不断读取得到的所述待提交数据进行数据库的异步持久化处理(206)。

采用本发明实施例，对于消耗数据，只有计费处理线程维护，可以通过从数据库里加载的过时的消耗数据依次加上缓冲区内的待提交块的消耗数据和当前计费线程用的消耗数据进行校验，这种方法可以及时校验到系统的异常、或者其他程序修改了只应由计费处理线程维护的数据库的消耗字段，从而增加了整个计费系统的可靠性和准确性。

本发明实施例的一种数据并行处理的方法，如图4所示，所述方法包括：从数据库中加载第一数据到内存中，所述第一数据为对应当前第一时刻的最新数据(301)。在数据加载过程中，上一个时刻的数据相对于当前数据而言，可以认为是旧的数据，而当前数据为新的数据，根据从内存中读取的数据进行计费处理时，不需要等当前数据全部加载完毕才执行该处理过程。需要指出的是，这里的“第一数据”和后续的“第二数据”只是为了对不同时刻的加载数据进行区分，并没有限定的意思。也就是说，从数据库加载到内存中的数据包括当前加载的最新数据、和相对该最新数据而言之前加载的旧数据，而不论数据的“新”或“旧”，其数据类型都至少包括消耗数据和预算数据。可见，从所述数据库中加载至少两类数据到内存中，所述至少两类数据包括：预算数据和消耗数据。其中，所述预算数据用于表征由终端用户写入的符合预期业务需求的数据类型，而所述消耗数据用于表征与所述预算数据相关消耗的数据类型。当检测到所述数据库出现数据处理，比如数据读写处理阻塞时，从所述内存中读取第二数据，所述第二数据为对应上一个第二时刻的旧数据(302)。对所述内存中读取的预算数据的业务处理时，具体是将所述待提交数据放到缓冲区后，返回计费处理线程，通过所述计费处理线程对以异步方式获取到的所述预算数据进行计费，得到实际的消耗数据(303)。根据所述第二数据进行计费处理，得到待提交给所述数据库的待提交数据，将所述待提交数据放到缓冲区(304)。根据从所述缓冲区不断读取得到的所述待提交数据进行数据库的异步持久化处理(305)。

采用本发明实施例，对于预算数据，通过所述计费处理线程加载预算数据以进行计费时，由于预算数据是信息推荐方(如广告主)通过前台系统可以随时修改的，所以需要不断地通过加载数据库来进行更新，然而考虑到信息推荐方(如广告主)更新预算的频率并不频繁，如果更新数据库的操作出现了阻塞，可以先用上次从数据库加载到内存中的预算数据进行计费，等本次数据库加载完成后，再用本次从数据库加载到内存中的预算数据进行计费。

基于上述各个实施例，一个实施方式中，当检测到所述将待提交数据放到缓冲区的操作为失败时，执行容错回退策略，返回所述计费处理线程，以再次提交所述待提交数据。对于计费处理线程向数据库以异步方式提交所述待提交数据而言，由于是异步提交及返回，首先，向数据库的提交在放入缓冲区的时候，就认为是已经提交成功，以便进行后续的计费处理，如果后来向数据库没有提交成功，由于本实施方式提供了一个容错的回退机制，从而能确保异步提交的可靠性和准确性。

基于上述各个实施例，一个实施方式中，将所述缓冲区的至少一个待提交数据按照等效合并策略进行数据合并。采用本实施方式，对于在缓冲区内的待提交数据，可以进行等效的合并优化，使得可以用更少的sql语句完成等价的工作。

基于上述各个实施例，一个实施方式中，所述待提交数据包括：消耗数据和计费明细数据。对于本实施方式的回写数据库的部分，是将消耗数据和计费的明细数据写入数据库，主要是为了进行持久化操作，通过数据库进行数据的长期保存，因此，这部分并不需要实时的。本实施方式中，可以由计费处理线程将需要通过数据库进行持久化的数据放入缓冲区的一个缓存队列中，数据库线程异步扫描缓冲队列进行提交数据库操作，计费处理线程就可以立即返回，无阻塞地进行下一个文件的计费任务，而不必等待此次的数据库提交完成。

综上所述，通过上述各个实施例及其实施方式中一系列处理，包括加载数据库数据到内存的处理；通过计费处理线程以异步方式从内存中读取上一时刻的数据以进行计费，得到包括消耗数据和计费明细在内的该待提交数据后，以异步方式提交该提交数据的处理；及回写数据库时，数据库线程以异步方式读取该计费处理线程提交的该提交数据的处理，允许该计费处理线程立即返回，无阻塞地进行下一个计费处理，可以实现将数据库操作和计费业务操作相分离，使得计费处理线程可以无阻塞地连续计费。计费业务处理既不会因为数据库的读写操作而被阻塞，也能提高计费业务的处理效率和准确度。在一个实际应用中，还可以及时生成停播列表以减少超播，进而提升收入。

本发明实施例的数据并行处理的系统，如图5所示，包括终端41和服务器42。终端是数据的提供方，具体的处理逻辑在服务器侧，数据加载过程中，不是等当前数据都加载完成才执行计费处理，而是通过异步处理机制在数据加载过程和计费过程间实现并行处理。类似的，通过设置缓冲区来存储计费处理后得到的待提交给数据库的该待提交数据，回写数据库的过程中，从所述缓冲区得到该待提交数据即可进行数据库的异步持久化处理，从而通过异步处理机制在计费过程和回写数据库过程间实现并行处理。其中，服务器42包括：加载单元421，用于从数据库中加载第一数据到内存中，所述第一数据为对应当前第一时刻的最新数据；读取单元422，用于当检测到所述数据库出现数据处理阻塞时，从所述内存中读取第二数据，所述第二数据为对应上一个第二时刻的旧数据；计费单元423，用于根据所述第二数据进行计费处理，得到待提交给所述数据库的待提交数据，将所述待提交数据放到缓冲区；回写处理单元424，用于根据从所述缓冲区不断读取得到的所述待提交数据进行数据库的异步持久化处理。

本发明实施例是从数据库中加载第一数据到内存中，所述第一数据为对应当前第一时刻的最新数据。在数据加载过程中，上一个时刻的数据相对于当前数据而言，可以认为是旧的数据，而当前数据为新的数据，根据从内存中读取的数据进行计费处理时，不需要等当前数据全部加载完毕才执行该处理过程。需要指出的是，这里的“第一数据”和后续的“第二数据”只是为了对不同时刻的加载数据进行区分，并没有限定的意思。也就是说，从数据库加载到内存中的数据包括当前加载的最新数据、和相对该最新数据而言之前加载的旧数据，而不论数据的“新”或“旧”，其数据类型都至少包括消耗数据和预算数据。可见，从所述数据库中加载至少两类数据到内存中，所述至少两类数据包括：预算数据和消耗数据。其中，所述预算数据用于表征由终端用户写入的符合预期业务需求的数据类型，而所述消耗数据用于表征与所述预算数据相关消耗的数据类型。当检测到所述数据库出现数据处理，比如数据读写处理阻塞时，从所述内存中读取第二数据，所述第二数据为对应上一个第二时刻的旧数据)。根据所述第二数据进行计费处理，得到待提交给所述数据库的待提交数据，将所述待提交数据放到缓冲区。根据从所述缓冲区不断读取得到的所述待提交数据进行数据库的异步持久化处理。采用本发明实施例，在加载数据库的时候，如果数据库出现阻塞，可以使用上一次从数据库加载到内存的数据进行计费，计费处理线程不必等待数据库完全加载。计费处理线程在提交数据库的时候，不必等待数据库提交成功，而是可以通过将需要提交的数据放到缓冲区的缓冲队列中直接返回，然后由数据库线程从该缓冲区的缓冲队列中不断读取待提交数据进行异步持久化操作。通过上述步骤实现了数据库操作和计费业务处理分离，具体可以将数据库处理线程和计费业务的处理线程分离，可以使得计费业务处理既不会因为数据库的读写操作而被阻塞，也能提高计费业务的处理效率和准确度，在一个实际应用中，还可以及时生成停播列表以减少超播，进而提升收入。

在本发明实施例一实施方式中，所述加载单元，进一步用于：从所述数据库中加载至少两类数据到内存中；

所述至少两类数据包括：预算数据和消耗数据；所述预算数据用于表征由终端用户写入的符合预期业务需求的数据类型；所述消耗数据用于表征与所述预算数据相关消耗的数据类型。

在本发明实施例一实施方式中，所述计费单元，进一步用于：通过所述计费处理线程对所述消耗数据进行维护时，从所述内存中读取当前时刻之前的第一消耗数据、当前时刻的第二消耗数据、对应所述缓冲区内待提交数据块的第三消耗数据；将所述第一消耗数据依次加上所述第三消耗数据和所述第二消耗数据进行校验。

在本发明实施例一实施方式中，所述计费单元，进一步用于：将所述待提交数据放到缓冲区后，通过所述计费处理线程对以异步方式获取到的所述预算数据进行计费，得到实际的消耗数据。

在本发明实施例一实施方式中，所述服务器还包括：回退单元，用于：当检测到所述将待提交数据放到缓冲区的操作为失败时，执行容错回退策略，返回所述计费处理线程，以再次提交所述待提交数据。

在本发明实施例一实施方式中，所述服务器还包括：合并单元，用于：将所述缓冲区的至少一个待提交数据按照等效合并策略进行数据合并。

在本发明实施例一实施方式中，所述待提交数据包括：消耗数据和计费明细数据。

其中，对于用于数据处理的处理器而言，在执行处理时，可以采用微处理器、中央处理器(CPU，Central Processing Unit)、数字信号处理器(DSP，Digital SingnalProcessor)或可编程逻辑阵列(FPGA，Field－Programmable Gate Array)实现；对于存储介质来说，包含操作指令，该操作指令可以为计算机可执行代码，通过所述操作指令来实现上述本发明实施例信息处理方法流程中的各个步骤。

这里需要指出的是：以上涉及终端和服务器项的描述，与上述方法描述是类似的，同方法的有益效果描述，不做赘述。对于本发明终端和服务器实施例中未披露的技术细节，请参照本发明方法流程描述的实施例所描述内容。

以一个现实应用场景为例对本发明实施例阐述如下：

数据处理涉及广告数据处理的场景中，首先对一些名词解释如下：

1)效果广告CPC计费模式(Cost Per Click)：按点击次数进行收费的模式，是一种按照效果进行收费的计费模式。对于网站主来说，要获得更多的收入，需要提高曝光的点击转化率。

2)效果广告CPM计费模式(Cost Per Mille)：对曝光进行收费的模式，按照显示的次数来计算广告费，它使得广告的每次展示都有自己的价值。

3)广告主：是为推销商品或者提供服务，自行或者委托他人设计、制作、发布广告的法人、其他经济组织或者个人。是市场经济及广告活动的重要参与者。

4)广告主余额：广告主可用于广告投放的资金，在投放排期内，广告主的余额会被消费，广告主也可以进行充值来增加余额。

5)推广计划：广告主管理一系列关键词、创意的大单位，每一个推广计划拥有单独的投放预算和投放时间。每个广告主通常会同时有几个推广计划。

6)推广计划总预算：推广计划在整个推广排期内的最大允许消耗。

7)推广计划日预算：推广计划在整个推广排期内单日的最大允许消耗。

订单：推广计划下管理一组关键词、创意的基本单位，通常每个推广计划下会下设几个订单。

8)应收：通过计费明细中的价格参数计算出来的点击或曝光的实际收费价格。

9)实收：由于受广告主的余额和推广计划的预算限制，在不超过限制范围内的应收可成功转化为实收。

10)超播：由于受广告主的余额和推广计划的预算限制，超过限制范围的应收就会转化为超播。

11)停播：当广告主的余额用完，或者推广计划的总预算或当日预算达到上限后，广告主或其下的到达预算的推广计划下的订单将不能再继续播放，变成停播状态。

12)停播列表：达到停播状态的订单的集合。

13)计费系统：计费系统处理计费落地文件，从计费落地文件中计算出每条点击或曝光的应收，然后通过广告主的余额和推广计划的预算计算出实收，并且将明细数据和消耗数据写入数据库进行持久化操作，同时生成停播列表。

在应用数据处理的一个广告计费系统中，如图6所示，包括：数据库加载过程，计费处理过程和数据库持久化处理过程。使用该系统架构进行计费处理时，每次处理一批点击和曝光数据的计费任务时，首先会从数据库里加载广告主的余额信息，推广计划的总预算，日预算，总消耗和当日消耗等信息到内存中，然后根据点击或曝光信息计算出应收，同时根据从数据库加载到内存中用户的账户和推广计划的余额计算出实际的消耗。最后将点击和聚合后的曝光明细数据写入明细库进行持久化操作，同时更新数据库中用户的余额数据和推广计划的消耗数据。

应收的价格为price，用户的余额为balance，推广计划的总预算为budget消耗为used，日预算为day_budget，消耗为today_used。

推广计划的剩余总预算remain_budget＝budget－used

推广计划的剩余日预算remain_day_budget＝day_budget－today_used

实收的价格cost＝min(price,balance,remain_budget,remain_day_budget)

采用上述现有系统架构存在的问题是：在现有的技术方案中，数据库的读写操作和计费的业务处理操作是串行的，随着业务的进一步发展，广告主，推广计划，订单以及需要计费的点击曝光数量都会急剧增多，这将会导致加载数据库和进行数据库持久化操作的时间越来越长。另外，由于预算等数据库字段都是通过前台系统进行修改的，这使得我们使用的数据库是和前台业务共有的，一旦前台的数据库并发访问量大，就会导致数据库的读写操作被阻塞住，进而影响到计费业务线程的处理和停播列表的及时下发，使得达到预算限制的订单仍然处于播放状态从而造成超播上升，引起收入损失。

对上述场景采用本发明实施例，是将广告计费系统中的将数据库操作和业务处理分离的方案，使得数据加载过程，计费处理过程，数据库持久化过程处于异步机制实现的并行处理中。具体的，本发明实施例为了解决加载和写入数据库可能对计费业务线程产生阻塞的问题。首先，分析加载数据库的部分，从数据库加载的数据主要分为两部分，预算数据和消耗数据。由于消耗字段只会由计费程序来修改，因此，完全可以放在内存中进行维护，没有必要通过每次加载数据库来获取最新的消耗，回写数据库只是为了把内存中的数据进行持久化操作。剩下的就是加载预算了，由于预算是广告主通过前台系统可以随时修改的，所以需要不断地通过加载数据库来进行更新，然而考虑到广告主更新预算的频率并不频繁，如果更新数据库的操作出现了阻塞，我们完全可以先用上次从数据库加载到内存中的预算数据进行计费，等这次数据库加载完成后，再用这次从数据库加载的预算数据进行计费。其次，分析回写数据库的部分，将消耗数据和计费的明细数据写入数据库，主要是为了进行持久化操作，通过数据库进行数据的长期保存，因此这部分并不需要实时的，可以由计费程序将需要通过数据库进行持久化的数据放入一个缓存队列中，数据库线程异步扫描缓冲队列进行提交数据库操作，计费的业务线程便可以立即返回，无阻塞地进行下一个文件的计费任务，而不必等待此次的数据库提交完成。

经过上述处理，从而可以通过将数据库操作和计费业务线程分离出来，使得计费线程可以无阻塞地连续计费，及时生成停播列表，从而达到减少超播，提升收入的效果。

如图7所示为本发明实施例一应用场景中的数据库线程和业务线程分离后的系统架构，该计费系统架构将数据库的操作从计费业务处理线程中分离了出来，在每次循环中，t0-t1时刻中，数据库线程正在将预算和消耗数据从数据库加载到内存中，即图7中以表示的第一数据块，其预算数据是最新的，但是加载出来的消耗数据是上个循环t3时刻点提交到数据库中的数据，从上个循环的t3时刻到当前循环的t1时刻，计费业务线程仍然在不停地进行计费操作，将待持久化的数据源源不断地放入到缓存队列中，此时计费线程中更新的计费内存数据的消耗值是准确值。这个值(当前循环t1时刻的消耗)和第一数据块的消耗值(上个循环t3时刻的消耗值)与缓冲队列内的2个以表示的第二数据块的消耗值(上个循环t3～当前循环t1时刻的消耗值)相加必须是一致的，这个恒等式也可以用来校验计费系统是否正常工作。在t1-t2时刻，需要将缓冲队列中的所有第二数据块中的消耗值累加给第一数据块，然后提供给计费线程进行计费。这一部分虽然计费线程需要阻塞，但是耗时比较短。

t2-t4时间段是进行待提交数据提交数据库进行持久化的部分，在t2-t3部分，需要给缓冲队列上锁，然后将缓冲队列内的待提交数据块放到临时队列中。在t3-t4部分，计费线程将存放在临时队列中的待提交数据提交到了数据库中，在这个时间段，计费线程可以无阻塞地进行计费，不断地将新的待提交数据放到缓冲队列中，接着就是下一个循环的加载数据库的过程了。

由于提交数据库的时候是异步进行的，计费线程提交数据库的过程只是将待提交数据放到缓存队列中，然后就返回进行下一批数据的计费了，在提交数据库过程中，难免会有提交数据库失败的情况，计费系统是一个精细的系统，必须要处理这种提交失败的情况。

在t3-t4的过程中，如图7所示的缓存队列中有2个待提交数据块需要提交，如果第一个块提交失败(每个块提交3次均失败才算真正的失败)，第一个块对应的原始落地文件需要放到失败目录中，进行人工处理(需要指出的是，这种情况很少发生)。

此时从预算的角度考虑，在缓存队列中这2个待提交数据块的第2个数据块的实收准确的前提是第1个数据块必须要准确(假设推广计划x的预算为1000，第1个数据块推广计划x的应收为500，实收为500，第2个数据块推广计划x的应收为1000，由于总预算限制为1000，所以第2个数据块的实收只能为500，超播500。但当第1个块的提交失败后，第1个数据块推广计划x的消耗为0，第2个数据块的实收就可以达到1000，没有超播了。所以前一个数据块提交失败后，后续的数据块的应收可以不需要计算，但实收需要重新回炉计算)，第2个数据块需要重新由业务线程计算实收后重新放入缓冲队列进行计费。另外，在缓冲队列中的数据块还是可以合并的，某个推广计划在两个块中分别消耗c1和c2，那么可以合并成消耗c1+c2元，这样原来需要2条sql语句进行提交，现在只需要1条sql语句就可以完成等价的操作。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元，即可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本发明各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

或者，本发明上述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本发明各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (14)

1.一种数据并行处理的方法，其特征在于，所述方法包括：

从数据库中加载第一数据到内存中，所述第一数据为对应当前第一时刻的最新数据；

当检测到所述数据库出现数据处理阻塞时，从所述内存中读取第二数据，所述第二数据为对应上一个第二时刻的旧数据；

根据所述第二数据进行计费处理，得到待提交给所述数据库的待提交数据，将所述待提交数据放到缓冲区；

根据从所述缓冲区不断读取得到的所述待提交数据进行数据库的异步持久化处理。

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

从所述数据库中加载至少两类数据到内存中；

所述至少两类数据包括：预算数据和消耗数据；

所述预算数据用于表征由终端用户写入的符合预期业务需求的数据类型；

所述消耗数据用于表征与所述预算数据相关消耗的数据类型。

3.根据权利要求2所述的方法，其特征在于，所述方法还包括：

通过所述计费处理线程对所述消耗数据进行维护时，从所述内存中读取当前时刻之前的第一消耗数据、当前时刻的第二消耗数据、对应所述缓冲区内待提交数据块的第三消耗数据；

将所述第一消耗数据依次加上所述第三消耗数据和所述第二消耗数据进行校验。

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

将所述待提交数据放到缓冲区后，通过所述计费处理线程对以异步方式获取到的所述预算数据进行计费，得到实际的消耗数据。

5.根据权利要求2所述的方法，其特征在于，所述方法还包括：

当检测到所述将待提交数据放到缓冲区的操作为失败时，执行容错回退策略，返回所述计费处理线程，以再次提交所述待提交数据。

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

将所述缓冲区的至少一个待提交数据按照等效合并策略进行数据合并。

7.根据权利要求2所述的方法，其特征在于，所述待提交数据包括：消耗数据和计费明细数据。

8.一种服务器，其特征在于，所述服务器包括：

加载单元，用于从数据库中加载第一数据到内存中，所述第一数据为对应当前第一时刻的最新数据；

读取单元，用于当检测到所述数据库出现数据处理阻塞时，从所述内存中读取第二数据，所述第二数据为对应上一个第二时刻的旧数据；

计费单元，用于根据所述第二数据进行计费处理，得到待提交给所述数据库的待提交数据，将所述待提交数据放到缓冲区；

回写处理单元，用于根据从所述缓冲区不断读取得到的所述待提交数据进行数据库的异步持久化处理。

9.根据权利要求8所述的服务器，其特征在于，所述加载单元，进一步用于：

从所述数据库中加载至少两类数据到内存中；

所述至少两类数据包括：预算数据和消耗数据；

所述预算数据用于表征由终端用户写入的符合预期业务需求的数据类型；

所述消耗数据用于表征与所述预算数据相关消耗的数据类型。

10.根据权利要求9所述的服务器，其特征在于，所述计费单元，进一步用于：

通过所述计费处理线程对所述消耗数据进行维护时，从所述内存中读取当前时刻之前的第一消耗数据、当前时刻的第二消耗数据、对应所述缓冲区内待提交数据块的第三消耗数据；

将所述第一消耗数据依次加上所述第三消耗数据和所述第二消耗数据进行校验。

11.根据权利要求9所述的服务器，其特征在于，所述计费单元，进一步用于：

将所述待提交数据放到缓冲区后，通过所述计费处理线程对以异步方式获取到的所述预算数据进行计费，得到实际的消耗数据。

12.根据权利要求9所述的服务器，其特征在于，所述服务器还包括：回退单元，用于：

当检测到所述将待提交数据放到缓冲区的操作为失败时，执行容错回退策略，返回所述计费处理线程，以再次提交所述待提交数据。

13.根据权利要求9所述的服务器，其特征在于，所述服务器还包括：合并单元，用于：

将所述缓冲区的至少一个待提交数据按照等效合并策略进行数据合并。

14.根据权利要求9所述的服务器，其特征在于，所述待提交数据包括：消耗数据和计费明细数据。