发明内容
本申请实施例的目的是提供一种数据处理方法及装置,解决现有技术不能兼顾网络节点关联的资源数据的变更操作的时效性和准确性的问题。
为解决上述技术问题,本申请实施例提供的数据处理方法及装置是这样实现的:
一种数据处理方法,包括:
当在第一预设时长内接收到以小于所述第一预设时长的第二预设时长为间隔的第一提取任务时,从预先记录的关于网络节点的事务明细信息队列中,提取在接收到该第一提取任务的时刻之前的提取时长内发生的事务明细信息;
根据在所述提取时长内发生的所述事务明细信息,确定该网络节点关联的资源数据在所述提取时长内的第一变更数值,并对该网络节点关联的资源数据进行与所述第一变更数值对应的变更;
当接收到第二提取任务时,从预先记录的关于网络节点的事务明细信息队列中,提取在所述第一预设时长内发生的事务明细信息;
根据在所述第一预设时长内发生的所述事务明细信息,确定该网络节点关联的资源数据在所述第一预设时长内的第二变更数值;
在所述第二变更数值与在所述第一预设时长内确定的各个第一变更数值的和值不一致时,确定所述第二变更数值与所述和值之间的差值,对所述网络节点关联的资源数据进行与所述差值对应的变更。
一种数据处理方法,包括:
当在第一预设时长内接收到以小于所述第一预设时长的第二预设时长为间隔的第一汇总记账任务时,从预先记录的关于账户的记账明细信息队列中,提取在接收到该第一汇总记账任务的时刻之前的提取时长内发生的记账明细信息;
根据在所述提取时长内发生的所述记账明细信息,确定该账户的余额在所述提取时长内的第一变更金额,并对该账户的余额进行与所述第一变更金额对应的变更;
当接收到第二汇总记账任务时,从预先记录的关于账户的记账明细信息队列中,提取在所述第一预设时长内发生的记账明细信息;
根据在所述第一预设时长内发生的所述记账明细信息,确定该账户的余额在所述第一预设时长内的第二变更金额;
在所述第二变更金额与在所述第一预设时长内确定的各个第一变更金额的和值不一致时,确定所述第二变更金额与所述和值之间的差值,对所述账户的余额进行与所述差值对应的变更。
一种数据处理装置,包括:
第一提取单元,用于在第一预设时长内接收到以小于所述第一预设时长的第二预设时长为间隔的第一提取任务时,从预先记录的关于网络节点的事务明细信息队列中,提取在接收到该第一提取任务的时刻之前的提取时长内发生的事务明细信息;
第一变更单元,用于根据在所述提取时长内发生的所述事务明细信息,确定该网络节点关联的资源数据在所述提取时长内的第一变更数值,并对该网络节点关联的资源数据进行与所述第一变更数值对应的变更;
第二提取单元,用于当接收到第二提取任务时,从预先记录的关于网络节点的事务明细信息队列中,提取在所述第一预设时长内发生的事务明细信息;
确定单元,用于根据在所述第一预设时长内发生的所述事务明细信息,确定该网络节点关联的资源数据在所述第一预设时长内的第二变更数值;
第二变更单元,用于在所述第二变更数值与在所述第一预设时长内确定的各个第一变更数值的和值不一致时,确定所述第二变更数值与所述第一变更数值的和值之间的差值,对所述网络节点关联的资源数据进行与所述差值对应的变更。
一种数据处理装置,包括:
第一提取单元,用于在第一预设时长内接收到以小于所述第一预设时长的第二预设时长为间隔的第一汇总记账任务时,从预先记录的关于账户的记账明细信息队列中,提取在接收到该第一汇总记账任务的时刻之前的提取时长内发生的记账明细信息;
第一变更单元,用于根据在所述提取时长内发生的所述记账明细信息,确定该账户的余额在所述提取时长内的第一变更金额,并对该账户的余额进行与所述第一变更金额对应的变更;
第二提取单元,用于当接收到第二汇总记账任务时,从预先记录的关于账户的记账明细信息队列中,提取在所述第一预设时长内发生的记账明细信息;
确定单元,用于根据在所述第一预设时长内发生的所述记账明细信息,确定该账户的余额在所述第一预设时长内的第二变更金额;
第二变更单元,用于在所述第二变更金额与在所述第一预设时长内确定的各个第一变更金额的和值不一致时,确定所述第二变更金额与所述和值之间的差值,对所述账户的余额进行与所述差值对应的变更。
由以上本申请各实施例提供的技术方案可见,本申请各实施例通过在第一预设时长内设置的以第二预设时长为间隔的第一提取任务,定时对一定的提取时长内发生的事务明细信息进行提取,计算得出第一变更数值并对网络节点的资源数据进行与第一变更数值对应的变更。此外,还通过第二提取任务对上述第一预设时长内发生的事务明细信息进行提取,计算得出第二变更数值,最终通过验证第二变更数值与在第一预设时长内确定的各个第一变更数值的和值是否一致,来判定在上述第一提取任务的过程中是否存在数据遗漏的情况,若存在遗漏,则通过确定所述第二变更数值与各第一变更数值的和值之间的差值,对所述网络节点关联的资源数据进行与所述差值对应的变更。在上述过程中,通过在第一预设时长内设置第一提取任务,可以提升上述网络节点的资源数据的更新的时效性,通过第二提取任务可以确保上述网络节点的资源数据的更新的准确性,从而使得本申请的技术方案可以兼顾网络节点关联的资源数据的变更操作的时效性和准确性。
具体实施方式
为了使本技术领域的人员更好地理解本申请中的技术方案,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都应当属于本申请保护的范围。
本申请实施例提供的数据处理方法用以对互联网中的网络节点所关联的资源数据进行变更处理。本申请适用于多种应用场景,如网上购物、购买车票、订购演唱会门票等互联网交易场景。在一些具体应用中,上述网络节点可以是互联网中的“热点账户”(或称“高并发账户”),本文将互联网中的事务请求的并发量较大的用户账户定义为上述“热点账户”。这类“热点账户”例如是:互联网中的交易量较大的商户账户、打车业务账户等。对于上述热点账户,通常在短时间内发生的交易明细数据量会非常大,这样导致基本无法对热点账户的数据进行实时地更新,而是通过汇总一天内的交易明细数据并进行统一轧差的方式来实现上述热点账户的数据更新。然而,由于现有的汇总一般是日切方式,这就导致针对上述热点账户所关联的资源数据的更新是每隔一天进行一次的,进而导致用户无法快速获悉热点账户的资源数据的变更情况。另一方面,若单纯地通过缩短上述定时任务的定时间隔(如:缩短为10分钟)来提高上述网络节点关联的资源数据的余额更新的频率(如:每隔10分钟更新一次),可能会因某些因数(如:数据延迟)造成所提取的事务明细信息存在遗漏的情况,进而造成最终更新的资源数据不准确。其中,举例说明上述数据延迟的情况:假设每隔10分钟去汇总一次交易明细数据,在时间点3:00:00可以去汇总02:30:00~02:40:00之间发生的交易明细数据并作汇总,然而,若因为网络延迟,在数据库中只存储有02:39:00之前的交易明细数据,这样便可能导致02:39:00~02:40:00被遗漏了,进而导致最终更新得到的资源数据的余额不准确。
本申请的技术方案正是为了在上述高并发场景下,在提升实现这类“热点账户”的资源数据的余额更新的时效性的同时,确保余额更新的准确性而产生的。当然,本申请的技术方案并不限于对“热点账户”的资源数据的余额更新。
图2为本申请一实施例提供的数据处理方法的流程,包括:
S101:当在第一预设时长内接收到以小于第一预设时长的第二预设时长为间隔的第一提取任务时,从预先记录的关于网络节点的事务明细信息队列中,提取在接收到该第一提取任务的时刻之前的提取时长内发生的事务明细信息。
以互联网中热点账户的资源数据的余额更新为例,由于这类热点账户的交易并发量较大,数据处理系统在接收到关于这些热点账户的事务请求(即资源数据的变更请求)后,可以生成相应的事务明细信息,该事务明细信息可以包括与本事务请求对应的资源数据的变更数额。上述数据处理系统可以将生成的上述事务明细信息逐一插入到汇总明细表ACCOUNT_LOG_SUMMARY中,从而得到储存于该汇总明细表的在各个时间点发生的事务明细信息的集合(称为“事务明细信息队列”)。
关于记录上述网络节点的事务明细信息的过程,可以通过分布式事务管理器的一阶段预处理过程和二阶段提交过程来实现。其中,在一阶段预处理过程中,在接收到一条事务请求后,可以插入该事务请求并锁住事务记录(事务记录可以包括交易双方账户信息、交易时间点、交易数额等),再对该条事务请求进行交易合法性检查;若该条事务请求通过交易合法性检查,则可以在二阶段提交过程中生成该事务请求对应的事务明细信息的,并在上述汇总明细表ACCOUNT_LOG_SUMMARY中记录该条事务明细信息及该事务明细信息对应的时间点。
上述第一提取任务是数据处理系统预先配置的以第二预设时长T2为间隔的定时机制。为了实现上述网络节点中的资源数据的余额的准实时更新,本申请实施例可以将该第二预设时长T2设置成不超过1h,例如,1min,10min,30min等。本申请通过第一提取任务,定时地从上述汇总明细表中提取在相应的提取时长T3内发生的事务明细信息,来作相应的资源数据的余额更新操作。
本实施例中,对于某些网络节点(如:热点账户)而言,通常这些网络节点在短时间内的事务请求的并发量(即业务量)也是足够大的,若上述提取时长设定得过长,则可能导致每次提取操作对数据库造成一定的“尖刺”,从而影响数据库的性能。鉴于此,在配置上述第一提取任务时,需要根据实际的业务量及数据库性能,设定合适的提取时长。
另外,在上述数据处理系统中,通常由于系统问题或网络抖动等因素,可能导致某些时间点发生的事务请求所对应的事务明细信息不会被第一时间写入到上述汇总明细表中。例如:01:09:00发生的事务请求,该事务请求对应的事务明细信息到01:19:00才被写入到上述汇总明细表中。鉴于上述原因,为确保每个第一提取任务能够从汇总明细表中将提取时长内的事务明细信息全部读取,需要设定合适的预设延迟时长T1,以确保数据处理系统有足够的时间将可能存在延迟的事务明细信息进行记录。
可选地,提取在所述提取时长内发生的事务明细信息之前,还包括:
当接收到第一提取任务时,确定接收到该第一提取任务的时刻之前的、且与该时刻相隔预设延迟时长的时间点为提取时长的起始时刻,得到与所述第二预设时长相等的提取时长;所述预设延迟时长不小于所述第二预设时长。
参图3,其示出了本申请一实施例中的各时间参数的关系。本实施例中,提取时长T3等于第二预设时长T2,预设延迟时长T1不小于第二预设时长T2。其中,将提取时长T3与第二预设时长T2设定成相等,可以避免资源数据的重复更新。举例而言,假设T3=T2=1min,T1=10min,在M日内接收的第n次的第一提取任务的时刻是:15:00:00,在M日内接收的第n+1次的第一提取任务的时刻是:15:01:00,确定接收第n次的第一提取任务的时刻15:00:00之前的、并且相隔10min的时刻14:50:00为提取时长T3的起始时刻,则该提取时长T3的终止时刻是:14:51:00。相应地,第n+1次的第一提取任务对应的提取时长是14:51:00~14:52:00,以此类推。
关于上述第一提取任务对应的各个时间参数(提取时长、第二预设时长、预设延迟时长),是可以进行动态调整的。在可选的实施例中,在接收第一提取任务之前,所述方法还包括:根据在单位时长(如:10分钟)内发生的事务明细信息的数量(即业务量),确定所述第二预设时长T2的长度。
具体地,上述单位时长内发生的事务明细信息的数量可以是历史业务量或当前正在运行的业务量。一般地,可以根据上述业务量估算一个与该业务量相适合的第二预设时长T2的长度,估算得到的这个时间长度对实际的处理时间来说有一定的余地。举例而言,在实际场景中,假设通过估算得到在正常情况下完成对某个时段(如:10分钟)内产生的事务明细信息进行汇总需要耗用的时长是1分钟,为了使得上述第一提取任务能够有足够的时间对上述提取时长内的数据进行汇总(因为在数据库可能存在抖动时,进行上述汇总所需耗用的时长可能变成5分钟或更长),可以设定将上述第二预设时长T2的长度远大于该实际需要耗用的时长,比如:30分钟。总之,上述第二预设时长可以根据实际业务量进行调整,以适应于实际业务量的需求。
参图4所示,其示例性地示出了本申请实施例中根据业务量对第一提取任务的时间参数进行调整的过程。其中,假设第n次第一提取任务与第n+1次第一提取任务是采用变更前的第二预设时长(如2分钟),假设在第n+1次第一提取任务执行完毕后系统的业务量(即单位时间内发生的事务明细信息的数量)超过预设阈值,则此时需要对上述第一提取任务的定时间隔(即上述第二预设时长)作相应的调整。通过调整之后,可以看出从第n+2次第一提取任务起,采取的第二预设时长可以进行相应的延长,比如从2分钟延长至3分钟(当然,实际情况中不会采取2分钟,仅作示例性说明)。相应地,从图中看出,对第二预设时长进行调整后,因为提取时长的长度需始终等于第二预设时长的长度,故从第n+2次第一提取任务起,各个任务所对应的提取时长也随着第二预设时长进行相应的延长。通过根据实际业务量实现对第一提取任务的时间参数的调整,可以使得第一提取任务更加适应于实际业务量的需求。
本申请实施例中,上述第一提取任务的定时间隔通常可以远小于上述第二提取任务的间隔,例如:上述第一提取任务的间隔是1分钟,或30分钟,或60分钟等。此外,上述第二提取任务可以是定时或不定时的任务,可选地,若第二提取任务是定时任务,则该第二提取任务可以是以第一预设时长T4(如:24小时、一周等)为定时间隔的定时任务。
在本申请可选的实施例中,上述步骤S101之前,所述方法还可以包括:
在所述第一预设时长内确定用以启动第一提取任务的热点时间段。
相应地,上述步骤S101可以具体包括:当在第一预设时长中包含的热点时间段内接收到以小于所述第一预设时长的第二预设时长为间隔的第一提取任务时,从预先记录的关于网络节点的事务明细信息队列中,提取在接收到该第一提取任务的时刻之前的提取时长内发生的事务明细信息。
对于一些网络节点而言,通常在一天中的某个时间段(如:15:00:00到20:00:00),或者,在某些特定的交易日(如:11月11号),其事务请求的并发量会呈现井喷的状态。若将以上网络节点的事务请求并发量呈现井喷状态的时间段定义为“热点时间段”,则可以将上述第一提取任务设定在该热点时间段内进行启用。
其中,可以根据不同的网络节点的历史业务量来确定与各个网络节点对应的热点时间段。举例而言,若通过查看某个网络节点的历史业务量,发现该网络节点在每天的15:00:00到20:00:00内的业务量超过预设阈值,则可以确定该网络节点的热点时间段是:每天的15:00:00到20:00:00。相应地,可以在15:00:00到20:00:00之间的热点时间段内为该网络节点启动第一提取任务,时间间隔可以是1min,预设延迟时长是10min,在15:00:00到来时,可以预设从汇总明细表ACCOUNT_LOG_SUMMARY中提取该日的00:00:00~14:50:00的事务明细信息,并求和得到与该时段对应的第一变更数值,再对该网络节点的资源数据进行相应的更新操作。如此,在接收到15:01:00的第一提取任务时,便可以提取该日的14:50:00~14:51:00的事务明细信息,并求和得到与该时段对应的第一变更数值,再对该网络节点的资源数据进行相应的更新操作。值得一提的是,在设定上述热点时间段的方案中,由于热点账户产生的交易量会非常大,从而在短时间内无法将该日的00:00:00~14:50:00中的所有的交易明细数据进行全部汇总。这样便有可能导致当热点时间段到来时,还没有完成对上述该日的00:00:00~14:50:00中的所有的交易明细数据的汇总。鉴于此,在上述实施例中,针对预设的热点时间段的起始时刻,可以设定上述第一提取任务的起始时刻是早于该热点时间段的起始时刻的,并且设定该第一提取任务的起始时刻与该热点时间段的起始时刻之间的时间间隔足够长(例如:不小于对该日的00:00:00~14:50:00中的所有的交易明细数据进行全部汇总所需耗用的时长)。举例而言,若上述热点时间段是15:00:00到20:00:00,则可以设定上述第一提取任务从14:30:00开始运行,在14:30:00接收到第一个定时任务时,开始汇总上述00:00:00~14:50:00中的所有的交易明细数据(从汇总明细表ACCOUNT_LOG_SUMMARY中提取),并对网络节点(热点账户)的资源数据进行更新。这样,假设00:00:00~14:50:00中的所有的交易明细数据需要汇总30min,那么大概在15:00:00便可以完成汇总,也就是说,在14:30:00就已经开始准实时汇总了,但是要等到15:00:00汇总完了,账户的资金才能准确反映。总之,通过确定用以启动第一提取任务的上述热点时间段,可以使得第一提取任务在仅在业务量较大的热点时间段进行启动,这样可以在一定程度上降低数据处理系统的负担,缓解机器资源的损耗。
S102:根据在提取时长内发生的所述事务明细信息,确定该网络节点关联的资源数据在所述提取时长内的第一变更数值,并对该网络节点关联的资源数据进行与所述第一变更数值对应的变更。
举例而言,若在M日内接收的第n次的第一提取任务对应的提取时长是:14:50:00~14:51:00,则通过从汇总明细表ACCOUNT_LOG_SUMMARY中提取,得到在上述提取时长14:50:00~14:51:00内某网络节点的事务明细信息(以金额值的形式表示)是:
{+100,-3,+1000,+304,-3940,+45956,+3,+5,+6,-7,+88};
则,可以通过求和运算,得到该网络节点关联的资源数据在所述提取时长内的第一变更数值是:
100-3+1000+304-3940+45956+3+5+6-7+88=43512。
例如,该网络节点更新前的资源数据的余额是10000,则更新后,其资源数据的余额是:43512+10000=53512。
值得提及的是,若实现资源数据更新的接口是以服务的方式暴露给外部调用的,可以远程调用方式RPC发送资源数据更新消息并调用远程接口,实现当前网络节点的资源数据的余额更新操作。当然,调用方式不限于远程。
S103:当接收到第二提取任务时,从预先记录的关于网络节点的事务明细信息队列中,提取在所述第一预设时长内发生的事务明细信息。
以第二提取任务的定时间隔是24小时为例,可以设定在M+1日的02:00:00进行第二提取任务,来从汇总明细表ACCOUNT_LOG_SUMMARY中提取M日的00:00:00~24:00:00的事务明细信息,将在M日内可能出现的延迟比较久的事务记录进行一次补充汇总。
S104:根据在所述第一预设时长内发生的所述事务明细信息,确定该网络节点关联的资源数据在所述第一预设时长内的第二变更数值。
通过提取在M日的00:00:00~24:00:00(第一预设时长)的事务明细信息,求和得到在M日的00:00:00~24:00:00内的第二变更数值。本申请实施例中,在每次第一提取任务时,可以将得到第一变更数值累加到准实时汇总表ACCOUNT_LOG_SUMMARY_MINUTE中,例如:在M日的3次第一提取任务中,得到的第一变更数值分别是:100、200、300,则在这3次第一提取任务完成时,上述准实时汇总表中累加得到的第一变更数值的和值是600。当然,在其他实施例中,可以将每个第一提取任务中得到的第一变更数值进行记录,在第二提取任务启动时,再提取记录的若干第一变更数值并进行求和运算。
S105:在所述第二变更数值与在所述第一预设时长内确定的各个第一变更数值的和值不一致时,确定所述第二变更数值与所述和值之间的差值,对所述网络节点关联的资源数据进行与所述差值对应的变更。
在上述步骤S104之后,需要验证所述第二变更数值是否与所述和值是否一致。若一致,表明M日中第一提取任务并无数据遗漏,反之,则表明存在数据遗漏。
若所述第二变更数值与所述和值是否不一致(表明存在数据遗漏),则确定所述第二变更数值与所述和值的差值。
举例而言,通过M+1日的第二提取任务,得到某网络节点在M日的00:00:00~24:00:00内的第二变更数值是:10000;而通过读取准实时汇总表,得到记录的截止M日中24:00:00累计的第一变更数值的和值是9990,则表明存在遗漏,确定两者的差值是10。
在存在差值时,可以在第二提取任务中,对该网络节点关联的资源数据的余额进行一次补充变更操作,例如,在M+1日的02:00:00,该网络节点关联的资源数据的余额是100,则通过补充变更操作,将其资源数据的余额更改为110。值得提及的是,在可行的实施例中,上述验证过程的具体过程并不限于上述过程。例如,若发现第一变更数值的和值与第二变更数值不一致,可以生成错误信息并反馈至业务系统;或,若发现第一变更数值的和值与第二变更数值不一致,取消通过M日中第一提取任务进行的资源数据的更新操作,以M+1日的第二提取任务得到第二变更数值为准,来进行资源数据的更新操作;等等。
在上述第一提取任务和第二提取任务结合的方案中,可能存在如下异常现象:
1)在M+1日的第二提取任务的补充汇总时,有可能由于M日中的一个或多个第一提取任务的意外停止,导致M日中的第一提取任务还没有执行完,这样,当第一提取任务恢复时,就会继续进行事务明细信息的提取并作资源数据的更新操作,然而,第二提取任务在上述第一提取任务恢复之前,已经完成对M日进行过补充更新操作了,如此就会发生重复操作,导致最终网络节点关联的资源数据的余额不准确;
2)由于某种原因,上述M+1日的第二提取任务启动的过早,但是M日中的第一提取任务还没执行完,这样的情况也会发生重复操作。
参照图5所示,假设M+1日的第二提取任务的时刻是01:00:00,在启动该第二提取任务时,正常的情况应该是:M日的第一提取任务已经执行完毕(在执行M+1日中某个时段的第一提取任务),但是,在图5中,在M+1日的01:00:00,还在执行M日的23:50:00的第一提取任务,这样,就会导致M日的23:50:00~M+1日的00:00:00之间的事务明细信息被重复提取,从而导致网络节点关联的资源数据的重复变更。本申请实施例通过下述技术方案来避免第一提取任务和第二提取任务的冲突。
可选地,当接收到所述第一提取任务时,提取在所述提取时长内发生的事务明细信息之前,还包括:
判断接收到该第一提取任务的时刻是否在执行第二提取任务。
在实际实现过程中,每次第一提取任务之后,可以在准实时汇日志表SUMMARY_MINUTE_LOG中记录本次第一提取任务的时间点;
在执行每一个第二提取任务之前,可以在日切补充汇总日志表SUMMARY_T_LOG中插入一条与当前第二提取任务的时间点对应的记录。
在步骤S205中,可以在接收到M日中的第一提取任务时,通过查询上述日切补充汇总日志表SUMMARY_T_LOG,来判断当前时刻是否在执行M+1日的第二提取任务。
相应地,提取在提取时长内发生的事务明细信息,具体可以包括:
当接收到该第一提取任务的时刻不在执行第二提取任务时,从预先记录的关于网络节点的事务明细信息队列中,提取在接收到该第一提取任务的时刻之前的提取时长内发生的事务明细信息。
在接收到该M日的第一提取任务的时刻不在执行M+1日的第二提取任务时,确定在接收到该第一提取任务的时刻之前的提取时长;
在接收到该M日的第一提取任务的时刻在执行M+1日的第二提取任务时,将上述准实时汇日志表SUMMARY_MINUTE_LOG中的记录时间更新到M+1日的00:00:00,从而使得数据处理系统的第一提取任务跳过M日中未完成的资源数据的更新操作,转而开始执行M+1日中的第一提取任务。通过上述步骤,可以避免第一提取任务和第二提取任务的冲突。
可选地,当接收到第二提取任务时,提取在所述第一预设时长内发生的事务明细信息之前,还可以包括:
判断在所述第一预设时长内的第一提取任务是否执行完毕。
本申请实施例中,数据处理系统可以通过查询上述准实时汇日志表SUMMARY_MINUTE_LOG,来判断是否还在做M日中的某时段的第一提取任务。
则,提取在所述第一预设时长内发生的事务明细信息,具体可以包括:
当在所述第一预设时长内的第一提取任务执行完毕时,提取在所述第一预设时长内发生的事务明细信息。
其中,在所述第一预设时长内的第一提取任务未执行完毕时,将上述准实时汇日志表SUMMARY_MINUTE_LOG中的时间点更新至M+1日的00:00:00。在此过程中,M日中未执行完毕的第一提取任务的事务明细信息,会被M+1日的第二提取任务一并补充处理掉。
图6为本申请一实施例提供的应用于账户余额的变更场景的数据处理方法的流程,包括:
S201:当在第一预设时长内接收到以小于所述第一预设时长的第二预设时长为间隔的第一汇总记账任务时,从预先记录的关于账户的记账明细信息队列中,提取在接收到该第一汇总记账任务的时刻之前的提取时长内发生的记账明细信息;
S202:根据在所述提取时长内发生的所述记账明细信息,确定该账户的余额在所述提取时长内的第一变更金额,并对该账户的余额进行与所述第一变更金额对应的变更;
S203:当接收到第二汇总记账任务时,从预先记录的关于账户的记账明细信息队列中,提取在所述第一预设时长内发生的记账明细信息;
S204:根据在所述第一预设时长内发生的所述记账明细信息,确定该账户的余额在所述第一预设时长内的第二变更金额;
S205:在所述第二变更金额与在所述第一预设时长内确定的各个第一变更金额的和值不一致时,确定所述第二变更金额与所述和值之间的差值,对所述账户的余额进行与所述差值对应的变更。
上述步骤S201-S205可以参照上述步骤S101-S105中的具体内容。
本申请各实施例提供的数据处理方法中,通过在第一预设时长内设置的以第二预设时长为间隔的第一提取任务,定时对一定的提取时长内发生的事务明细信息(在账户余额的变更场景中为记账明细信息)进行提取,计算得出第一变更数值并对网络节点的资源数据(在账户余额的变更场景中为账户的余额)进行与第一变更数值对应的变更。此外,还通过第二提取任务对上述第一预设时长内发生的事务明细信息进行提取,计算得出第二变更数值,最终通过验证第二变更数值与在第一预设时长内确定的各个第一变更数值的和值是否一致,来判定在上述第一提取任务的过程中是否存在数据遗漏的情况,若存在遗漏,则通过确定所述第二变更数值与各第一变更数值的和值之间的差值,对所述网络节点关联的资源数据进行与所述差值对应的变更。在上述过程中,通过在第一预设时长内设置第一提取任务,可以提升上述网络节点的资源数据的更新的时效性(例如:可以每隔30分钟对账户余额进行一次更新操作),通过第二提取任务可以确保上述网络节点的资源数据的更新的准确性(例如:可以每隔24小时对之前一天中的第一提取任务所作的余额更新进行验证),从而使得本申请的技术方案可以兼顾网络节点关联的资源数据的变更操作的时效性和准确性。本申请实施例可以应用于银行、在线支付系统中处理账户之间的资金流动操作。对于互联网中的事务并发量较大的热点账户的无法实时更新账户余额的问题,存在实际意义。
与上述方法流程对应的,本申请的实施例还提供了一种数据处理装置。该装置可以通过软件实现,也可以通过硬件或者软硬件结合的方式实现。以软件实现为例,作为逻辑意义上的装置,是通过服务器的中央处理器(Central ProcessUnit,CPU)将对应的计算机程序指令读取到内存中运行形成的。
图7为本申请一实施例提供的数据处理装置的模块示意图。其中,该装置中各单元的功能与上述方法中各步骤的功能类似,故该装置可以参照上述方法实施例的具体内容。该数据处理装置包括:
第一提取单元101,用于在第一预设时长内接收到以小于所述第一预设时长的第二预设时长为间隔的第一提取任务时,从预先记录的关于网络节点的事务明细信息队列中,提取在接收到该第一提取任务的时刻之前的提取时长内发生的事务明细信息;
第一变更单元102,用于根据在所述提取时长内发生的所述事务明细信息,确定该网络节点关联的资源数据在所述提取时长内的第一变更数值,并对该网络节点关联的资源数据进行与所述第一变更数值对应的变更;
第二提取单元103,用于当接收到第二提取任务时,从预先记录的关于网络节点的事务明细信息队列中,提取在所述第一预设时长内发生的事务明细信息;
确定单元104,用于根据在所述第一预设时长内发生的所述事务明细信息,确定该网络节点关联的资源数据在所述第一预设时长内的第二变更数值;
第二变更单元105,用于在所述第二变更数值与在所述第一预设时长内确定的各个第一变更数值的和值不一致时,确定所述第二变更数值与所述第一变更数值的和值之间的差值,对所述网络节点关联的资源数据进行与所述差值对应的变更。
可选地,所述装置还包括:
提取时长确定单元,用于当接收到第一提取任务时,确定接收到该第一提取任务的时刻之前的、且与该时刻相隔预设延迟时长的时间点为提取时长的起始时刻,得到与所述第二预设时长相等的提取时长;所述预设延迟时长不小于所述第二预设时长。
可选地,所述装置还包括:
长度确定单元,用于在提取所述提取时长内发生的事务明细信息之前,根据在单位时长内发生的事务明细信息的数量,确定所述第二预设时长的长度。
可选地,所述装置还包括:
第一判断单元,用于当接收到所述第一提取任务时,提取在所述提取时长内发生的事务明细信息之前,判断接收到该第一提取任务的时刻是否在执行第二提取任务;
相应地,所述第一提取单元101具体用于:
当接收到该第一提取任务的时刻不在执行第二提取任务时,从预先记录的关于网络节点的事务明细信息队列中,提取在接收到该第一提取任务的时刻之前的提取时长内发生的事务明细信息。
可选地,所述装置还包括:
第一判断单元,用于当接收到第二提取任务时,提取在所述第一预设时长内发生的事务明细信息之前,判断在所述第一预设时长内的第一提取任务是否执行完毕;
相应地,所述第二提取单元103具体用于:
当在所述第一预设时长内的第一提取任务执行完毕时,提取在所述第一预设时长内发生的事务明细信息。
可选地,所述装置还包括:
热点时间段确定单元,用于在所述第一预设时长内确定用以启动第一提取任务的热点时间段;
相应地,所述第一提取单元101具体用于:
当在第一预设时长中包含的热点时间段内接收到以小于所述第一预设时长的第二预设时长为间隔的第一提取任务时,从预先记录的关于网络节点的事务明细信息队列中,提取在接收到该第一提取任务的时刻之前的提取时长内发生的事务明细信息。
结合账户余额更新的场景,上述数据处理装置,包括:
第一提取单元101,用于在第一预设时长内接收到以小于所述第一预设时长的第二预设时长为间隔的第一汇总记账任务时,从预先记录的关于账户的记账明细信息队列中,提取在接收到该第一汇总记账任务的时刻之前的提取时长内发生的记账明细信息;
第一变更单元102,用于根据在所述提取时长内发生的所述记账明细信息,确定该账户的余额在所述提取时长内的第一变更金额,并对该账户的余额进行与所述第一变更金额对应的变更;
第二提取单元103,用于当接收到第二汇总记账任务时,从预先记录的关于账户的记账明细信息队列中,提取在所述第一预设时长内发生的记账明细信息;
确定单元104,用于根据在所述第一预设时长内发生的所述记账明细信息,确定该账户的余额在所述第一预设时长内的第二变更金额;
第二变更单元105,用于在所述第二变更金额与在所述第一预设时长内确定的各个第一变更金额的和值不一致时,确定所述第二变更金额与所述和值之间的差值,对所述账户的余额进行与所述差值对应的变更。
为了描述的方便,描述以上装置时以功能分为各种单元分别描述。当然,在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白,本发明的实施例可提供为方法、系统、或计算机程序产品。因此,本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白,本申请的实施例可提供为方法、系统或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
以上所述仅为本申请的实施例而已,并不用于限制本申请。对于本领域技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本申请的权利要求范围之内。