CN111242783A - 交易数据处理方法、装置、计算机设备以及存储介质 - Google Patents

Abstract

本申请实施例公开了一种交易数据处理方法、装置、计算机设备以及存储介质，方法包括：获取目标用户在结算时间戳的基准剩余业务量；获取所述目标用户的至少一个历史交易记录，所述历史交易记录包括交易时间戳，所述至少一个历史交易记录中每个历史交易记录包括的交易时间戳均小于或等于所述结算时间戳；根据所述基准剩余业务量确定所述每个历史交易记录分别对应的交易剩余业务量。采用本申请，可以丰富历史交易记录的数据种类，以及直观表达用户的历史资源数据量情况。

Description

交易数据处理方法、装置、计算机设备以及存储介质

技术领域

本申请涉及计算机技术领域，尤其涉及一种交易数据处理方法、装置、计算机设备以及存储介质。

背景技术

互联网金融是指通过互联网进行有关金融业务的交易行为，目前各金融机构与用户通过互联网金融交易平台发生交易行为。依托于互联网的信息高效传播效率，互联网金融交易平台获得信息更加便捷，信息透明度更高，因此拥有更高的用户信赖度。

用户可以将资源数据存放在互联网金融交易平台，并在该互联网金融交易平台发生交易行为，平台生成对应的历史交易记录。但历史交易记录中只会记录交易金额、交易对象以及交易时间，所记录的数据类型单一，进而导致记录的数据不能直观表达用户的历史资源数据量情况。

发明内容

本申请实施例提供一种交易数据处理方法、装置、计算设备以及存储介质，可以丰富历史交易记录的数据种类，以及直观表达用户的历史资源数据量情况。

本申请实施例一方面提供了一种交易数据处理方法，包括：

获取目标用户在结算时间戳的基准剩余业务量；

获取目标用户的至少一个历史交易记录，历史交易记录包括交易时间戳，至少一个历史交易记录中每个历史交易记录包括的交易时间戳均小于或等于结算时间戳；

根据基准剩余业务量确定每个历史交易记录分别对应的交易剩余业务量。

本申请实施例一方面提供了一种交易数据处理装置，包括：

第一获取模块，用于获取目标用户在结算时间戳的基准剩余业务量；

第二获取模块，用于获取目标用户的至少一个历史交易记录，历史交易记录包括交易时间戳，至少一个历史交易记录中每个历史交易记录包括的交易时间戳均小于或等于结算时间戳；

确定模块，用于根据基准剩余业务量确定每个历史交易记录分别对应的交易剩余业务量。

其中，第一获取模块，包括：

第一获取单元，用于获取目标用户的至少一个关联业务对象；

第二获取单元，用于分别获取每个关联业务对象在结算时间戳对应的单位剩余业务量；

第一获取单元，还用于将至少一个单位剩余业务量叠加为基准剩余业务量。

其中，第二获取单元，具体用于接收结算终端发送的关联业务对象在结算时间戳对应的第一剩余业务量，从本地文件中获取关联业务对象在结算时间戳对应的第二剩余业务量，若第一剩余业务量和第二剩余业务量相同，则将第一剩余业务量确定为关联业务对象在结算时间戳对应的单位剩余业务量。

其中，确定模块，包括：

划分单元，用于将至少一个历史交易记录划分为第一历史交易记录和至少一个第二历史交易记录；第一历史交易记录是至少一个历史交易记录中具有最大交易时间戳的历史交易记录；至少一个第二历史交易记录是至少一个历史交易记录中除第一历史交易记录以外的历史交易记录；

第一确定单元，用于将基准剩余业务量作为与第一历史交易记录对应的交易剩余业务量；

第二确定单元，用于根据基准剩余业务量，确定与每个第二历史交易记录分别对应的交易剩余业务量。

其中，每个历史记录均包括交易类型和交易业务量；

第二确定单元，包括：

设置子单元，用于根据每个第二历史交易记录的交易时间戳，为每个第二历史交易记录分别设置轮询优先级，从至少一个第二历史交易记录中选择具有最高轮询优先级的第二历史交易记录，将选择的第二历史交易记录作为目标历史交易记录；

获取子单元，用于获取第一历史交易记录的目标交易类型和目标交易业务量；

确定子单元，用于根据目标交易类型、目标交易业务量以及基准剩余业务量确定与目标历史交易记录对应的交易剩余业务量；

获取子单元，还用于将目标历史交易记录作为第一历史交易记录，将与目标历史交易记录对应的交易剩余业务量作为基准剩余业务量，从剩余的第二历史交易记录中选择下一个用于轮询的目标历史交易记录，当所有的第二历史交易记录均被作为目标历史交易记录时，停止轮询。

其中，目标交易类型包括业务量输入类型和业务量输出类型；

确定子单元，具体用于若目标交易类型为业务量输入类型，则将基准剩余业务量和目标交易业务量相减为与目标历史交易记录对应的交易剩余业务量，若目标交易类型为业务量输出类型，则将基准剩余业务量和目标交易业务量叠加为与目标历史交易记录对应的交易剩余业务量。

其中，第二获取模块，包括：

第三获取单元，用于获取业务区块链；业务区块链包括至少一个目标业务区块，至少一个目标业务区块中每个目标业务区块用于存储目标用户的历史交易记录；

读取单元，用于从业务区块链中获取至少一个目标业务区块；

第三获取单元，还用于从至少一个目标业务区块的区块体中分别读取至少一个历史交易记录。

其中，读取单元，具体用于从业务区块链中获取与目标用户相关联的至少一个原始业务区块，至少一个原始业务区块中每个原始业务区块用于存储目标用户的原始交易记录；原始交易记录包括交易时间戳，获取业务时长，根据业务时长和结算时间戳确定业务时间戳；业务时间戳小于结算时间戳，将交易时间戳处于业务时间戳和结算时间戳区间内的原始交易记录所对应的原始业务区块，作为目标业务区块。

其中，至少一个历史交易记录从云服务器拉取的；每个历史交易记录均包括交易业务量以及交易摘要；

方法还包括：

更新模块，用于响应于目标用户的交易记录显示请求，将至少一个交易剩余业务量分别添加至至少一个历史交易记录，显示更新后的历史交易记录，并将更新后的历史交易记录上传至云服务器，指示云服务器更新至少一个历史交易记录。

本申请实施例一方面提供了一种计算机设备，包括存储器和处理器，存储器存储有计算机程序，计算机程序被处理器执行时，使得处理器执行上述各实施例中的方法。

本申请实施例一方面提供了一种计算机存储介质，计算机存储介质存储有计算机程序，计算机程序包括程序指令，程序指令当被处理器执行时，执行上述各实施例中的方法。

本申请获取用户在结算时间戳中的基准剩余业务量，获取目标用户的多个历史交易记录，根据基准剩余业务量，确定每个历史交易记录分别对应的交易剩余业务量。上述可知，以一个时间点为基准，确定用户在该时间点的剩余业务量，从该时间点往前确定该用户的每一个历史交易记录的剩余业务量，采用本申请，可以获取到交易完成时的剩余业务量，不仅可以丰富历史交易记录的数据种类，还可以通过剩余业务量直观表达用户的历史资源数据量情况。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的一种交易数据处理的系统架构图；

图2a-图2d是本申请实施例提供的一种交易数据处理的场景示意图；

图3是本申请实施例提供的一种交易数据处理的流程示意图；

图4是本申请实施例提供的一种确定单位剩余业务量的交互示意图；

图5是本申请实施例提供的一种确定用户基准余额的交互示意图；

图6是本申请实施例提供的一种更新用户历史交易单的交互示意图；

图7是本申请实施例提供的一种区块链的系统架构图；

图8是本申请实施例提供的一种交易数据处理的流程示意图；

图9是本申请实施例提供的一种交易数据处理装置的结构示意图；

图10是本发明实施例提供的一种计算机设备的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

云技术(Cloud technology)是基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称，可以组成资源池，按需所用，灵活便利。目前，技术网络系统的后台服务需要大量的计算、存储资源，如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用，将来每个物品都有可能存在自己的识别标志，都需要传输到后台系统进行逻辑处理，不同程度级别的数据将会分开处理，各类行业数据皆需要强大的系统后盾支撑，只能通过云计算来实现。

目前，云技术主要分为云基础技术类以及云应用类；云基础技术类可以进一步细分为：云计算、云储存、数据库以及大数据等；云应用类可以进一步细分为：医疗云、云物联、云安全、云呼叫、私有云、公有云、混合云、云游戏、云教育、云会议、云社交以及人工智能云服务等。

本申请的交易数据处理主要涉及云计算和云储存：

云计算(cloud computing)是一种计算模式，它将计算任务分布在大量计算机构成的资源池上，使各种应用系统能够根据需要获取计算力、存储空间和信息服务。提供资源的网络被称为“云”。“云”中的资源在使用者看来是可以无限扩展的，并且可以随时获取，按需使用，随时扩展，按使用付费。

作为云计算的基础能力提供商，会建立云计算资源池(简称云平台，一般称为IaaS(Infrastructure as a Service，基础设施即服务)平台，在资源池中部署多种类型的虚拟资源，供外部客户选择使用。云计算资源池中主要包括：计算设备(为虚拟化机器，包含操作系统)、存储设备、网络设备。

按照逻辑功能划分，在IaaS(Infrastructure as a Service，基础设施即服务)层上可以部署PaaS(Platform as a Service,平台即服务)层，PaaS层之上再部署SaaS(Software as a Service,软件即服务)层，也可以直接将SaaS部署在IaaS上。PaaS为软件运行的平台，如数据库、web容器等。SaaS为各式各样的业务软件，如web门户网站、短信群发器等。一般来说，SaaS和PaaS相对于IaaS是上层。

在本申请中，可以由终端设备通过云计算技术获取足够算力和存储空间，进而执行本申请中所涉及的获取基准剩余业务量以及计算每一笔历史交易记录的交易剩余业务量。

云存储(cloud storage)是在云计算概念上延伸和发展出来的一个新的概念，分布式云存储系统(以下简称存储系统)是指通过集群应用、网格技术以及分布存储文件系统等功能，将网络中大量各种不同类型的存储设备(存储设备也称之为存储节点)通过应用软件或应用接口集合起来协同工作，共同对外提供数据存储和业务访问功能的一个存储系统。

目前，存储系统的存储方法为：创建逻辑卷，在创建逻辑卷时，就为每个逻辑卷分配物理存储空间，该物理存储空间可能是某个存储设备或者某几个存储设备的磁盘组成。客户端在某一逻辑卷上存储数据，也就是将数据存储在文件系统上，文件系统将数据分成许多部分，每一部分是一个对象，对象不仅包含数据而且还包含数据标识(ID，ID entity)等额外的信息，文件系统将每个对象分别写入该逻辑卷的物理存储空间，且文件系统会记录每个对象的存储位置信息，从而当客户端请求访问数据时，文件系统能够根据每个对象的存储位置信息让客户端对数据进行访问。

存储系统为逻辑卷分配物理存储空间的过程，具体为：按照对存储于逻辑卷的对象的容量估量(该估量往往相对于实际要存储的对象的容量有很大余量)和独立冗余磁盘阵列(RAID，Redundant Array of Independent Disk)的组别，预先将物理存储空间划分成分条，一个逻辑卷可以理解为一个分条，从而为逻辑卷分配了物理存储空间。

在本申请中，用户的历史交易记录可以由终端设备通过云存储技术存储在“云”上，当需要读取历史交易记录时，可以从云存储设备中拉取该历史交易记录，以降低终端设备的存储压力。

请参见图1，是本申请实施例提供的一种交易数据处理的系统架构图。本申请可以涉及服务器10d以及终端设备集群，终端设备集群可以包括：终端设备10a、终端设备10b、...、终端设备10c等。

以终端设备10a为例，终端设备10a是目标用户所在的终端设备。终端设备10a接收目标用户的交易记录获取请求，将该交易记录获取请求发送至服务器10d。服务器10d获取目标用户在结算时间戳的基准剩余业务量，结算时间戳是服务器10d和金融机构之间进行对账行为的最大对账时间戳，且结算时间戳小于当前时间戳。服务器10d获取目标用户的多个历史交易记录，每个历史交易记录均包括交易时间戳，且每个历史交易记录所包含的交易时间戳是小于或等于结算时间戳的。服务器10d根据基准剩余业务量，反向计算每一笔历史交易记录的交易剩余业务量。服务器10d可以将每一笔历史交易记录的交易剩余业务量添加至历史交易记录中，并将更新后的历史交易记录下发至终端设备10a，以使终端设备10a显示上述包含了交易剩余业务量的历史交记录。

当然，上述服务器10d所执行的步骤也可以由终端设备10a来执行，即终端设备10a获取到交易记录获取请求后，由终端设备10a获取目标用户在结算时间戳的基准剩余业务量，以及根据基准剩余业务量反向计算每一笔历史交易记录的交易剩余业务量。

图1所示的服务器10d可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(Content Delivery Network，内容分发网络)、以及大数据和人工智能平台等基础云计算服务的云服务器。

图1所示的终端设备10a、终端设备10b、终端设备10c等可以是智能手机、平板电脑、笔记本电脑、台式计算机、智能音箱、智能手表等，但并不局限于此。终端设备集群以及服务器10d可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

下述图2a-图2d在互联网金融场景下，以终端设备10a如何确定基准账户余额(即基准剩余业务量)以及如何确定每一笔历史交易记录的交易后余额(即交易剩余业务量)为例进行说明。

请参见图2a-图2d，是本申请实施例提供的一种交易数据处理的场景示意图，本申请涉及的交易数据处理可以应用于互联网金融客户端。本申请的应用场景为：用户通过互联网金融客户端可以查看用户在该客户端中的每一笔历史交易记录的交易后余额，以直观展示用户的历史资产情况，即前述中的历史资源数据量情况。

如图2a所示，终端设备10a是用户A所在的终端设备，且当前时间戳为2020/1/118:00:00，当用户A访问互联网金融客户端时，在该客户端的主界面显示用户A当前的账户余额，以及按钮“转出”、按钮“转入”以及按钮“交易记录”。从图2a可以看出，用户A当前的账户余额为1500元。

其中，按钮“转出”的功能是，将用户A在互联网金融账户中的资源数据转移至其余的账户(例如，银行卡账户)；按钮“转入”的功能是，将用户A在其余的账户(例如，银行卡账户)中的资源数据转移至互联网金融账户中，其中互联网金融账户是指与互联网金融客户端对应的用户账户。

按钮“交易记录”的功能是用于显示用户A的历史交交易记录，历史交易记录包括交易时间、交易金额以及交易后余额等。

用户A可以点击按钮“交易记录”，如图2b所示，终端设备10a获取用户A在2020/1/115:00:00的账户余额，作为基准余额，从图2b可以看出，用户A的基准余额为1000元。

每天的15:00:00终端设备10a都需要和金融机构核对用户A在当前交易日(昨天的15:00:00到今天的15:00:00)的账目(这个过程也称为对账)，对账项目就包括核对用户A在当天15:00:00的账户余额。

只有对账正确时，终端设备10a才会记录下用户A在当天15:00:00的账户余额。假设终端设备10a和金融机构对账正确，且记录下来的用户A在2020/1/115:00:00的账户余额为1000元。

终端设备10a从本地获取属于用户A，且交易时间在2020/1/1 15:00:00之前的历史交易记录，若当前获取到的历史交易记录中只包括交易时间，交易操作以及交易金额，并没有包含交易后余额。为了更直观地展示用户A的历史资产情况，因此终端设备10a需要计算用户A的每笔历史交易记录的交易后余额。

计算原理为：根据用户A在2020/1/1 15:00:00的基准余额，从2020/1/115:00:00往前推算每一笔历史交易记录的交易后余额。

如图2b所示，假设用户A在2020/1/1 15:00:00之前包括4笔历史交易记录，从时间维度上来看，是从后往前反向计算：

终端设备10a首先计算交易时间戳为2020/1/1 14:49:00的历史交易记录的交易后余额，由于这一笔历史交易记录是截止2020/1/1 15:00:00的最后一笔历史交易记录，因此，交易时间戳为2020/1/1 14:49:00的历史交易记录的交易后余额就等于基准余额1000元。

终端设备10a计算交易时间戳为2020/1/1 10:30:00的历史交易记录的交易后余额，由于是从后往前计算，因此这一笔历史交易记录的交易后余额是由后一笔历史交易记录(即交易时间戳为2020/1/1 14:49:00的历史交易记录)中的交易操作、交易金额以及交易后余额决定的。可以这样理解，对交易时间戳为2020/1/114:49:00的历史交易记录来说，转出100元后的余额为1000，那么转出之前，余额应该是1000+100＝1100，因此，交易时间戳为2020/1/1 10:30:00的历史交易记录的交易后余额为1100。

终端设备10a计算交易时间戳为2020/1/1 10:20:00的历史交易记录的交易后余额，这一笔历史交易记录的交易后余额是由交易时间戳为2020/1/1 10:30:00的历史交易记录中的交易操作、交易金额以及交易后余额决定的。可以这样理解，对交易时间戳为2020/1/1 10:30:00的历史交易记录来说，转入500元后的余额为1100，那么转入之前，余额应该是1100-500＝600，因此，交易时间戳为2020/1/1 10:20:00的历史交易记录的交易后余额为600。

终端设备10a计算交易时间戳为2020/1/1 10:10:00的历史交易记录的交易后余额，这一笔历史交易记录的交易后余额是由交易时间戳为2020/1/1 10:20:00的历史交易记录中的交易操作、交易金额以及交易后余额决定的。可以这样理解，对交易时间戳为2020/1/1 10:20:00的历史交易记录来说，消费100元后的余额为600，那么消费之前，余额应该是600+100＝700，因此，交易时间戳为2020/1/110:10:00的历史交易记录的交易后余额为700。

可见，从时间维度角度来说，当前历史交易记录的交易后余额是由后一笔历史交易记录中的交易操作、交易金额以及以及交易后余额来决定的。

终端设备10a可以将计算出来的每一笔历史交易记录的交易后余额添加至历史交易记录中，如图2b所示，添加后可以得到用户A的最新历史交易记录。

如图2c所示，终端设备10a可以将用户A的最新历史交易记录按照预定的板式排版为交易记录20a。

如图2d所示，互联网金融客户端响应用户A点击按钮“交易记录”，在互联网金融客户端的主界面中显示交易记录20a。

用户A通过上述交易记录20a中的交易后余额，可以直观地看到自己的历史资产情况。

其中，获取基准剩余业务量(如上述实施例中的基准余额)，获取历史交易记录(如上述实施例中的用户A的历史交易记录)以及每个历史交易记录的交易剩余业务量(如上述实施例中的交易后余额)的具体过程可以参见下述图3-图8对应的实施例。

请参见图3，是本申请实施例提供的一种交易数据处理的流程示意图，本申请的方案可以应用于互联网金融客户端，用户可以将银行账户内的资源数据转移至互联网金融客户端对应的互联网金融账户内，以购买该客户端所提供的金融产品，并获得一定的收益(金融领域内称为申购金融产品)；当然，用户也可以随着将上述互联网金融账户内的资源数据转移至银行账户(金融领域内称为赎回金融产品)，或者用户可以直接将互联网金融账户内的资源数据用于消费(金融领域内称为消费)。

现有的历史交易记录中没有包含交易剩余业务量，采用本申请的交易数据处理方法可以获取历史交易记录所对应的交易剩余业务量，该交易剩余业务量可以直接体现用户的历史资产情况。

下述实施例以互联网金融客户端为执行主体进行描述，也可以由云服务器来执行本申请所涉及的技术方案，或者互联网金融客户端通过云计算技术，调用云服务器来执行本申请所涉及的技术方案，并将执行后所得到的交易剩余业务量发送至终端设备。

交易数据处理可以包括如下步骤：

步骤S101，获取目标用户在结算时间戳的基准剩余业务量。

具体的，将当前处理的用户称为目标用户(如上述图2a-图2d对应实施例中的用户A)，互联网金融客户端在每天固定时间点(一般是15:00:00)都要和目标用户所持有的金融产品对应的金融机构进行对账(也称为结算，该固定时间点称为对账时间戳)，对账项目就包含双方共同确定目标用户在当天对账时间戳的剩余业务量，当双方达成共识后，共同记录目标用户在当天对账时间戳的剩余业务量。

其中互联网金融客户端所在的终端设备可以对应上述图2a-图2d对应实施例中的终端设备10a。

金融产品可以是货币基金、股票基金或者股票等。

由此可见，互联网金融客户端可以获取到目标用户在每天的对账时间戳的剩余业务量。互联网金融客户端从目标用户的所有对账时间戳中选择结算时间戳，将选择的结算时间戳的剩余业务量作为基准剩余业务量(如上述图2a-图2d对应实施例中的基准余额)。

从多个对账时间戳中选择结算时间戳的方式如下：

互联网金融客户端可以将距离当前时间戳最近的一个对账时间戳作为本申请的结账时间戳，将结算时间戳的剩余业务量称为基准剩余业务量。

例如，当前时间戳为2020/1/1 10:20:00，而对账时间戳是每天的15:00:00，因此可以将2019/12/31 15:00:00作为结算时间戳，将对账后的2019/12/3115:00:00的剩余业务量作为基准剩余业务量。

从前述可知，互联网金融客户端需要和目标用户所持有的金融产品对应的金融机构进行对账，目标用户所持有的金融产品的数量可能是一个，也可能是多个。下面对如何获取结算时间戳的基准剩余业务量进行具体的说明：

确定结算时间戳后，获取与目标用户相关联的业务对象(称为关联业务对象)，关联业务对象可以看作是目标用户所持的金融产品。

以一个关联业务对象为例进行说明：

互联网金融客户端接收结算终端(即金融机构所在的终端设备)发送的该关联业务对象在结算时间戳的剩余业务量(称为第一剩余业务量)，单位剩余业务量通俗理解为目标用户在结算时间戳所持有的某一个金融产品的价值。

互联网金融客户端从本地文件中获取该关联业务对象在结算时间戳的剩余业务量(称为第二剩余业务量)，若第一剩余业务量和第二剩余业务量相同，那么说明互联网金融客户端和关联业务对象的金融结构对账完成(即是达成共识)，进而互联网金融客户端以及结算终端都可以将第一剩余业务量作为该关联业务对象在结算时间戳的单位剩余业务量。

若目标用户的关联业务对象的数量有多个，那么互联网金融客户端可以采用上述方式分别确定每个关联业务对象的单位剩余业务量。将多单位剩余业务量叠加为基准剩余业务量。

下述以如何确定一个单位剩余业务量为例进行说明。请参见图4，是本申请实施例提供的一种确定单位剩余业务量的交互示意图，交易过程涉及互联网金融客户端、金融机构所在的结算终端以及收益数据库，具体包括如下步骤：

步骤S1011，互联网金融客户端拉取截止当日对账时间戳的所有交易数据，生成账单文件。

具体的，账单文件可以包括多笔原始交易记录，每一笔原始交易记录都包括：交易时间戳、交易类型、交易业务量以及交易的金融产品id，交易类型包括输入类型和输入类型。后续以金融产品是基金，以及一笔原始交易记录为例。

步骤S1012，互联网金融客户端将账单文件发送至金融机构所在的结算终端。

步骤S1013，结算终端根据账单文件生成结果文件和份额文件。

具体的，结算终端获取该用户在昨日所持有的基金份额，以及根据昨日的基金份额计算用户在当日的收益。结算终端根据基金当日的净值、当日的交易业务量以及当日的收益确定用户在当日所购买的基金份额。

其中，当日所购买的基金份额＝(当日的交易业务量+当日的收益)/当日的净值。

当日所持有的基金份额＝昨日所持有的基金份额+当日所购买的基金份额。

其中份额文件是用于记录用户在当日所持有的基金份额。

根据当日的收益和昨日的交易业务量确定当日的收益率。结果文件是用于存储当日的收益，当日的收益率等。

步骤S1014，结算终端向互联网金融客户端发送结果文件和份额文件。

步骤S1015，互联网金融客户端根据账单文件也计算用户在当日所持有的基金份额，若互联网金融客户端所计算出来的基金份额与份额文件中所记录的基金份额相同，那么对账结束。

步骤S1016，互联网金融客户端在收益数据库中记录在当日对账时间戳，用户当日所持有的基金份额。

其中，单位剩余业务量＝当日所持有的基金份额*基金在当日的净值。

上述步骤S1011-步骤S1016是以互联网金融客户端为执行主体，来确定一个单位剩余业务量，执行主体也可以是云服务器。

下述以云服务器为执行主体，说明如何确定用户基准余额，用户基准余额可以对应本申请中的基准剩余业务量。确定用户基准余额的具体过程为请参见下述图5，是本申请实施例提供的一种确定用户基准余额的交互示意图，交互过程包括云服务器，用户数据库以及收益数据库：

步骤S201，云服务器从用户数据库中拉取当前所有有效用户。

步骤S202，云服务器依次遍历每一个有效用户。

步骤S203，云服务器从收益数据库中读取用户所持有的基金在对账时间戳的基金份额，获取基金份额的具体过程可以参见上述步骤S1011-步骤S1016，只需将执行主体由互联网金融客户端调整为云服务器即可。

步骤S204，云服务器根据基金份额以及当前净值，确定用户所持有的该基金的余额，汇总多个基金的余额，得到用户基准余额。基准余额可以对应前述中的基准剩余业务量。

步骤S205，云服务器将汇总后的基准余额存储至收益数据库。

需要说明的是，上述步骤是由云服务器作为执行主体来确定用户基准余额，云服务器确定用户基准余额后，可以将每一个用户基准余额下发至每个用户所在的互联网金融客户端，进而由互联网金融客户端根据用户基准余额来确定每一笔交易后的交易余额。

依次遍历每一个用户，收益数据库中就会存储每个用户的基准余额。

步骤S102，获取目标用户的至少一个历史交易记录，历史交易记录包括交易时间戳，至少一个历史交易记录中每个历史交易记录包括的交易时间戳均小于或等于结算时间戳。

具体的，互联网金融客户端获取目标用户的至少一个历史交易记录(如上述图2a-图2d对应实施例中用户A的历史交易记录)，目标用户在互联网金融客户端中每发生一次交易行为(例如，申购金融产品、赎回金融产品等)，互联网金融客户端都会生成与之对应的交易记录。

其中，历史交易记录可以是互联网金融客户端从云服务器拉取的，或者互联网金融客户端通过云存储技术从云存储设备上拉取的，也可以从互联网金融客户端的本地获取的。

此时获取的历史交易记录是不包括交易剩余业务量的，交易剩余业务量可以看作是目标用户完成交易行为时，互联网金融账户内的余额。

历史交易记录可以包括交易时间戳，历史交易记录所包含的交易时间戳都是小于或等于结算时间戳的，且获取的至少一个历史交易记录是连续，不中断的交易记录。获取的至少一个历史交易记录必须要有连续性是因为：后续需要从后往前计算每笔历史交易记录的交易剩余量，只有连续的历史交易记录才能准确计算出交易剩余业务量。

获取的历史交易记录可以理解为结算时间戳之前的交易记录。

步骤S103，根据基准剩余业务量确定每个历史交易记录分别对应的交易剩余业务量。

具体的，互联网金融客户端以基准剩余业务量为基准，按照交易时间戳从后往前依次反推每一笔历史交易记录的交易剩余业务量(如上述图2a-图2d对应实施例中的交易后余额)，具体过程如下：

互联网金融客户端从获取的至少一个历史交易记录中提取具有最大交易时间戳的历史交易记录，将提取的历史交易记录作为第一历史交易记录，将剩余的历史交易记录均作为第二历史交易记录。

互联网金融客户端将基准剩余业务量作为第一历史交易记录的交易剩余业务量，这是因为第一历史交易记录是多个历史交易记录中的最后一个历史交易记录，而基准剩余业务量又是最后一个历史交易记录完成后，所结算的剩余业务量，因此基准剩余业务量就是第一历史交易记录的交易剩余业务量。

下面分别确定每个第二历史交易的交易剩余业务量：

每个历史交易记录除了包括交易时间戳以外，还包括交易类型和交易业务量，交易类型包括业务量输入类型和业务量输出类型，业务量输入类型或者业务量输出类型是从互联网金融可客户端的角度来定义的。

交易业务量是指本次交易的数额。

例如，目标用户将资源数据从银行账户转移至互联网金融账户，以申购金融产品，那么这个交易的交易类型就是业务量输入类型；目标用户将资源数据从互联网金融账户转移至银行账户，以赎回金融产品，那么这个交易的交易类型就是业务量输出类型。

互联网金融客户端按照交易时间戳的大小，为每个第二历史交易记录分别设置轮询优先级，其中交易时间戳越大，轮询优先级就越高。

互联网金融客户端从所有的第二历史交易记录中选择具有最高轮询优先级的第二历史交易记录，将选择出来的第二历史交易记录作为目标历史交易记录。

获取第一历史交易记录的交易类型(称为目标交易类型)和交易业务量(称为目标交易业务量)，若目标交易类型是业务量输入类型，那么互联网金融客户端可以用基准剩余业务量减去目标交易业务量，得到的差值作为目标历史交易记录的交易剩余业务量。

若目标交易类型是业务量输出类型，那么互联网金融客户端可以用基准剩余业务量与目标交易业务量相加，得到的和作为目标历史交易记录的交易剩余业务量。

至此，就确定了与第一历史交易记录相邻的一个第二历史交易记录的交易剩余业务量，将目标历史交易记录作为新的第一历史交易记录，将上述计算出来的目标历史交易记录的交易剩余业务量作为新的基准剩余业务量。

从剩余的第二历史交易记录中选择下一个具有最高轮询优先级的第二历史交易记录，作为新的目标历史交易记录。

第二次循环开始：再提取新的第一历史交易记录(即是前述中的目标历史交易记录)中的目标交易类型和目标交易业务量，根据新的目标交易类型和目标交易业务量确定当前新的目标历史交易记录的剩余业务量。

至此，就确定了与新的第一历史交易记录相邻的一个第二历史交易记录的交易剩余业务量，将新的目标历史交易记录又作为新的第一历史交易记录，将上述计算出来的目标历史交易记录的交易剩余业务量作为新的基准剩余业务量。

不断循环，当所有的第二历史交易记录都被作为目标历史交易记录时，停止轮询，说明此时互联网金融客户端已经计算出了所有的第二历史交易记录的交易剩余业务量。

举例来说，若获取到4笔历史交易记录(参见下述表1)，且结算时间戳为15:00:00，基准剩余业务量为100。

表1

序号	交易时间戳	交易类型	交易业务量
				4	14:49	业务量输出类型	10
3	10:30	业务量输入类型	50
				2	10:20	业务量输出类型	10
1	10:10	业务量输入类型	70

首先将上述4笔历史交易记录划分为第一历史交易记录和3个第二历史交易记录，其中序号为4的历史交易记录是第一历史交易记录，其余的3个历史交易记录都是第二历史交易记录。

由于基准剩余业务量为100，因此第一历史交易记录(即序号为4的历史交易记录)的交易剩余业务量为100。

根据交易时间戳，为3个第二历史交易记录设置轮询优先级，其中序号为3的第二历史交易记录的轮询优先级大于序号为2的第二历史交易记录的轮询优先级，序号为2的第二历史交易记录的轮询优先级大于序号为1的第二历史交易记录的轮询优先级。

首先提取出序号为3的第二历史交易记录作为目标历史交易记录，由于第一历史交易记录(即序号为4的历史交易记录)的交易类型为输出类型，且业务交易量为10，因此，此时的目标历史交易记录(即序号为3的第二历史交易记录)的交易剩余业务量＝基准剩余业务量+第一历史交易记录的交易业务量＝100+10＝110。

将目标历史交易记录的交易剩余业务量作为新的基准剩余交易量(新的基准剩余交易量为110)，将目标历史交易记录作为新的第一历史交易记录(此时第一历史交易记录是序号为3的历史交易记录)。

再提取出序号为2的第二历史交易记录作为目标历史交易记录，由于第一历史交易记录(即序号为3的历史交易记录)的交易类型为输入类型，且业务交易量为50，因此，此时的目标历史交易记录(即序号为2的第二历史交易记录)＝基准剩余业务量-第一历史交易记录的交易业务量＝110-50＝60。

将目标历史交易记录的交易剩余业务量作为新的基准剩余交易量(新的基准剩余交易量为60)，将目标历史交易记录作为新的第一历史交易记录(此时第一历史交易记录是序号为2的历史交易记录)。

再提取出序号为1的第二历史交易记录作为目标历史交易记录，由于第一历史交易记录(即序号为2的历史交易记录)的交易类型为输出类型，且业务交易量为10，因此，此时的目标历史交易记录(即序号为1的第二历史交易记录)＝基准剩余业务量+第一历史交易记录的交易业务量＝60+10＝70。

至此，4个历史交易记录的交易剩余业务量都确定完毕，停止循环。

综上，序号为4的历史交易记录的交易剩余业务量为100；序号为3的历史交易记录的交易剩余业务量为110；序号为2的历史交易记录的交易剩余业务量为60；序号为1的历史交易记录的交易剩余业务量为70。

可选的，历史交易记录除了可以包括交易时间戳以外，还可以包括交易业务量以及交易摘要，交易摘要用于标识交易对象和/或交易原因，交易摘要可以是：消费、二维码付款、收益入账、申购、快递支付、超市支付、转账等。历史交易记录可以是从云服务器拉取的。

互联网金融客户端响应于目标用户的交易记录显示请求，将每个交易剩余业务量分别添加至与之对应的历史交易记录中，得到更新后的历史交易记录(如上述图2a-图2d对应实施例中的交易记录20a)。

或者互联网金融客户端预先将每个交易剩余业务量分别添加至与之对应的历史交易记录中，得到更新后的历史交易记录。待接收到目标用户的交易记录显示请求时，就直接显示更新后的历史交易记录，这样可以减少目标用户等待的时间。

至此，每一个历史交易记录至少包括：交易时间戳、交易剩余业务量、交易业务量以及交易摘要。

互联网金融客户端可以按照预设的版式显示更新后的所有历史交易记录，或者，目标用户可以从上述历史交易记录中选择想要显示的历史交易记录，例如，只显示近半年的历史交易记录。

互联网金融客户端还可以将更新后的历史交易记录上传至云服务器，以使云服务器更新上述历史交易记录，使得云服务器中所存储的历史交易记录和互联网金融客户端中所存储的历史交易记录一致。

当本申请应用于金融领域，本申请中的历史交易记录可以为用户历史交易单，更新用户历史交易单的具体过程为请参见下述图6，是本申请实施例提供的一种更新用户历史交易单的交互示意图，交互过程包括云服务器、用户数据库、收益数据库以及账单系统：

步骤S301，云服务器从用户数据库中拉取当前所有有效用户。

步骤S302，云服务器依次遍历每一个有效用户。

步骤S303，云服务器从收益数据库中读取用户基准余额，确定用户基准余额的具体过程可以参见上述图5对应实施例中的步骤S203-步骤S205。

步骤S304，云服务器从账单系统中拉取用户历史交易单，用户历史交易单可以对应前述中的历史交易记录。

步骤S305，云服务器按照用户历史交易单的交易时间戳，将用户历史交易单按照时间倒序排序，逐笔反推每一个用户历史交易单的交易后余额。

具体的，对每个用户历史交易单作反向操作，申购、收益、转入做减操作；赎回、消费、转出等做加操作。

步骤S306，将交易后余额添加至用户历史交易单，以更新用户历史交易单。更新后的用户历史交易单中包括交易后余额。

上述可知，以一个时间点为基准，确定用户在该时间点的剩余业务量，从该时间点往前确定该用户的每一个历史交易记录的剩余业务量，采用本申请，可以获取到历史交易完成时的剩余业务量，不仅可以丰富历史交易记录的数据种类，还可以通过剩余业务量直观表达用户的历史资产情况。

本申请中的历史交易记录可以存储在区块链上，因此本申请可以应用于区块链(Block chain)场景下。区块链是分布式数据存储、点对点传输(P2P，Peer To Peer)、共识机制、加密算法等计算机技术的新型应用模式。区块链本质上是一个去中心化的数据库，是一串使用密码学方法相关联产生的数据块，每一个数据块中包含了一个或多个交易信息，用于验证其信息的有效性(防伪)和生成下一个区块。

请参见图7，是本申请实施例提供的一种区块链的系统架构图。前述实施例中的互联网金融客户端所在的终端设备可以为图7中的节点1、或节点2或节点3或节点4，所有的节点可以组合为区块链系统，每个节点都包括硬件层、中间层、操作系统层和应用层。从图7中可以看出，区块链系统的中的每个节点所存储的区块链数据都相同。可以知道，上述节点可以包括计算机设备。下述实施例以区块链节点为执行主体进行描述：

请一并参见图8，是本申请实施例提供的一种交易数据处理的流程示意图，交易数据处理方法包括如下步骤：

步骤S401，区块链节点获取目标用户在结算时间戳的基准剩余业务量。

其中，步骤S401的具体过程可以参见上述图3对应实施例中的步骤S101，执行主体由互联网金融客户端调整为区块链节点即可。

步骤S402，区块链节点获取业务区块链；业务区块链包括至少一个目标业务区块，至少一个目标业务区块中每个目标业务区块用于存储目标用户的历史交易记录，历史交易记录包括交易时间戳，每个历史交易记录包括的交易时间戳均小于或等于结算时间戳。

具体的，区块链节点获取业务区块链，业务区块链包括至少一个目标业务区块，每个目标业务区块是用于存储目标用户的历史交易记录，且每个历史交易记录的交易时间戳都小于或等于结算时间戳。

步骤S403，区块链节点从业务区块链中获取至少一个目标业务区块，从至少一个目标业务区块的区块体中分别读取至少一个历史交易记录。

具体的，业务区块链包括多个业务区块，从业务区块链中获取与目标用户相关联的至少一个业务区块，均称为原始业务区块，每个原始业务区块是用于存储目标用户的原始交易记录，且每个原始交易记录均包括交易时间戳。

区块链节点从获取预设的业务时长，采用结算时间戳减去业务时长，所确定的时间戳为业务时间戳，当然业务时间戳是小于结算时间戳的。

举例来说，结算时间戳为：2020/1/1 15:00:00，若预设的业务时长为10小时，那么业务时间戳为：2020/1/1 5:00:00。

区块链节点将交易时间戳处于业务时间戳和结算时间戳区间内的原始交易记录所对应的原始业务区块，均作为目标业务区块，从目标业务区块中读取原始交易记录，将读取的原始交易记录均作为历史交易记录。

需要说明的是，只要目标用户在区块链节点中发生了交易行为，区块链节点实时生成原始交易记录，并上链。当然此时生成的原始交易记录是不包括交易剩余业务量的，为了确定每一笔原始交易记录的交易剩余业务量，因此采用目标用户在距离当前最近的对账时间戳(即是结算时间戳)的基准剩余业务量，反推回结算时间戳之前的每一笔原始交易的交易剩余业务量。

依托于区块链的完整以及不可篡改属性，可以保证获取到的历史交易记录是可信的，以增加用户的信任度。

步骤S404，区块链节点根据基准剩余业务量确定每个历史交易记录分别对应的交易剩余业务量。

其中，步骤S404的具体过程可以参见上述图3对应实施例中的步骤S103，执行主体由互联网金融客户端调整为区块链节点即可。

上述可知，以一个时间点为基准，确定用户在该时间点的剩余业务量，从该时间点往前确定该用户的每一个历史交易记录的剩余业务量，采用本申请，可以获取到历史交易完成时的剩余业务量，不仅可以丰富历史交易记录的数据种类，还可以通过剩余业务量直观表达用户的历史资产情况。

进一步的，请参见图9，是本申请实施例提供的一种交易数据处理装置的结构示意图。如图9所示，交易数据处理装置1可以应用于上述图3-图8对应实施例中的互联网金融客户端所在的终端设备，具体应用于互联网金融客户端。

交易数据处理装置1可以包括：第一获取模块11、第二获取模块12以及确定模块13。

第一获取模块11，用于获取目标用户在结算时间戳的基准剩余业务量；

第二获取模块12，用于获取目标用户的至少一个历史交易记录，历史交易记录包括交易时间戳，至少一个历史交易记录中每个历史交易记录包括的交易时间戳均小于或等于结算时间戳；

确定模块13，用于根据基准剩余业务量确定每个历史交易记录分别对应的交易剩余业务量。

其中，第一获取模块11、第二获取模块12以及确定模块13的具体功能实现方式可以参见上述图3对应实施例中的步骤S101-步骤S103，这里不再进行赘述。

请参见图9，第一获取模块11可以包括：第一获取单元111以及第二获取单元112。

第一获取单元111，用于获取目标用户的至少一个关联业务对象；

第二获取单元112，用于分别获取每个关联业务对象在结算时间戳对应的单位剩余业务量；

第一获取单元111，还用于将至少一个单位剩余业务量叠加为基准剩余业务量；

第二获取单元112，具体用于接收结算终端发送的关联业务对象在结算时间戳对应的第一剩余业务量，从本地文件中获取关联业务对象在结算时间戳对应的第二剩余业务量，若第一剩余业务量和第二剩余业务量相同，则将第一剩余业务量确定为关联业务对象在结算时间戳对应的单位剩余业务量。

其中，第一获取单元111以及第二获取单元112的具体过程可以参见上述图3对应实施例中的步骤S101。

请参见图9，确定模块13可以包括：划分单元131、第一确定单元132以及第二确定单元133。

划分单元131，用于将至少一个历史交易记录划分为第一历史交易记录和至少一个第二历史交易记录；第一历史交易记录是至少一个历史交易记录中具有最大交易时间戳的历史交易记录；至少一个第二历史交易记录是至少一个历史交易记录中除第一历史交易记录以外的历史交易记录；

第一确定单元132，用于将基准剩余业务量作为与第一历史交易记录对应的交易剩余业务量；

第二确定单元133，用于根据基准剩余业务量，确定与每个第二历史交易记录分别对应的交易剩余业务量；

其中，划分单元131、第一确定单元132以及第二确定单元133的具体过程可以参见上述图3对应实施例中的步骤S103。

请参见图9，每个历史记录均包括交易类型和交易业务量；

第二确定单元133还可以包括：设置子单元1331、获取子单元1332以及确定子单元1333。

设置子单元1331，用于根据每个第二历史交易记录的交易时间戳，为每个第二历史交易记录分别设置轮询优先级，从至少一个第二历史交易记录中选择具有最高轮询优先级的第二历史交易记录，将选择的第二历史交易记录作为目标历史交易记录；

获取子单元1332，用于获取第一历史交易记录的目标交易类型和目标交易业务量；

确定子单元1333，用于根据目标交易类型、目标交易业务量以及基准剩余业务量确定与目标历史交易记录对应的交易剩余业务量；

获取子单元1332，还用于将目标历史交易记录作为第一历史交易记录，将与目标历史交易记录对应的交易剩余业务量作为基准剩余业务量，从剩余的第二历史交易记录中选择下一个用于轮询的目标历史交易记录，当所有的第二历史交易记录均被作为目标历史交易记录时，停止轮询；

目标交易类型包括业务量输入类型和业务量输出类型；

确定子单元1333，具体用于若目标交易类型为业务量输入类型，则将基准剩余业务量和目标交易业务量相减为与目标历史交易记录对应的交易剩余业务量，若目标交易类型为业务量输出类型，则将基准剩余业务量和目标交易业务量叠加为与目标历史交易记录对应的交易剩余业务量。

其中，设置子单元1331、获取子单元1332以及确定子单元1333的具体过程可以参见上述图3对应实施例中的步骤S103。

再参见图9，第二获取模块12可以包括：第三获取单元121以及读取单元122。

第三获取单元121，用于获取业务区块链；业务区块链包括至少一个目标业务区块，至少一个目标业务区块中每个目标业务区块用于存储目标用户的历史交易记录；

读取单元122，用于从业务区块链中获取至少一个目标业务区块；

第三获取单元121，还用于从至少一个目标业务区块的区块体中分别读取至少一个历史交易记录；

读取单元122，具体用于从业务区块链中获取与目标用户相关联的至少一个原始业务区块，至少一个原始业务区块中每个原始业务区块用于存储目标用户的原始交易记录；原始交易记录包括交易时间戳，获取业务时长，根据业务时长和结算时间戳确定业务时间戳；业务时间戳小于结算时间戳，将交易时间戳处于业务时间戳和结算时间戳区间内的原始交易记录所对应的原始业务区块，作为目标业务区块。

其中，第三获取单元121以及读取单元122的具体过程可以参见上述图8对应实施例中的步骤S402-步骤S403。

请再参见图9，至少一个历史交易记录从云服务器拉取的；每个历史交易记录均包括交易业务量以及交易摘要；

交易数据处理装置1可以包括：第一获取模块11、第二获取模块12以及确定模块13，还可以包括：更新模块14。

更新模块14，用于响应于目标用户的交易记录显示请求，将至少一个交易剩余业务量分别添加至至少一个历史交易记录，显示更新后的历史交易记录，并将更新后的历史交易记录上传至云服务器，指示云服务器更新至少一个历史交易记录。

其中，更新模块14的具体过程可以参见上述图3对应实施例中的步骤S103。

进一步地，请参见图10，是本发明实施例提供的一种计算机设备的结构示意图。上述图3-图8对应实施例中的互联网金融客户端所在的终端设备可以为计算机设备1000，如图10所示，计算机设备1000可以包括：用户接口1002、处理器1004、编码器1006以及存储器1008。信号接收器1016用于经由蜂窝接口1010、WIFI接口1012、...、或NFC接口1014接收或者发送数据。编码器1006将接收到的数据编码为计算机处理的数据格式。存储器1008中存储有计算机程序，处理器1004被设置为通过计算机程序执行上述任一项方法实施例中的步骤。存储器1008可包括易失性存储器(例如，动态随机存取存储器DRAM)，还可以包括非易失性存储器(例如，一次性可编程只读存储器OTPROM)。在一些实例中，存储器1008可进一步包括相对于处理器1004远程设置的存储器，这些远程存储器可以通过网络连接至计算机设备1000。用户接口1002可以包括：键盘1018和显示器1020。

在图10所示的计算机设备1000中，处理器1004可以用于调用存储器1008中存储计算机程序，以实现：

获取目标用户在结算时间戳的基准剩余业务量；

获取目标用户的至少一个历史交易记录，历史交易记录包括交易时间戳，至少一个历史交易记录中每个历史交易记录包括的交易时间戳均小于或等于结算时间戳；

根据基准剩余业务量确定每个历史交易记录分别对应的交易剩余业务量。

应当理解，本发明实施例中所描述的计算机设备1000可执行前文图3到图8所对应实施例中对交易数据处理方法的描述，也可执行前文图9所对应实施例中对交易数据处理装置1的描述，在此不再赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。

此外，这里需要指出的是：本发明实施例还提供了一种计算机存储介质，且计算机存储介质中存储有前文提及的交易数据处理装置1所执行的计算机程序，且该计算机程序包括程序指令，当处理器执行上述程序指令时，能够执行前文图3到图8所对应实施例中对交易数据处理方法的描述，因此，这里将不再进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。对于本发明所涉及的计算机存储介质实施例中未披露的技术细节，请参照本发明方法实施例的描述。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，上述程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，上述存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random AccessMemory，RAM)等。

以上所揭露的仅为本发明较佳实施例而已，当然不能以此来限定本发明之权利范围，因此依本发明权利要求所作的等同变化，仍属本发明所涵盖的范围。

Claims (12)

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

获取目标用户在结算时间戳的基准剩余业务量；

获取所述目标用户的至少一个历史交易记录，所述历史交易记录包括交易时间戳，所述至少一个历史交易记录中每个历史交易记录包括的交易时间戳均小于或等于所述结算时间戳；

根据所述基准剩余业务量确定所述每个历史交易记录分别对应的交易剩余业务量。

2.根据权利要求1所述的方法，其特征在于，所述获取目标用户在结算时间戳的基准剩余业务量，包括：

获取所述目标用户的至少一个关联业务对象；

分别获取每个关联业务对象在所述结算时间戳对应的单位剩余业务量；

将至少一个单位剩余业务量叠加为所述基准剩余业务量。

3.根据权利要求2所述的方法，其特征在于，所述分别获取每个关联业务对象在所述结算时间戳对应的单位剩余业务量，包括：

接收结算终端发送的关联业务对象在所述结算时间戳对应的第一剩余业务量；

从本地文件中获取所述关联业务对象在所述结算时间戳对应的第二剩余业务量；

若所述第一剩余业务量和所述第二剩余业务量相同，则将所述第一剩余业务量确定为所述关联业务对象在所述结算时间戳对应的单位剩余业务量。

4.根据权利要求1所述的方法，其特征在于，所述根据所述基准剩余业务量确定所述每个历史交易记录分别对应的交易剩余业务量，包括：

将所述至少一个历史交易记录划分为第一历史交易记录和至少一个第二历史交易记录；所述第一历史交易记录是所述至少一个历史交易记录中具有最大交易时间戳的历史交易记录；所述至少一个第二历史交易记录是所述至少一个历史交易记录中除所述第一历史交易记录以外的历史交易记录；

将所述基准剩余业务量作为与所述第一历史交易记录对应的交易剩余业务量；

根据所述基准剩余业务量，确定与所述每个第二历史交易记录分别对应的交易剩余业务量。

5.根据权利要求4所述的方法，其特征在于，每个历史记录均包括交易类型和交易业务量；

所述根据所述基准剩余业务量，确定与所述每个第二历史交易记录分别对应的交易剩余业务量，包括：

根据所述每个第二历史交易记录的交易时间戳，为所述每个第二历史交易记录分别设置轮询优先级；

从所述至少一个第二历史交易记录中选择具有最高轮询优先级的第二历史交易记录，将选择的第二历史交易记录作为目标历史交易记录；

获取所述第一历史交易记录的目标交易类型和目标交易业务量；

根据所述目标交易类型、所述目标交易业务量以及所述基准剩余业务量确定与所述目标历史交易记录对应的交易剩余业务量；

将目标历史交易记录作为所述第一历史交易记录，将与所述目标历史交易记录对应的交易剩余业务量作为所述基准剩余业务量；

从剩余的第二历史交易记录中选择下一个用于轮询的目标历史交易记录；

当所有的第二历史交易记录均被作为所述目标历史交易记录时，停止轮询。

6.根据权利要求5所述的方法，其特征在于，所述目标交易类型包括业务量输入类型和业务量输出类型；

所述根据所述目标交易类型、所述目标交易业务量以及所述基准剩余业务量确定与所述目标历史交易记录对应的交易剩余业务量，包括：

若所述目标交易类型为所述业务量输入类型，则将所述基准剩余业务量和所述目标交易业务量相减为与所述目标历史交易记录对应的交易剩余业务量；

若所述目标交易类型为所述业务量输出类型，则将所述基准剩余业务量和所述目标交易业务量叠加为与所述目标历史交易记录对应的交易剩余业务量。

7.根据权利要求1所述的方法，其特征在于，所述获取所述目标用户的至少一个历史交易记录，包括：

获取业务区块链；所述业务区块链包括至少一个目标业务区块，所述至少一个目标业务区块中每个目标业务区块用于存储所述目标用户的历史交易记录；

从所述业务区块链中获取所述至少一个目标业务区块，从所述至少一个目标业务区块的区块体中分别读取所述至少一个历史交易记录。

8.根据权利要求7所述的方法，其特征在于，所述从所述业务区块链中获取所述至少一个目标业务区块，包括：

从所述业务区块链中获取与所述目标用户相关联的至少一个原始业务区块，所述至少一个原始业务区块中每个原始业务区块用于存储所述目标用户的原始交易记录；所述原始交易记录包括交易时间戳；

获取业务时长，根据所述业务时长和所述结算时间戳确定业务时间戳；所述业务时间戳小于所述结算时间戳；

将交易时间戳处于所述业务时间戳和所述结算时间戳区间内的原始交易记录所对应的原始业务区块，作为目标业务区块。

9.根据权利要求1所述的方法，其特征在于，所述至少一个历史交易记录从云服务器拉取的；所述每个历史交易记录均包括交易业务量以及交易摘要；

所述方法还包括：

响应于所述目标用户的交易记录显示请求，将至少一个交易剩余业务量分别添加至所述至少一个历史交易记录；

显示更新后的历史交易记录，并将更新后的历史交易记录上传至所述云服务器，指示所述云服务器更新所述至少一个历史交易记录。

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

第一获取模块，用于获取目标用户在结算时间戳的基准剩余业务量；

第二获取模块，用于获取所述目标用户的至少一个历史交易记录，所述历史交易记录包括交易时间戳，所述至少一个历史交易记录中每个历史交易记录包括的交易时间戳均小于或等于所述结算时间戳；

确定模块，用于根据所述基准剩余业务量确定所述每个历史交易记录分别对应的交易剩余业务量。

11.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，所述计算机程序被所述处理器执行时，使得所述处理器执行如权利要求1-9中任一项所述方法的步骤。

12.一种计算机存储介质，其特征在于，所述计算机存储介质存储有计算机程序，所述计算机程序包括程序指令，所述程序指令当被处理器执行时，执行如权利要求1-9任一项所述的方法。

Images