CN112433886A - 数据处理方法和装置、服务器及存储介质 - Google Patents

Abstract

本申请实施例提供的数据处理方法和装置、服务器及存储介质，涉及数据处理技术领域。数据处理方法包括：首先，响应于结算处理信号，获取待处理结算数据；其次，对待处理结算数据进行复制处理，得到预设格式的复制结算数据；然后，对复制结算数据进行结算处理，得到结算处理结果。通过上述设置，可以实现对复制后的预设格式的复制结算数据进行结算处理，改善了现有技术中直接根据原始的结算数据进行更新操作可能会出现部分成功部分失败的结果，所导致的结算处理的可靠性低的问题。

Description

数据处理方法和装置、服务器及存储介质

技术领域

本申请涉及数据处理技术领域，具体而言，涉及一种数据处理方法和装置、服务器及存储介质。

背景技术

经过发明人研究发现，在现有结算恢复技术中，由于直接根据原始的结算数据进行更新操作可能会出现部分成功部分失败的结果，从而存在着结算处理的可靠性低的问题。

发明内容

有鉴于此，本申请的目的在于提供一种数据处理方法和装置、服务器及存储介质，以改善现有技术中存在的问题。

为实现上述目的，本申请实施例采用如下技术方案：

第一方面，本发明提供一种数据处理方法，包括：

响应于结算处理信号，获取待处理结算数据；

对所述待处理结算数据进行复制处理，得到预设格式的复制结算数据；

对所述复制结算数据进行结算处理，得到结算处理结果。

在可选的实施方式中，所述复制结算数据包括多个日志，所述对所述复制结算数据进行结算处理，得到结算处理结果的步骤，包括：

对所述多个日志进行聚合处理；

对聚合处理后的复制结算数据进行结算处理，得到结算处理结果。

在可选的实施方式中，所述日志包括结算主体，所述对所述多个日志进行聚合处理的步骤，包括：

获取每一个日志的结算主体；

根据所述结算主体对所述多个日志进行聚合处理。

在可选的实施方式中，所述对聚合处理后的复制结算数据进行结算处理，得到结算处理结果的步骤，包括：

针对每一个结算主体，获取该结算主体的预设处理信息；

根据该结算主体的预设处理信息对属于该结算主体的复制结算数据进行结算处理，得到结算处理结果。

在可选的实施方式中，所述数据处理方法还包括：

对结算处理后的复制结算数据进行存储。

在可选的实施方式中，所述数据处理方法还包括：

判断所述结算处理结果是否包括每个日志的结果；

若否，则获取所述待处理结算数据，对所述待处理结算数据进行结算处理，得到新的结算处理结果。

在可选的实施方式中，所述数据处理方法还包括：

判断所述结算处理结果是否重复；

若是，则获取所述待处理结算数据，对所述待处理结算数据进行结算处理，得到新的结算处理结果。

第二方面，本发明提供一种数据处理装置，包括：

数据获取模块，用于响应于结算处理信号，获取待处理结算数据；

复制处理模块，用于对所述待处理结算数据进行复制处理，得到预设格式的复制结算数据；

结算处理模块，用于对所述复制结算数据进行结算处理，得到结算处理结果。

第三方面，本发明提供一种服务器，包括存储器和处理器，所述处理器用于执行所述存储器中存储的可执行的计算机程序，以实现前述实施方式任意一项所述的数据处理方法。

第四方面，本发明提供一种存储介质，其上存储有计算机程序，该程序被执行时实现前述实施方式任意一项所述数据处理方法的步骤。

本申请实施例提供的数据处理方法和装置、服务器及存储介质，通过对待处理结算数据进行复制处理得到预设格式的复制结算数据，对复制结算数据进行结算处理，得到结算处理结果，实现了对复制后的预设格式的复制结算数据进行结算处理，改善了现有技术中直接根据原始的结算数据进行更新操作可能会出现部分成功部分失败的结果，所导致的结算处理的可靠性低的问题。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的数据处理系统的结构框图。

图2为本申请实施例提供的数据处理方法的流程示意图。

图3为本申请实施例提供的数据处理方法的另一流程示意图。

图4为本申请实施例提供的数据处理方法的另一流程示意图。

图5为本申请实施例提供的数据处理方法的另一流程示意图。

图6为本申请实施例提供的数据处理方法的另一流程示意图。

图7为本申请实施例提供的数据处理方法的另一流程示意图。

图8为本申请实施例提供的数据处理方法的另一流程示意图。

图9为本申请实施例提供的数据处理装置的结构框图。

图标：10-数据处理系统；100-服务器；200-终端设备；900-数据处理装置；910-数据获取模块；920-复制处理模块；930-结算处理模块。

具体实施方式

广告引擎由结算模块负责曝光日志结算功能，而且目前多采用实时结算模式。目前常见的广告系统日志量一般在亿级～百亿/天，采用批量处理的方式进行日志结算，是提高结算性能的通用方式，可以减少资源消耗。广告曝光日志从终端回传之后，一般使用消息队列存放，而曝光日志中会携带广告ID或者广告主ID，作为区分曝光的标志信息，也是结算的依据。批量处理时，首先根据广告ID或者广告主ID进行聚合，然后按照所属ID进行结算，所以只有当一批日志都完成扣除相应广告主金额信息后，才能确认这批日志结算完成，即批量处理时将每一批的日志结算作为一个事务操作。而实际中，广告主金额信息存储方式有多种，一般采用关系型数据库或者KV型数据库存储广告主金额信息，方便查询和更新操作，以KV型数据库为例，多条账户金额信息更新操作很难作为一个事务操作，所以只能尽可能保证多的账户金额更新成功，一旦出现重启情况，并且重启时只有部分广告主结算信息更新成功，重启之后会从数据库获取重启之前日志队列的最新位置，但是由于重启之前的更新操作不是一个事务操作，所以最后一次批处理涉及的账户只有部分更新成功，则很难找到正确的数据恢复点，为了保证结算数据正确，则需要广告结算信息和广告报表服务对比结算信息，进行金额信息校正。

根据现有广告结算恢复技术，由于批处理曝光日志引发的账户数据库更新操作不是事务操作，所以可能会出现部分成功部分失败的结果，因此数据库很难给出正确的数据恢复点，一旦出现需要找到数据恢复点重新进行计费时，会出现重复扣费或者漏扣费问题。

举例说明结算数据恢复时会遇到问题：例如，批处理10条广告曝光日志，这10条日志分别属于3个广告主：owner1，owner2，owner3，曝光日志在消息队列中存储顺序如下[owner1，owner2，owner3，owner3，owner1，owner1，owner2，owner2，owner2，owner1]，这10条曝光日志在消息队列中的编号为order＝[1，2，3，4，5，6，7，8，9，10]，在结算时先按照owner聚合10条曝光日志，结果如下：<owner1,total_pv＝4,total_cost＝cost1*total_pv>，<owner2,total_pv＝4,total_cost＝cost2*total_pv>，<owner3,total_pv＝2,total_cost＝cost3*total_pv>，然后对相应帐户扣费，最后提交扣费之后的账户金额信息，并更新每个账户结算成功的最后一条日志的位置。假设在提交账户金额步骤出现意外(例如出现重启操作)，那么就出现一部分账户金额更新成功，一部分金额更新不成功的问题，以上述10条曝光日志为例，假设在owner3账户更新成功之后，owner1和owner2对应账户更新成功之前出现意外，则重启之后，结算数据恢复模块会根据owner1、owner2、owner3最后结算的日志位置，比较得出重启的日志结算起始位置，有两种选择：其一是选择上次结算的最新的位置作为此次重启的日志结算起始位置，即order＝5的位置开始日志结算，结果会出现曝光日志丢失问题，在重启之前的最后一次结算中，并没有将order＝1的owner1日志和order＝2的owner2日志结算信息更新成功，则owner1漏计费order＝1的日志，owner2漏计费order＝2的日志；其二是选择上次结算的起始位置作为此次重启的日志结算重启位置，即从order＝1开始日志结算，结果就会出现重复计费的情况。所以，目前采用广告结算和广告报表服务相互对比以弥补重复计费或者日志丢失的问题，但是由于广告报表服务一般是非实时离线数据统计，所以因为重启引发的校正工作就需要延时对比，带来的不良影响就是某些账户可能会因此出现账户金额超投现象(日志丢失造成需要引擎更多的曝光)或者多扣现象(日志重复计费)。

为了改善本申请所提出的上述至少一种技术问题，本申请实施例提供一种数据处理方法和装置、服务器及存储介质，下面通过可能的实现方式对本申请的技术方案进行说明。

针对以上方案所存在的缺陷，均是发明人在经过实践并仔细研究后得出的结果，因此，上述问题的发现过程以及本申请针对上述问题所提出的解决方案，都应该是发明人在本申请过程中对本申请做出的贡献。

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行详细地描述，应当理解，本申请中附图仅起到说明和描述的目的，并不用于限定本申请的保护范围。另外，应当理解，示意性的附图并未按实物比例绘制。本申请中使用的流程图示出了根据本申请的一些实施例实现的操作。应该理解，流程图的操作可以不按顺序实现，没有逻辑的上下文关系的步骤可以反转顺序或者同时实施。此外，本领域技术人员在本申请内容的指引下，可以向流程图添加一个或多个其他操作，也可以从流程图中移除一个或多个操作。

另外，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请的实施例，本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本申请保护的范围。

为了使得本领域技术人员能够使用本申请内容，给出以下实施方式。对于本领域技术人员来说，在不脱离本申请的精神和范围的情况下，可以将这里定义的一般原理应用于其他实施例和应用场景。本申请的系统或方法的应用可以包括网页、浏览器的插件、客户端终端、定制系统、内部分析系统、或人工智能机器人等，或其任意组合。

需要说明的是，本申请实施例中将会用到术语“包括”，用于指出其后所声明的特征的存在，但并不排除增加其它的特征。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

图1为本申请实施例提供的数据处理系统10的结构框图，其提供了一种数据处理系统10可能的实现方式，参见图1，该数据处理系统10可以包括服务器100、终端设备200中的一种或多种。

其中，服务器100与终端设备200通信连接，以获取终端设备200发送的数据(可以包括待处理结算数据)进行处理，得到结算处理结果。

对于服务器100，需要说明的是，在一些实施例中，服务器100可以是单个服务器设备，也可以是服务器组。服务器组可以是集中式的，也可以是分布式的(例如，服务器100可以是分布式系统)。在一些实施例中，服务器100相对于终端设备200，可以是本地的、也可以是远程的。例如，服务器100可以经由网络访问存储在终端设备200中的信息和/或数据。作为另一示例，服务器100可以直接连接到终端设备200，以访问存储的信息和/或数据。在一些实施例中，服务器100可以在云平台上实现。仅作为示例，云平台可以包括私有云、公有云、混合云、弹性云、社区云(community cloud)、分布式云、跨云(inter-cloud)、多云(multi-cloud)等，或者它们的任意组合。在一些实施例中，服务器100可以在终端设备200上实现。

在一些实施例中，服务器100可以包括处理器。处理器可以处理终端设备200发送的信息和/或数据，以执行本申请中描述的一个或多个功能。在一些实施例中，处理器可以包括一个或多个处理核(例如，单核处理器(S)或多核处理器(S))。仅作为举例，处理器可以包括中央处理单元(Central Processing Unit,CPU)、专用集成电路(ApplicationSpecific Integrated Circuit,ASIC)、专用指令集处理器(Application SpecificInstruction-set Processor,ASIP)、图形处理单元(Graphics Processing Unit,GPU)、物理处理单元(Physics Processing Unit,PPU)、数字信号处理器(Digital SignalProcessor,DSP)、现场可编程门阵列(Field Programmable Gate Array,FPGA)、可编程逻辑器件(Programmable Logic Device,PLD)、控制器、微控制器单元、简化指令集计算机(Reduced Instruction Set Computing,RISC)或微处理器等，或其任意组合。

网络可以用于信息和/或数据的交换。在一些实施例中，数据处理系统10中的一个或多个组件(例如，服务器100和终端设备200)可以向其他组件发送信息和/或数据。例如，服务器100可以经由网络从终端设备200获取数据。在一些实施例中，网络可以是任何类型的有线或者无线网络，或者是他们的结合。仅作为示例，网络可以包括有线网络、无线网络、光纤网络、远程通信网络、内联网、因特网、局域网(Local Area Network，LAN)、广域网(Wide Area Network，WAN)、无线局域网(Wireless Local Area Networks，WLAN)、城域网(Metropolitan Area Network，MAN)、广域网(Wide Area Network，WAN)、公共电话交换网(Public Switched Telephone Network，PSTN)、蓝牙网络、ZigBee网络、或近场通信(NearField Communication,NFC)网络等，或其任意组合。

在一些实施例中，网络可以包括一个或多个网络接入点。例如，网络可以包括有线或无线网络接入点，例如基站和/或网络交换节点，数据处理系统10的一个或多个组件可以通过该接入点连接到网络以交换数据和/或信息。

服务器100中可以包括数据库，数据库可以存储数据和/或指令。在一些实施例中，数据库可以存储从终端设备200获得的数据。在一些实施例中，数据库可以存储本申请中描述的示例性方法的数据和/或指令。在一些实施例中，数据库可以包括大容量存储器、可移动存储器、易失性读写存储器、或只读存储器(Read-Only Memory,ROM)等，或其任意组合。作为举例，大容量存储器可以包括磁盘、光盘、固态驱动器等；可移动存储器可包括闪存驱动器、软盘、光盘、存储卡、zip磁盘、磁带等；易失性读写存储器可以包括随机存取存储器(Random Access Memory,RAM)；RAM可以包括动态RAM(Dynamic Random Access Memory,DRAM)，双倍数据速率同步动态RAM(Double Date-Rate Synchronous RAM,DDR SDRAM)；静态RAM(Static Random-Access Memory,SRAM)，晶闸管RAM(Thyristor-Based RandomAccess Memory,T-RAM)和零电容器RAM(Zero-RAM)等。作为举例，ROM可以包括掩模ROM(Mask Read-Only Memory,MROM)、可编程ROM(Programmable Read-Only Memory,PROM)、可擦除可编程ROM(Programmable Erasable Read-only Memory,PEROM)、电可擦除可编程ROM(Electrically Erasable Programmable read only memory,EEPROM)、光盘ROM(CD-ROM)、以及数字通用磁盘ROM等。在一些实施例中，数据库可以在云平台上实现。仅作为示例，云平台可以包括私有云、公有云、混合云、社区云、分布式云、跨云、多云、弹性云或者其它类似的等，或其任意组合。

在一些实施例中，数据库可以连接到网络以与数据处理系统10(例如，服务器100和终端设备200)中的一个或多个组件通信。数据处理系统10中的一个或多个组件可以经由网络访问存储在数据库中的数据或指令。在一些实施例中，数据库可以直接连接到数据处理系统10中的一个或多个组件(例如，服务器100和终端设备200)。或者，在一些实施例中，数据库也可以是服务器100的一部分。在一些实施例中，数据处理系统10中的一个或多个组件(例如，服务器100和终端设备200)可以具有访问数据库的权限。

图2示出了本申请实施例所提供的数据处理方法的流程图之一，该方法可应用于图1所示的服务器100，由图1中的服务器100执行。应当理解，在其他实施例中，本实施例的数据处理方法中的部分步骤的顺序可以根据实际需要相互交换，或者其中的部分步骤也可以省略或删除。下面对图2所示的数据处理方法的流程进行详细描述。

步骤S210，响应于结算处理信号，获取待处理结算数据。

步骤S220，对待处理结算数据进行复制处理，得到预设格式的复制结算数据。

步骤S230，对复制结算数据进行结算处理，得到结算处理结果。

上述方法通过对待处理结算数据进行复制处理得到预设格式的复制结算数据，对复制结算数据进行结算处理，得到结算处理结果，实现了对复制后的预设格式的复制结算数据进行结算处理，改善了现有技术中直接根据原始的结算数据进行更新操作可能会出现部分成功部分失败的结果，所导致的结算处理的可靠性低的问题。

对于步骤S210，需要说明的是，待处理结算数据的具体结构不受限制，可以根据实际应用需求进行设置。例如，在一种可以替代的示例中，待处理结算数据可以为预设格式的数据，直接对待处理结算数据进行复制处理。又例如，在另一种可以替代的示例中，待处理结算数据可以为非预设格式的数据，可以将待处理结算数据转化成预设格式之后再进行复制处理。

可选地，待处理结算数据的获取方式不受限制，可以根据实际应用需求进行设置。例如，在一种可以替代的示例中，服务器100可以获取终端设备200发送的待处理结算数据。又例如，在另一种可以替代的示例中，服务器100可以存储有待处理结算数据。

其中，结算数据的数据结构可以包括结算数据版本、更新时间、日志队列中计费位置、结算主体(可以包括广告主)、历史充值总额、历史扣费总额等数据。

详细地，可以通过以下代码标识当前结算数据的数据结构：

"current_version":{

"current_version_time":"yyyy-mm-dd-HH-MM"

}；

可以通过以下表格中的内容进行释义：

进一步地，可以通过以下代码标识所有广告主结算数据都存在的某个特定版本的结算数据的数据结构：

"version_yyyy-mm-dd-HH-MM":{

"last_version_time":"yyy-mm-dd-HH-MM"

}；

可以通过以下表格中的内容进行释义：

进一步地，可以通过以下代码标识日志队列当前消耗位置的数据结构：

可以通过以下表格中的内容进行释义：

进一步地，可以通过以下代码标识广告主某个特定版本号的结算数据的数据结构：

每一条上述数据结构都包含该广告主某个版本的金额信息，而且携带上一个版本的结算信息，可以通过以下表格中的内容进行释义：

举例说明，假设共有3个广告主owner1、owner2、owner3，上一次更新的结算版本号是在2019-10-30 20：10分完成的，此版本存储在集中式存储中，则根据上述数据结构可以写出以下信息：

首先，可以根据结算数据初始状态中current_version字段，获取当前结算数据的版本号为2019-10-30-20-10，则根据此版本号获取队列信息queue_2019-10-30-20-10内容，获取队列名为0的位置为1000，同时获取广告主owner1的ad_owner_id_owner1_2019-10-30-20-10的结算数据为[deposit＝20，deduction＝10]，owner2的ad_owner_id_owner2_2019-10-30-20-10的结算数据为[deposit＝100，deduction＝5]，owner3的ad_owner_id_owner3_2019-10-30-20-10的结算数据为[deposit＝300，deduction＝15]。

需要说明的是，广告主结算数据使用版本号区分每个版本的数据，既可以根据current_version获取最新版本的数据，存在last_version_time字段，类似链式存储结构，可以根据last_version_time字段回溯每个广告主在每个时间点的结算信息，有利于追溯广告主的结算历史，方便做多维度的数据监控。

对于步骤S220，需要说明的是，本申请实施例中对结算数据的处理采用数据隔离方式，即当对广告主进行扣费之前，先复制广告主当前最新未提交版本的结算数据，然后对复制结算数据进行结算处理，成功后设置新的版本号。优点在于：数据隔离方式可以完全避免数据干扰，即已提交和未提交版本，版本号的设置，可以允许同一个广告帐户的多个版本存在，可以根据事务执行结果决定是否提交数据，结算操作成功，则新版本可以提交，结算操作失败，则新版本可以抛弃，新旧版本之间做到了严格的物理隔离，可以在新旧版本上并行执行不同操作，可以提高吞吐量和资源利用率，即数据持久化、数据查询和数据结算可以并行运行，数据持久化和数据查询即IO操作，数据结算即CPU操作，利用CPU与IO操作并行操作，可以并行执行多个事务。

对于步骤S230，需要说明的是，进行结算处理的步骤不受限制，可以根据实际应用需求进行设置。例如，在一种可以替代的示例中，复制结算数据包括多个日志，步骤S230可以包括进行聚合处理的步骤。因此，在图2的基础上，图3为本申请实施例提供的另一种数据处理方法的流程示意图，参见图3，步骤S230可以包括：

步骤S231，对多个日志进行聚合处理。

步骤S232，对聚合处理后的复制结算数据进行结算处理，得到结算处理结果。

需要说明的是，聚合处理的步骤可以在复制处理的操作之前，先将待处理结算数据进行聚合处理再进行复制处理，得到复制结算数据；聚合处理的步骤可以在复制处理的操作之后，先将待处理结算数据进行复制处理，得到复制结算数据，再对复制结算数据进行聚合处理。

对于步骤S231，需要说明的是，进行聚合处理的步骤不受限制，可以根据实际应用需求进行设置。例如，在一种可以替代的示例中，日志包括结算主体，步骤S231可以包括根据结算主体进行聚合处理的步骤。因此，在图3的基础上，图4为本申请实施例提供的另一种数据处理方法的流程示意图，参见图4，步骤S231可以包括：

步骤S2311，获取每一个日志的结算主体。

步骤S2312，根据结算主体对多个日志进行聚合处理。

详细地，从队列名为0的位置开始批量获取10条广告曝光日志，分别属于3个广告主：owner1，owner2，owner3，曝光日志在消息队列中存储顺序如下[owner1，owner2，owner3，owner3，owner1，owner1，owner2，owner2，owner2，owner1]，曝光日志在消息队列queue1中的编号为order＝[1001，1002，1003，1004，1005，1006，1007，1008，1009，1010]。然后，按照owner聚合10条曝光日志并记录相应的队列信息，结果如下：[owner1，cost＝40，queue1，max_order＝1010]，[owner2，cost＝80，queue1，max_order＝1009]，[owner3，cost＝60，queue1，max_order＝1004]。

对于步骤S232，需要说明的是，进行结算处理的步骤不受限制，可以根据实际应用需求进行设置。例如，在一种可以替代的示例中，步骤S232可以包括根据预设处理信息进行结算处理的步骤。因此，在图3的基础上，图5为本申请实施例提供的另一种数据处理方法的流程示意图，参见图5，步骤S232可以包括：

步骤S2321，针对每一个结算主体，获取该结算主体的预设处理信息。

步骤S2322，根据该结算主体的预设处理信息对属于该结算主体的复制结算数据进行结算处理，得到结算处理结果。

详细地，预设处理信息表征每一个广告主的扣费，广告主owner1的扣费可以为10，广告主owner,2的扣费可以为20，广告主owner3的扣费可以为30。当所有广告主都更新完毕后，可以对广告主信息升级版本号如下：

"version_2019-10-30-20-20":{

"last_version_time":"2019-10-30-20-10"；

}；

同时设置整体版本号：

"current_version":{

"current_version_time":"2019-10-30-20-20"

}

也就是说，结算处理采用批量处理曝光日志，即从曝光日志消息队列中批量获取日志，然后聚合之后，对相应广告主进行扣费。每次从消息队列中批量获取日志，到此批日志涉及的所有广告主扣费完成，这是一个事务操作。不能拆分的原因是，只有当此次批量获取的日志都完成计费并且广告主扣费完成，这些日志才能算是真正结算完成，同时每个广告主在日志队列中日志的最新位置也要更新，只有根据所有广告主在日志队列中最新位置比较得出结算服务消耗该队列的最新位置，所以要么此批日志涉及的广告主同时扣费成功并更新日志队列信息成功，要么一个广告主都不更新，以此避免出现某个广告主更新不成功，造成日志队列中某些日志出现漏计费或者重复计费。如果结算成功，则将此次结算更新的广告主数据和事务ID存入待提交事务队列，即此次更新的广告主数据的提交是原子的，不可分割的。

需要说明的是，在步骤S230之后，本申请实施例提供的数据处理方法还可以包括存储数据的步骤。因此，在图2的基础上，图6为本申请实施例提供的另一种数据处理方法的流程示意图，参见图6，数据处理方法还可以包括：

步骤S240，对结算处理后的复制结算数据进行存储。

详细地，可以将内存中处理后的数据结构持久化到集中式存储中。本事情实施例中结算事务提交(即数据存储)和一般数据库事务提交的不同之处在于：一般数据库事务提交是指只将未提交数据持久化到磁盘中，而本申请实施例是将整个数据结构看作一个整体持久化到集中式内存中，可以保证每个成功持久化的数据结构都是一份完整的结算数据快照，每个成功持久化的数据结构都可以作为结算数据恢复的恢复点。

其中，结算数据持久化(存储)过程为：服务器100包括的持久化模块会每隔一段时间进行数据持久化工作，首先从待提交事务队列(结算处理后的复制结算数据)获取待提交事务，每个事务都包含四种数据结构：第一，多个广告主某个时间点的数据更新版本；第二，队列在某个时间点的数据更新版本；第三，总体数据的版本号信息；第四，当前版本的版本号信息。

进一步地，持久化步骤也分为四步：第一步，先持久化多个广告主数据更新版本到集中式内存；第二步，持久化队列更新版本数据到集中式内存；第三步，持久化总体版本号数据到集中式内存；第四步，持久化当前版本数据到集中式内存。

以上持久化步骤是一个事务过程，即任何一步出现失败，则意味着本次事务执行失败，可以中途退出后续持久化；即使出现失败，也不会影响已有数据，因为数据恢复时依据当前版本current_version确定版本内容。

需要说明的是，在步骤S230之后，本申请实施例提供的数据处理方法还可以包括对漏扣费情况进行处理的步骤。因此，在图2的基础上，图7为本申请实施例提供的另一种数据处理方法的流程示意图，参见图7，数据处理方法还可以包括：

步骤S250，判断结算处理结果是否包括每个日志的结果。

在本申请实施例中，在结算处理结果包括每个日志的结果时，判定结算处理无误；在结算处理结果没有包括每个日志的结果时，判定结算处理出错，执行步骤S260。

步骤S260，获取待处理结算数据，对待处理结算数据进行结算处理，得到新的结算处理结果。

详细地，广告结算服务重启时，首先可以根据current_version查找最后一个成功更新的版本，获取总体数据版本号，然后根据版本号，获取该版本号下的结算数据。同时，可以根据版本号获取所有广告主在该版本号下的数据，当这些数据获取完毕后，即完成所有广告主账户信息加载和曝光日志队列信息。即使在上面事务提交时，某个版本的某条数据提交失败，只是新增的版本信息提交失败，并不会影响已有版本信息，而且只要current_version没有被破坏，就可以根据该版本号获取完整的结算快照信息。

需要说明的是，在步骤S230之后，本申请实施例提供的数据处理方法还可以包括对重复扣费情况进行处理的步骤。因此，在图2的基础上，图8为本申请实施例提供的另一种数据处理方法的流程示意图，参见图8，数据处理方法还可以包括：

步骤S270，判断结算处理结果是否重复。

在本申请实施例中，在判断结算处理结果没有重复时，判定结算处理无误；在判断结算处理结果重复时，判定结算处理出错，执行步骤S280。

步骤S280，获取待处理结算数据，对待处理结算数据进行结算处理，得到新的结算处理结果。

详细地，步骤S280的具体步骤可以参照前文对步骤S260的具体描述，在此不再赘述。

结合图9，本申请实施例还提供了一种数据处理装置900，该数据处理装置900实现的功能对应上述方法执行的步骤。该数据处理装置900可以理解为上述服务器100的处理器，也可以理解为独立于上述服务器100或处理器之外的在服务器100控制下实现本申请功能的组件。其中，数据处理装置900可以包括数据获取模块910、复制处理模块920和结算处理模块930。

数据获取模块910，用于响应于结算处理信号，获取待处理结算数据。在本申请实施例中，数据获取模块910可以用于执行图2所示的步骤S210，关于数据获取模块910的相关内容可以参照前文对步骤S210的描述。

复制处理模块920，用于对待处理结算数据进行复制处理，得到预设格式的复制结算数据。在本申请实施例中，复制处理模块920可以用于执行图2所示的步骤S220，关于复制处理模块920的相关内容可以参照前文对步骤S220的描述。

结算处理模块930，用于对复制结算数据进行结算处理，得到结算处理结果。在本申请实施例中，结算处理模块930可以用于执行图2所示的步骤S230，关于结算处理模块930的相关内容可以参照前文对步骤S230的描述。

此外，本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，该计算机程序被处理器运行时执行上述数据处理方法的步骤。

综上所述，本申请实施例所提供的数据处理方法的计算机程序产品，包括存储了程序代码的计算机可读存储介质，程序代码包括的指令可用于执行上述方法实施例中的数据处理方法的步骤，具体可参见上述方法实施例，在此不再赘述。

本申请实施例提供的数据处理方法和装置、服务器100及存储介质，通过对待处理结算数据进行复制处理得到预设格式的复制结算数据，对复制结算数据进行结算处理，得到结算处理结果，实现了对复制后的预设格式的复制结算数据进行结算处理，改善了现有技术中直接根据原始的结算数据进行更新操作可能会出现部分成功部分失败的结果，所导致的结算处理的可靠性低的问题。

在本申请所提供的实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

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

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

以上仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种数据处理方法，其特征在于，包括：

响应于结算处理信号，获取待处理结算数据；

对所述待处理结算数据进行复制处理，得到预设格式的复制结算数据；

对所述复制结算数据进行结算处理，得到结算处理结果。

2.如权利要求1所述的数据处理方法，其特征在于，所述复制结算数据包括多个日志，所述对所述复制结算数据进行结算处理，得到结算处理结果的步骤，包括：

对所述多个日志进行聚合处理；

对聚合处理后的复制结算数据进行结算处理，得到结算处理结果。

3.如权利要求2所述的数据处理方法，其特征在于，所述日志包括结算主体，所述对所述多个日志进行聚合处理的步骤，包括：

获取每一个日志的结算主体；

根据所述结算主体对所述多个日志进行聚合处理。

4.如权利要求3所述的数据处理方法，其特征在于，所述对聚合处理后的复制结算数据进行结算处理，得到结算处理结果的步骤，包括：

针对每一个结算主体，获取该结算主体的预设处理信息；

根据该结算主体的预设处理信息对属于该结算主体的复制结算数据进行结算处理，得到结算处理结果。

5.如权利要求1所述的数据处理方法，其特征在于，所述数据处理方法还包括：

对结算处理后的复制结算数据进行存储。

6.如权利要求1所述的数据处理方法，其特征在于，所述数据处理方法还包括：

判断所述结算处理结果是否包括每个日志的结果；

若否，则获取所述待处理结算数据，对所述待处理结算数据进行结算处理，得到新的结算处理结果。

7.如权利要求1所述的数据处理方法，其特征在于，所述数据处理方法还包括：

判断所述结算处理结果是否重复；

若是，则获取所述待处理结算数据，对所述待处理结算数据进行结算处理，得到新的结算处理结果。

8.一种数据处理装置，其特征在于，包括：

数据获取模块，用于响应于结算处理信号，获取待处理结算数据；

复制处理模块，用于对所述待处理结算数据进行复制处理，得到预设格式的复制结算数据；

结算处理模块，用于对所述复制结算数据进行结算处理，得到结算处理结果。

9.一种服务器，其特征在于，包括存储器和处理器，所述处理器用于执行所述存储器中存储的可执行的计算机程序，以实现权利要求1-7任意一项所述的数据处理方法。

10.一种存储介质，其特征在于，其上存储有计算机程序，该程序被执行时实现权利要求1-7任意一项所述数据处理方法的步骤。

Images