广告结算方法、装置及设备与流程

本申请涉及广告结算技术领域，具体而言，涉及一种广告结算方法、装置及设备。

背景技术：

广告曝光时，会产生广告曝光日志，广告曝光日志包含有广告主的信息。在实际的广告曝光过程中，各个广告主的广告曝光日志按照广告的曝光时间存储在同一个队列中，在结算时，按照广告曝光时间的先后顺序依次取出一个批次的广告日志信息，然后根据该批次广告曝光日志对各个广告主的广告金额进行逐个结算。

在现有的这种结算方式中，如果某一批次的广告在结算过程中发生错误，需要重新计算时，一般采用两种方式，其中一种方式是采用最近一次广告结算的结算起点作为新的结算起点，然后根据结算起点后的一批广告日志进行下一次结算。另一种方式是获取最近一次结算的终点，然后以该终点为新的结算起点进行下一次结算。第一种结算方式中，由于新的结算起点与上一次结算的结算起点相同，因此，在下一次结算时，会对已经结算的广告重复结算，造成多扣费的问题。而在第二种结算方式中，由于在结算时同一个广告主的广告日志是一起结算的，第二种方式中，可能会存在新的结算起点之前的曝光日志并未进行结算，从而导致漏扣费的问题。

技术实现要素：

为了克服现有技术中的上述不足，本申请的目的在于提供一种广告结算方法，应用于预先存储有快照文件的广告结算系统，所述快照文件包括多个账户的已结算信息，所述已结算信息包括每个所述账户的可消费金额以及第一结算序号，所述第一结算序号为所有成功结算的曝光日志中、与该账户对应的曝光日志在第一队列中最大的序号；曝光日志为广告被成功下载至客户端中的记录信息，所述方法包括：

获取待结算的曝光日志对应的待结算数据，所述待结算数据包括与每条所述曝光日志分别对应的待结算账户、需要扣除的费用信息以及该曝光日志在第一队列中的队列序号；

从所述快照文件中获取每个所述待结算账户的所述已结算信息；

根据所述待结算数据以及所述待结算账户的已结算信息依次对每个所述待结算账户进行结算，得到每个所述待结算账户的结算结果，所述结算结果包括该次结算结束后该待结算账户对应的已结算信息；

根据所有待结算账户的所述结算结果判断是否所有的待结算账户均结算成功；

如果所有所述待结算账户均结算成功，则根据所述结算结果更新所述快照文件。

可选地，所述方法还包括：

如果存在没有结算成功的待结算账户，则重新执行获取待结算的曝光日志对应的待结算数据；从所述快照文件中获取每个所述待结算账户的所述已结算信息；根据所述待结算数据以及所述待结算账户的已结算信息依次对每个所述待结算账户进行结算，得到每个所述待结算账户的结算结果；根据所有待结算账户的所述结算结果判断是否所有的待结算账户均结算成功。

可选地，所述根据所述待结算数据以及所述待结算账户的已结算信息依次对每个所述待结算账户进行结算，直至结算结束得到每个所述待结算账户的结算结果的步骤包括：

选取一未进行结算的待结算账户作为目标待结算账户进行结算操作，其中所述结算操作包括：

从待结算的曝光日志中，获取所述目标待结算账户对应的曝光日志；

根据所述目标待结算账户对应的曝光日志及该曝光日志的费用信息计算所述目标待结算账户的需扣除金额；

获取待结算的曝光日志中，与所述目标待结算账户对应的曝光日志在第一队列中的最大序号作为第二结算序号；

根据所述需扣除金额以及所述第二结算序号更新该待结算账户的已结算信息；

以结算结束时该待结算账户对应的已结算信息作为该待结算账户的结算结果；

重新选取一未进行结算的待结算账户作为新的目标待结算账户并进行结算操作。

可选地，所述根据所有待结算账户的所述结算结果判断是否所有的待结算账户均结算成功的步骤包括：

分别判断每个待结算账户的可消费金额及第一结算序号是否更新；

如果每个待结算账户的可消费金额已经更新，且第一结算序号已经更新，则判定为所有的待结算账户均结算成功；

如果存在待结算账户的可消费金额未更新，或者第一结算序号未更新，则判定为存在未结算成功的待结算账户。

可选地，所述根据所述结算结果更新所述快照文件的步骤包括：

将所有所述待结算账户的所述结算结果存储至第二队列；

根据第二队列中的每个待结算账户的所述结算结果更新所述快照文件。

可选地，所述方法还包括，

根据所述快照文件中的各个账户的可消费金额进行广告展示。

本申请的另一目的在于提供一种广告结算装置，应用于预先存储有快照文件的广告结算系统，所述快照文件包括多个账户的已结算信息，所述已结算信息包括每个所述账户的可消费金额以及第一结算序号，所述第一结算序号为所有成功结算的曝光日志中、与该账户对应的曝光日志在第一队列中最大的序号；曝光日志为广告被成功下载至客户端中的记录信息，所述装置包括第一获取模块、第二获取模块、结算模块和更新模块；

所述第一获取模块用于获取待结算的曝光日志对应的待结算数据，所述待结算数据包括与每条所述曝光日志分别对应的待结算账户、需要扣除的费用信息以及该曝光日志在第一队列中的队列序号；

所述第二获取模块用于从所述快照文件中获取每个所述待结算账户的所述已结算信息；

所述结算模块用于根据所述待结算数据以及所述待结算账户的已结算信息依次对每个所述待结算账户进行结算，得到每个所述待结算账户的结算结果，所述结算结果包括该次结算结束后该待结算账户对应的已结算信息；

所述更新模块用于根据所有待结算账户的所述结算结果判断是否所有的待结算账户均结算成功；以及

在所有所述待结算账户均结算成功时，根据所述结算结果更新所述快照文件。

可选地，所述更新模块还用于在存在没有结算成功的待结算账户时，使所述广告结算装置重新执行获取待结算的曝光日志对应的待结算数据；从所述快照文件中获取每个所述待结算账户的所述已结算信息；根据所述待结算数据以及所述待结算账户的已结算信息依次对每个所述待结算账户进行结算，得到每个所述待结算账户的结算结果；根据所有待结算账户的所述结算结果判断是否所有的待结算账户均结算成功。

可选地，所述结算模块用于根据所述待结算数据以及所述待结算账户的已结算信息依次对每个所述待结算账户进行结算，得到每个所述待结算账户的结算结果的步骤包括：

选取一未进行结算的待结算账户作为目标待结算账户进行结算操作，其中所述结算操作包括：从待结算的曝光日志中，获取所述目标该待结算账户对应的曝光日志；

根据所述目标待结算账户对应的曝光日志及该曝光日志的费用信息计算所述目标待结算账户的需扣除金额；

获取待结算的曝光日志中，与所述目标待结算账户对应的曝光日志在第一队列中的最大序号作为第二结算序号；

根据所述需扣除金额以及所述第二结算序号更新该待结算账户的已结算信息；

以结算结束时该待结算账户对应的已结算信息作为该待结算账户的结算结果；

重新选取一未进行结算的待结算账户作为新的目标待结算账户并进行结算操作。

本申请的另一目的在于提供一种广告结算设备，所述广告结算设备包括通信连接的存储器和处理器，所述存储器中存储有可执行程序，所述处理器执行所述程序，实现如以上任一项所述方法的步骤。

相对于现有技术而言，本申请具有以下有益效果：

本申请实施例公开的广告结算方法、装置及设备中，在进行曝光日志结算时，首先获取待结算的曝光日志对应的待结算数据以及待结算账户，从快照文件中获取各个待结算账户的已结算信息，然后根据待结算数据以及各个待结算账户的已结算信息获得各个账户的结算结果，接着再根据各个账户的结算结果判断是否所有的待结算账户均结算成功，最后所有的待结算账户均结算成功的情况下，根据各个待结算账户的结算结果更新快照文件。由于每次获取来进行结算的基础都是快照文件中的已结算信息，而快照文件中的已结算信息又是每次所有待结算账户成功结算后更新过的数据，因此，本申请能够大幅避免漏扣费和多扣费的问题，同时，也能够进一步避免由于结算延时造成的超投现象。

附图说明

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

图1为本申请实施例提供的广告结算设备的结构示意框图；

图2为本申请实施例提供的广告结算方法的流程示意图一；

图3为本申请实施例提供的广告结算设备的流程示意图二；

图4为本申请实施例提供的广告结算方法的流程示意图三；

图5为本申请实施例提供的广告结算方法的流程示意图四；

图6为本申请实施例提供的广告结算装置的结构示意图。

图标：100-广告结算设备；110-广告结算装置；111-第一获取模块；112-第二获取模块；113-结算模块；114-更新模块；120-存储器；130-处理器。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

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

在广告系统的广告引擎中，会存在展示广告的服务，如果展示的广告被成功下载至客户端中，那么则称为广告曝光，而对于每次广告的曝光，会产生对应的曝光日志，因此可以根据这个曝光日志对广告进行结算。目前比较大的广告系统日志量一般在亿级、十亿甚至百亿级别，为获得比较高的结算性能，降低资源消耗，一般采用批量处理的方式进行曝光日志结算。也就是说每次结算时会对一段时间范围内产生的多条广告的曝光日志进行结算。这些曝光日志一般使用消息队列存放，也就是说，曝光日志是按照生成的先后顺序存储在消息队列中的。而曝光日志一般是以广告id或者广告主id区分的，批量处理时，同一批曝光日志很有可能是属于不同广告主展示的广告，所以只有这批广告日志结算完成并扣除相应广告主可消费金额之后，这批广告的曝光日志才算结算完成，即一批曝光日志的结算以及相应帐户可消费金额的扣除是一个事务操作。而实际中，为方便后续查询和更新操作，一般会采用关系型数据库存储广告主可消费金额，以mysql数据库为例，每个账户的曝光日志结算完后，其费用信息和结算的位置信息(已经结算的曝光日志在消息队列中的序号)便单独存储进数据库，因此，多条账户可消费金额更新操作很难作为一个事务操作。这种方式中一旦广告结算设备100在只有部分广告主已结算信息更新成功时出现重启情况，则该设备重启之后会从数据库获取重启之前曝光日志的最新位置(该批次曝光日志中，所有已经结算的曝光日志在消息队列中的最大序号)，但是由于重启之前的更新操作不是一个事务操作，也就是说，各个广告主对应的信息是在该广告主对应的曝光日志结算成功后便进行更新，所以最后一次批处理涉及的账户中，只有部分账户的费用信息和位置信息更新成功，因此，从数据库中，很难找到正确的数据恢复点。

为了方便理解，以下结合实际的例子来对现有技术进行阐述：在包含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]，在结算时先按照广告主聚合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>，其中，total_pv是聚合结果中，属于同一个广告主的曝光日志的数量，total_cost为聚合结果中，同一个广告主的对应的需扣除金额，cost1代表广告主owner1每条曝光日志对应的费用信息，cost2代表广告主owner2每条曝光日志对应的费用信息，cost3代表广告主owner3每条曝光日志对应的费用信息。然后对相应广告主的帐户进行扣费，再提交账户扣费之后的可消费金额以及更新每个账户时，结算成功的最后一条曝光日志的位置。假设在提交账户的可消费金额的步骤出现意外(例如出现重启操作)，那么就出现一部分账户的可消费金额更新成功，一部分账户的可消费金额更新不成功的问题，以上述10条曝光日志为例，假设在owner3账户的可消费金额以及结算成功的最后一条曝光日志的位置更新成功之后，owner1和owner2对应账户更新成功之前出现意外，则重启之后，结算数据恢复模块会根据owner1、owner2、owner3三者中，最后结算的曝光日志位置，比较得出重启的曝光日志结算起始位置。具体地，获取起始位置有两种选择：其一是选择上次结算的最新的位置作为此次重启的曝光日志结算起始位置，即order＝5的位置开始曝光日志结算，这种方式，由于在重启之前的最后一次结算中，并没有将order＝1的owner1曝光日志和order＝2的owner2的已结算信息更新成功，因此owner1漏计费order＝1的曝光日志，owner2漏计费order＝2的曝光日志，也就是会出现曝光日志丢失问题；其二是选择上次结算的起始位置作为此次重启的曝光日志结算起始位置，即从order＝1开始曝光日志结算，由于有order＝1后的一些曝光日志已经结算过，因此会出现重复计费的情况。目前采用广告结算和广告报表服务相互对比以弥补重复计费或者曝光日志丢失的问题，但是由于广告报表服务一般是非实时离线数据统计，所以重启引发的校正工作就存在一定的滞后性，因此，同样可能会因此出现账户金额超投现象(曝光日志丢失造成需要引擎更多的曝光广告)或者多扣现象(同一曝光日志重复计费)。

请参照图1，图1是本申请实施例所述的广告结算设备100的结构示意框图，所述广告结算设备100可以应用于解决至少一个上述问题。所述广告结算设备100可以是计算机或者服务器等具有数据处理功能的设备。所述广告结算设备100包括广告结算装置110，存储器120和处理器130，存储、和处理器130相互之间直接或间接电性连接，用于实现数据交互。例如，这些元件相互之间可通过一条或多条通讯总线或信号线实现电性连接。所述广告结算装置110包括至少一个可以软件或固件(firmware)的形式存储于所述存储器120中或固化在所述广告结算设备100的操作系统(operatingsystem，os)中的软件功能模块。所述处理器130用于执行所述存储器120中存储的可执行模块，例如所述广告结算装置110所包括的软件功能模块及计算机程序等。

其中，所述存储器120可以是，但不限于，随机存取存储器120(randomaccessmemory，ram)，只读存储器120(readonlymemory，rom)，可编程只读存储器120(programmableread-onlymemory，prom)，可擦除只读存储器120(erasableprogrammableread-onlymemory，eprom)，电可擦除只读存储器120(electricerasableprogrammableread-onlymemory，eeprom)等。其中，存储器120用于存储程序，所述处理器130在接收到执行指令后，执行所述程序。

所述处理器130可能是一种集成电路芯片，具有信号的处理能力。上述的处理器130可以是通用处理器130，包括中央处理器130(centralprocessingunit，cpu)、网络处理器130(networkprocessor，np)等；还可以是数字信号处理器130(dsp)、专用集成电路(asic)、现场可编程门阵列(fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器130可以是微处理器130或者该处理器130也可以是任何常规的处理器130等。

本实施例提供一种广告结算方法，应用于预先存储有快照文件的广告结算系统，所述广告结算系统中包括广告结算设备100，所述快照文件包括多个账户的已结算信息，所述已结算信息包括每个所述账户的可消费金额以及第一结算序号，所述第一结算序号为所有成功结算的曝光日志中，与该账户对应的曝光日志在第一队列中最大的序号；每个账户的已结算信息与该账户对应识别信息也就是说，快照文件包括每个账户的识别信息、可消费金额和第一结算序号。其中，同一账户的识别信息、可消费金额和第一结算序号对应存储，这样，根据账户的识别信息便可以查找到与该账户对应的可消费金额和第一结算序号。每个曝光日志为广告被成功下载至客户端中的记录信息。可消费金额为每个账户可以用于支付广告费用的金额，可消费金额可以包括初始金额和已扣除金额。本实施例中的快照文件可以存储在持久化存储区。

进一步地，快照文件中，还可以包括每个账户的有效时间信息，即可以对账户对应的广告进行曝光的时间。

请参见图2，图2是本申请实施例提供的广告结算方法的流程示意图，所述方法包括步骤s110-步骤s150。

步骤s110，获取待结算的曝光日志对应的待结算数据。

其中，所述待结算数据包括与每条所述曝光日志分别对应的待结算账户、需要扣除的费用信息以及该曝光日志在第一队列中的队列序号。待结算账户通过用于识别账户的识别信息表示，识别信息与账户具有对应关系，相同的识别信息与同一账户对应。

本实施例用于获取一批待结算的曝光日志，并根据待结算的曝光日志获取与该批次待结算的曝光日志对应的待结算账户。具体地，可以通过获取该批待结算的曝光日志中的各种类型的识别信息，然后根据识别信息确定待结算账户。

为方便理解，以下结合实例对本实施例进行详细的阐述。

待结算一批次的曝光日志的数量有10条，这10条曝光日志中，总共存在3个识别信息，也就是说，这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]，曝光日志的费用信息依次为[10，20，30，30，10，10，20，20，20，10]。其中，所述待结算数据包括各个待结算的曝光日志的识别信息、在第一队列中的序号和费用信息。

步骤s120，从所述快照文件中获取每个所述待结算账户的所述已结算信息。

本实施例用于获取与待结算账户对应的已结算信息。

可选地，在获取与待结算账户对应的已结算信息时，将所述快照文件加载到广告结算设备100的内存中，然后根据各个待结算账户的识别信息获取对应的已结算信息。

仍然以上述10条曝光日志为例，由于已经得知这10条曝光日志中待结算账户的识别信息，因此，本实施例中，便可以根据所述识别信息获取每个待结算账户的已结算信息。已结算信息可以包括时间戳，已结算信息包括时间戳时，待结算账户owner1的已结算信息为[owner1，1000，200，[{queue1，990}]，1543992784]，待结算账户owner2的已结算信息为[owner2，2000，300，[{queue1，997}]，1543992784]，待结算账户owner3的已结算信息为[owner3，1500，150，[{queue1，999}]，1543992784]。每个待结算账户的已结算信息中的各项依次对应代表：识别信息、初始金额、已扣除金额、队列标识、第一结算序号、时间戳。

步骤s130，获取每个待结算账户的结算结果。

具体地，本实施例中，根据所述待结算数据以及所述待结算账户的已结算信息依次对每个所述待结算账户进行结算，得到每个所述待结算账户的结算结果。由于每个待结算账户相互之间并不会产生影响，因此，本实施例中，可以单独获取各个待结算账户的已结算信息。

也就是说，本实施例用于选取一未进行结算的待结算账户作为目标待结算账户进行结算操作，以获得该待结算账户的结算结果。该步骤会一直执行直至满足预先设定的结束条件，即预先设定的用于结束对所有待结算账户结算的条件。在满足预先设定的结束条件后，如果存在未结算的待结算账户，那么，则根据这些未结算的待结算账户对应的结算信息获得结算结果。这样，每个待结算账户对应的结算结果都是根据该批次曝光日志结算的结束条件来获得的。那么就可以据此来判断所有待结算账户的结算状态。

本实施例中，在获取已结算信息时，可以是在检测到当前对当前批次的所有曝光日志的结算过程结束时获取。此处，结算过程结束可以是所有账户的结算操作都已结算完成。也可以是系统故障、广告结算设备100重启等导致的对所有待结算账户的结算过程终止的情况，也就是说，仅有一部分账户的曝光日志结算过程完成，而另一部分待结算账户的结算并没有完成的情况。

请参照图3，本实施例中，可选地，步骤s130可以包括对每个待结算账户进行步骤s131-步骤s136。

步骤s131，选取一未进行结算的待结算账户作为目标待结算账户进行结算操作。

本实施例用于确定进行结算的待结算账户。

步骤s132，从待结算的曝光日志中，获取所述目标待结算账户对应的曝光日志。

具体地，对于所述目标待结算账户，从待结算的曝光日志中，获取所述目标待结算账户对应的曝光日志。

本实施例用于获取当前结算的所述待结算账户在待结算的曝光日志中，对应的曝光日志。

步骤s133，计算所述目标待结算账户的需扣除金额。

具体地，根据所述目标待结算账户对应的曝光日志及该曝光日志的费用信息计算该目标待结算账户的需扣除金额。

步骤s134，获取所述目标待结算账户的第二结算序号。

具体地，获取待结算的曝光日志中，与所述目标待结算账户对应的曝光日志在第一队列中的最大序号作为第二结算序号

步骤s135，根据所述需扣除金额以及所述第二结算序号更新该待结算账户的已结算信息。

本实施例用于获取已经结算的待结算账户的新的已结算信息。

步骤s136，以结算结束时该待结算账户对应的已结算信息作为该待结算账户的结算结果。

具体地，以结算结束时所述目标待结算账户对应的已结算信息作为该待结算账户的结算结果。

在步骤s131-步骤s136后，如果没有满足预先设定的结束条件，则重新执行步骤s131-步骤s136。

如果满足预先设定的结束条件，那么则将未结算的待结算账户的已结算信息作为该待结算账户的结算结果。

本实施例用于获取结算结束后各个待结算账户的已结算信息组成该待结算账户的结算结果，由于结算结束时，存在待结算账户的已结算信息没有变化的情况，因此，本实施例中，待结算账户的结算结果中，所包含的已结算信息就可能是没有更新的已结算信息。

本实施例用于对待结算的曝光日志的待结算数据进行聚合，根据待已结算信息将属于同一账户的曝光日志的数量、需扣除金额和第二结算序号，获得各个待结算账户的结算结果。当然，聚合结果中还可以包括曝光日志所在队列的队列标识。

例如，在已经获得上述10条待结算的日志的待结算数据的情况下，对上述10条待结算的曝光日志按照账户进行聚合，可以得到的聚合结果为：[owner1，cost＝40，queue1，max_order＝1010]，[owner2，cost＝80，queue1，max_order＝1009]，[owner3，cost＝60，queue1，max_order＝1004]，每个聚合结果中的各项依次代表：识别信息、需扣除金额、队列标识、第二结算序号。其中，需扣除金额为同一账户对应曝光日志的费用信息之和。

具体地，可以先复制一份待结算数据的旧的已结算信息，也就是从快照文件中获取的已结算信息，然后对复制的已结算信息进行步骤s131-步骤s134的更新操作。

本实施例中，可选地，所述可消费金额包括账户的初始金额及已扣除金额，根据所述需扣除金额以及所述第二结算序号更新该待结算账户的已结算信息时，可以先根据需扣除金额与所述已扣除金额计算出该待结算账户的新的已扣除金额，便可得到该待结算账户的新的可消费金额，新的可消费金额包括初始金额和新的已扣除金额。然后再将该待结算账户已有的已结算信息中的可消费金额替换为新的可消费金额、第一结算序号替换为第二结算序号。

在对各个待结算账户进行结算后，内存中与待结算账户对应的新的已结算信息便会发生更改，变为新的已结算信息。故本实施例中，可以根据待结算账户的已结算信息判断该待结算账户是否结算成功。

本实施例用于对待结算账户的第一结算序号和已扣除金额进行更新。以上述三个待结算账户为例，由于owner1的需扣除金额为40，第二结算序号为1010，故owner1的新的已扣除金额为owner1的旧的已扣除金额200与需扣除金额40之和，也就是240，owner1的新的第一结算序号为1010。同理可得owner2的新的已扣除金额为380，owner2的新的第一结算序号为1009，owner3的新的已扣除金额为210，owner3的新的第一结算序号为1004。当已结算信息中包含时间戳时，各个账户的结算结果分别为：[owner1，1000，240，[{queue1，1010}]，1543992784]，[owner2，2000，380，[{queue1，1009}]，1543992784]，[owner3，1500，210，[{queue1，1004}]，1543992784]。

请继续参照图2，步骤s140，根据所有待结算账户的所述结算结果判断是否所有的待结算账户均结算成功。

请参照图4，本实施例中，可选地，所述步骤s140包括步骤s141-步骤s143。

步骤s141，分别判断每个待结算账户的可消费金额及第一结算序号是否更新。

步骤s142，如果每个待结算账户的可消费金额已经更新，且第一结算序号已经更新，则判定为所有的待结算账户均结算成功。

步骤s143，如果存在待结算账户的可消费金额未更新，或者第一结算序号未更新，则判定为存在未结算成功的待结算账户。

本实施例用于判断是否所有待结算账户的均已经结算成功。

请继续参照图2，步骤s150，如果所有所述待结算账户均结算成功，则根据所述结算结果更新所述快照文件。

请参照图5，步骤s150包括步骤s151-步骤s152。

步骤s151，存储所有所述待结算账户的所述结算结果至第二队列。

步骤s152，根据第二队列中的每个待结算账户的所述结算结果更新所述快照文件。

本实施例用于在所有待结算账户均结算成功时，对快照文件中存储的待结算账户的已结算信息进行更新。

本实施例用于在待结算的曝光日志对应的待结算账户都结算成功后，再将快照文件中该待结算账户的已结算信息更新为该待结算账户对应的新的已结算信息。如此，快照文件中就既包括已经结算的待结算账户的新的已结算信息，也包括该批次未结算的其他账户的已结算信息。也就是说，本实施例中，可以将所有账户的已结算信息都保存到快照文件中，因此可以保证每个成功持久化的快照文件都是一份完整的结算数据文件，每个成功持久化的快照文件都可以作为数据库恢复的恢复点。具体地，可以将每批次结算的曝光日志的对应账户的新的已结算信息作为一个整体的结算文件通过第二队列存放，然后按照预设的时间间隔，从第二队列读取这些结算文件来更新快照文件。

如果结算失败，例如，广告结算设备100因为故障重启时，则重复执行步骤s110-步骤s140。当然，如果内存中从快照文件中获取的已结算信息仍然存在，那么则可以根据内存中的该已结算信息执行步骤s110、步骤s130和步骤s140。

在不做特殊说明的情况下，本实施例中所述的快照文件，均是指相对于方案中获取快照文件时刻而言，最近产生的快照文件。而对比该快照文件产生时间更早的快照文件，可以根据需要进行删除、复制或者移动等操作。在更新快照文件时，可以先将原有的快照文件进行备份，然后再进行更新操作。本实施例中，可以对已经更新的快照文件设置识别号，从而在需要获取相应的快照文件时，可以根据该识别号来获取。

当结算过程出现异常(异常结算)，进行重新结算时，由于用于结算的已结算信息是从快照文件中获得，而快照文件中所保存的已结算信息是最近一次成功结算后，各个账户的已结算信息，就相当于把结算状态恢复到异常结算前的状态，因此，并不会再出现多扣费或者少扣费的现象。

本实施例中，还可以根据所述快照文件中的各个账户的可消费金额进行广告展示。

例如，在账户的可消费金额耗完时，不进行账户相应的广告的展示。如此，便可以根据账户的可消费金额展示相应的广告。

请参照图6，本申请实施例还提供一种广告结算装置110，应用于预先存储有快照文件的广告结算系统，所述快照文件包括多个账户的已结算信息，所述已结算信息包括每个所述账户的可消费金额以及第一结算序号，所述第一结算序号为所有成功结算的曝光日志中，与该账户对应的曝光日志在第一队列中最大的序号；曝光日志为广告被成功下载至客户端中的记录信息，所述装置包括第一获取模块111、第二获取模块112、结算模块113和更新模块114；所述广告结算装置110包括一个可以软件或固件的形式存储于所述存储器120中或固化在所述图像处理设备的操作系统(operatingsystem，os)中的软件功能模块。

所述第一获取模块111获取待结算的曝光日志对应的待结算数据，所述待结算数据包括与每条所述曝光日志分别对应的待结算账户、需要扣除的费用信息以及该曝光日志在第一队列中的队列序号。

本实施例中的第一获取模块111用于执行步骤s110，关于所述第一获取模块111的具体描述可参照对所述步骤s110的描述。

所述第二获取模块112用于从所述快照文件中获取每个所述待结算账户的所述已结算信息。

本实施例中的第二获取模块112用于执行步骤s120，关于所述第二获取模块112的具体描述可参照对所述步骤s120的描述。

所述结算模块113用于根据所述待结算数据以及所述待结算账户的已结算信息依次对每个所述待结算账户进行结算，得到每个所述待结算账户的结算结果，所述结算结果包括该次结算结束后该待结算账户对应的已结算信息。

本实施例中的结算模块113用于执行步骤s130，关于所述结算模块113的具体描述可参照对所述步骤s130的描述。

所述更新模块114用于根据所有待结算账户的所述结算结果判断是否所有的待结算账户均结算成功，以及在所有所述待结算账户均结算成功时，根据所述结算结果更新所述快照文件。

本实施例中的更新模块114用于执行步骤s140-步骤s150，关于所述更新模块114的具体描述可参照对所述步骤s140-步骤s150的描述。

所述更新模块114还用于在存在没有结算成功的待结算账户时，所述广告结算装置110重新执行获取待结算的曝光日志对应的待结算数据；从所述快照文件中获取每个所述待结算账户的所述已结算信息；根据所述待结算数据以及所述待结算账户的已结算信息依次对每个所述待结算账户进行结算，得到每个所述待结算账户的结算结果；根据所有待结算账户的所述结算结果判断是否所有的待结算账户均结算成功。

本实施例中的更新模块114用于执行步骤s140-步骤s150，关于所述更新模块114的具体描述可参照对所述步骤s140-步骤s150的描述。

可选地，所述结算模块113用于根据所述待结算数据以及所述待结算账户的已结算信息依次对每个所述待结算账户进行结算，得到每个所述待结算账户的结算结果的步骤包括：

选取一未进行结算的待结算账户作为目标待结算账户进行结算操作，其中所述结算操作包括：从待结算的曝光日志中，获取所述目标该待结算账户对应的曝光日志。

根据所述目标待结算账户对应的曝光日志及该曝光日志的费用信息计算所述目标待结算账户的需扣除金额。

获取待结算的曝光日志中，与所述目标待结算账户对应的曝光日志在第一队列中的最大序号作为第二结算序号。

根据所述需扣除金额以及所述第二结算序号更新该待结算账户的已结算信息。

以结算结束时该待结算账户对应的已结算信息作为该待结算账户的结算结果。

重新选取一未进行结算的待结算账户作为新的目标待结算账户并进行结算操作。本实施例中的更新模块114具体用于执行步骤s131-步骤s134，关于所述更新模块114的具体描述可参照对所述步骤s131-步骤s134的描述。

综上所述，本申请实施例公开的广告结算方法、装置及设备中，在进行曝光日志结算时，首先获取待结算的曝光日志对应的待结算数据以及待结算账户，从快照文件中获取各个待结算账户的已结算信息，然后根据待结算数据以及各个待结算账户的已结算信息获得各个账户的结算结果，接着再根据各个账户的结算结果判断是否所有的待结算账户均结算成功，最后所有的待结算账户均结算成功的情况下，根据各个待结算账户的结算结果更新快照文件。由于每次获取来进行结算的基础都是快照文件中的已结算信息，而快照文件中的已结算信息又是每次所有待结算账户成功结算后更新过的数据，因此，本申请能够大幅避免漏扣费和多扣费的问题，同时，也能够进一步避免由于结算延时造成的超投现象。同时，也能够进一步避免由于结算延时造成的超投现象。

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