CN113627934A - 一种交易数据获取方法及相关设备 - Google Patents

Abstract

本申请提出了一种交易数据获取方法及相关设备，在执行针对权益账户的目标交易过程中，通常会对权益账户进行多次操作，使得其中某些业务数据发生变动，为了方便后续准确定位异常，本申请将会记录该目标交易执行期间产生的该权益账户的业务变动数据，即记录数据层面的交易信息，并在检测到目标交易执行成功时，将由该业务变动数据生成的交易数据上报至数据库存储，以供后续查询并准确定位导致客户端权益变化或使用异常等问题的业务变动数据，相对于人工一一排查的手动查询方法，大大降低了人工成本，且提高了查询效率和精准度，有助于提高客户体验感受。

Description

一种交易数据获取方法及相关设备

技术领域

本申请涉及数据处理技术领域，更具体地说是涉及一种交易数据获取方法及相关设备。

背景技术

在如银行等金融机构的管理应用中，为了保障银行和客户的权益，通常需要准确记录每次交易的相关数据，如获取交易请求的交易层面数据，如交易双方、交易日期、报文等信息，作为本次交易的交易数据上报至数据库存储，以便后续业务人员或客户查询。

然而，在实际应用中，由于一次交易过程，通常会对客户的权益账户进行多次操作，导致客户权益发生多次改变，导致依据目前所记录的交易层面的交易数据，是很难追溯到导致某权益无法正常使用的原因，往往需要业务人员依据业务规则进行人工逐一排查，极大增加了业务人员的工作量，且查询效率往往比较低，降低了客户体验感受。

发明内容

有鉴于此，为了解决上述技术问题，本申请提供了以下技术方案：

本申请提出了一种交易数据获取方法，所述方法包括：

响应针对权益账户的交易请求，执行所请求的目标交易；

记录所述目标交易执行期间产生的所述权益账户的业务变动数据；

检测到所述目标交易执行成功，由记录的所述业务变动数据生成所述交易请求的交易数据；

将所述交易数据上报至数据库存储。

可选的，所述记录所述目标交易执行期间产生的所述权益账户的业务变动数据，包括：

在所述目标交易执行期间，获取对所述权益账户信息的每一次操作，产生的所述权益账户的业务变动数据；

由每一次操作产生的所述业务变动数据，生成相应的一条账户变动消息进行缓存。

可选的，所述由记录的所述业务变动数据生成所述交易请求的交易数据，包括：

对所述目标交易对应的多条所述账户变动消息进行合并封装处理，得到具有预设消息格式的一条交易数据；

将所述交易数据发送至缓存队列进行存储。

可选的，所述将所述交易数据上报至数据库存储，包括：

按照数据提交策略，获取所述缓存队列存储的所述交易数据；

将获取的所述交易数据包含的所述业务变动数据上报至数据库存储。

可选的，所述按照数据提交策略，获取所述缓存队列存储的所述交易数据，包括：

获取所述缓存队列在预设时长内存储的所述交易数据；所述预设时长是指距离当前时间的时长；

或者，

检测到所述缓存队列存储的所述交易数据的数量达到预设条数，获取所述缓存队列存储的所述预设条数的所述交易数据。

可选的，所述业务变动数据包括对所述权益账户信息的一次操作所产生的，操作前后相应业务的状态信息、该操作的操作类型以及所述目标交易的交易标识、交易类型；

所述响应针对权益账户的交易请求，执行所请求的目标交易，包括：

响应针对权益账户的联机交易请求，执行所述请求的目标交易；或者，

响应针对不同权益账户的批处理交易请求，执行所述批处理交易请求各自所请求的目标交易。

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

检测到所述目标交易执行失败，依据记录的所述业务变动数据，撤销所述目标交易执行期间对所述权益账户信息的操作。

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

响应针对所述目标交易的异常检测请求；

从数据库调取与所述目标交易对应的交易数据；

对所述交易数据包含的多条所述业务变动数据分别进行异常检测，确定异常业务变动数据；

依据所述异常业务变动数据，获得异常检测结果；

将所述异常检测结果与执行所述目标交易的权益账户关联，反馈至登录所述权益账户的客户端输出。

本申请还提出了一种交易数据获取装置，所述装置包括：

交易执行模块，用于响应针对权益账户的交易请求，执行所请求的目标交易；

业务变动数据记录模块，用于记录所述目标交易执行期间产生的所述权益账户的业务变动数据；

交易数据生成模块，用于检测到所述目标交易执行成功，由记录的所述业务变动数据生成所述交易请求的交易数据；

交易数据上报模块，用于将所述交易数据上报至数据库存储。

本申请还提出了一种计算机设备，所述计算机设备包括：至少一个通信接口、至少一个存储器和至少一个处理器，其中：

所述存储器，用于存储实现如上述的交易数据获取方法的程序；

所述处理器，用于加载并执行所述存储器存储的所述程序，以实现如上述的交易数据获取方法。

本申请还提出了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器调用并执行，实现如上文描述的交易数据获取方法。

由此可见，本申请实施例提出了一种交易数据获取方法及相关设备，在执行针对权益账户的目标交易过程中，通常会对权益账户进行多次操作，使得其中某些业务数据发生变动，为了方便后续准确定位异常，本申请将会记录该目标交易执行期间产生的该权益账户的业务变动数据，即记录数据层面的交易信息，并在检测到目标交易执行成功时，将由该业务变动数据生成的交易数据上报至数据库存储，以供后续查询并准确定位导致客户端权益变化或使用异常等问题的业务变动数据，相对于人工一一排查的手动查询方法，大大降低了人工成本，且提高了查询效率和精准度，有助于提高客户体验感受。

附图说明

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

图1示出了本申请提出的交易数据获取方法的一可选示例的流程示意图；

图2示出了本申请提出的交易数据获取方法的又一可选示例的流程示意图；

图3示出了本申请提出的交易数据获取方法的又一可选示例的流程示意图；

图4示出了本申请提出的交易数据获取装置的一可选示例的结构示意图；

图5示出了本申请提出的交易数据获取装置的又一可选示例的结构示意图；

图6示出了本申请提出的交易数据获取装置的又一可选示例的结构示意图；

图7为适用于本申请提出的交易数据获取方法和装置的计算机设备的一可选示例的硬件结构示意图。

具体实施方式

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

需要说明的是，为了便于描述，附图中仅示出了与有关发明相关的部分。在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

应当理解，本申请中使用的“系统”、“装置”、“单元”和/或“模块”是用于区分不同级别的不同组件、元件、部件、部分或装配的一种方法。然而，如果其他词语可实现相同的目的，则可通过其他表达来替换该词语。

如本申请和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的步骤和元素，而这些步骤和元素不构成一个排它性的罗列，方法或者设备也可能包含其它的步骤或元素。由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

其中，在本申请实施例的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，在本申请实施例的描述中，“多个”是指两个或多于两个。以下术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。

另外，本申请中使用了流程图用来说明根据本申请的实施例的系统所执行的操作。应当理解的是，前面或后面操作不一定按照顺序来精确地执行。相反，可以按照倒序或同时处理各个步骤。同时，也可以将其他操作添加到这些过程中，或从这些过程移除某一步或数步操作。

参照图1，为本申请提出的交易数据获取方法的一可选示例的流程示意图，该方法可以适用于计算机设备，该交计算机设备可以是如银行等金融机构的服务设备或者是具有一定数据处理能力的业务终端。其中，该服务设备可以是独立的物理服务器，也可以是多台物理服务器集成的服务器集群，还可以是具有云计算能力的云服务器等；业务终端可以包括但并不局限于笔记本电脑、平板电脑、台式电脑等电子设备，本申请对计算机设备的产品形式不做限制，可视情况而定。

如图1所示，本申请实施例提出的交易数据获取方法可以包括但并不局限于以下步骤：

步骤S11，响应针对权益账户的交易请求，执行所请求的目标交易；

在实际应用中，在用户发起针对其权益账户的交易请求的场景下，如参加能够获取某项权益的活动等，计算机设备接收到该交易请求后，可以按照该交易请求的请求内容，执行所请求的目标交易，具体执行内容可以依据该交易请求内容确定，本申请对此不作限制。

示例性的，如某第三方服务商在其应用平台提出绑定个人银行卡，可以免费领取xxx面值的优惠券；在银行应用平台上在线充值可以享受九五折优惠；将其具有的某一项权益转增给其他权益账户等活动中，用户提出相应申请后，业务终端响应该申请可以生成针对该用户的相应权益账户(如)的交易请求，如该权益账户与第三方应用平台的账户绑定，给该账户发放优惠券等；按照优惠活动扣除权益账户的扣账金额，利用所得充值金额更新被充值的充值账户的余额等；取消被转赠用户的权益账户所拥有的相应权益，更新转增对象的权益账户的相应业务配置信息，以使得转增对象的权益账户具有该项权益等，本申请对目标交易的执行过程及内容不做详述。

需要说明的是，对于针对权益账户的交易请求，包括但并不局限于上文描述的交易场景和内容，涉及到权益账户的权益变化的各交易场景均适用于本申请提出的交易数据获取方法，本申请不做一一列举。

步骤S12，记录目标交易执行过程中产生的权益账户的业务变动数据；

继上文分析，目标交易执行过程中，往往会对权益账户的账户信息进行多次操作，导致相应的账户信息发生变化，影响该权益账户的相关权益，为了方便后续查询每一次导致权益变化或影响权益使用的影响因素，本申请实施例提出记录每一次导致权益账户变化的操作所产生的业务变动数据，如新增权益前后的该权益账户关联的相应业务数据(如新增权益前该权益账户的状态信息、新增权益内容及其有效期等数据，本申请对业务数据的内容不做限制，可视情况而定)、第三方服务商权益到帐通知信息等，本申请对该业务变动数据的内容不做限制，可以依据相应权益账户变化的操作内容确定。

可见，相对于目标交易过程中，记录交易层的交易内容，如交易日期、交易双方、交易报文等内容，本申请提出了对数据层面的交易内容进行检测记录，关于该数据层面的交易内容可以是目标交易执行过程中，涉及到的各业务数据表的业务变动数据，本申请对数据层面的交易内容及其记录方式等不做限制，可视情况而定。

本申请实施例中，在目标交易执行过程中，本申请除了按照上述方式记录数据层面的业务变动数据外，还可以记录交易层面的交易内容，以满足后续对整个目标交易过程涉及到的各类内容的查询。

步骤S13，检测到目标交易执行成功，由记录的业务变动数据生成交易请求的交易数据；

步骤S14，将交易数据上报至数据库进行存储。

如上文描述，本申请是在目标交易执行过程中，同步记录每一次交易操作所产生的关于权益账户的业务变动数据，直至该目标交易结束，在确定目标交易执行成功的情况下，可以由记录的该目标交易执行过程中，涉及到的权益账户的每一次操作对应产生的业务变动数据，生成本次交易请求的交易数据，即该目标交易的交易数据，本申请对该交易数据的内容及其格式不做限制。

在一些实施例中，上述交易数据除了包含上文记录的各操作对应产生的权益账户的业务变动数据外，还可以包括本次交易在交易层面上的交易内容，且为了方便后续从数据库中查询目标交易的交易数据，该交易数据可以携带该目标交易的交易标识，如交易流水号等唯一标识，便于用户快速了解交易内容的交易摘要(即详情概述)、交易类型以及涉及到的各操作的操作类型等，本申请对生成的交易数据内容不做限制，可视情况而定。

在得到每一个目标交易的交易数据后，可以按照预设通信协议要求将该交易数据上报至数据库进行存储，如将该交易数据封装成符合该通信协议要求格式的报文，再传输至数据库进行存储，本申请对数据库存储各交易的报文的存储方式不做限制。

应该理解的是，在上述交易请求是联机交易或批处理中某一交易的交易请求的场景下，对于每一个交易请求均可以按照上述方式进行处理，以得到各交易请求的交易数据后上报数据库存储。其中，对于批处理交易请求，为了避免不同交易之间的相互影响，可以对不同交易请求的权益账户的业务变动数据进行隔离，具体隔离实现方式不做限制。

综上所述，在执行针对权益账户的目标交易过程中，通常会对权益账户进行一次或多次操作，使得其中某些业务数据发生变动，为了方便后续准确定位异常，本申请将会记录该目标交易执行期间产生的该权益账户的业务变动数据，即记录数据层面的交易信息，并在检测到目标交易执行成功时，将由该业务变动数据生成的交易数据上报至数据库存储，以供后续查询并准确定位导致客户端权益变化或使用异常等问题的业务变动数据，相对于人工一一排查的手动查询方法，大大降低了人工成本，且提高了查询效率和精准度，有助于提高客户体验感受。

参照图2，为本申请提出的交易数据获取方法的又一可选示例的流程示意图，本实施例可以是对上文描述的交易数据获取方法的一可选细化实现方法，但并不局限于本实施例描述的这种细化实现方法。如图2所示，该方法可以包括：

步骤S21，响应针对权益账户的交易请求，执行所请求的目标交易；

在本申请实际应用中，针对权益账户的交易请求可以是联机交易请求，或者是批处理交易请求中的任一交易请求，本申请对该交易请求的类型及其获取方式不做限制，可视情况而定。

其中，联机交易是指系统对外直接提供的交易，该类交易具有事务性，可以回滚，即撤销本次交易操作等；且该类交易通常具有生命周期，并配置超时机制等，调用方(如用户客户端)需实时等待被调方(如数据库、计算机设备)的反馈(如调用成功或失败)，即在线等待反馈。在实际联机交易过程中，同一类甚至是同一个交易可以同时被多个线程调用，相互间有锁处理机制，该机制的应用及实现过程本申请不做详述。

可见，在响应的交易请求为联机交易的场景下，往往会对权益账户进行多次操作，本申请实施例主要对这种交易类型的应用场景下，如何获取数据层面的交易数据进行存储的实现过程进行描述，但并不限制具体联机交易类型。

对于上文批处理类型的交易请求，在实际应用中，通常是会先确定交易相关的参数、系统状态等，再对批处理的多个交易执行同一类操作。可以理解，该类操作具有统一性，使用相同的处理规则即可对批处理大量数据；通常情况下，批处理交易执行过程中，各步骤之间具有一定条件依赖性，当然各步骤也可以并发执行，可视情况而定。需要说明，对于批处理交易的交易请求响应过程中，批处理交易也可能会涉及权益账户变化的一次或多次操作步骤，因此，批处理交易请求也适用于本申请提出的交易数据获取方法，本申请对该方法适用的交易请求的交易类型不做限制。

步骤S22，在目标交易执行期间，获取对权益账户信息的每一次操作，产生的权益账户的业务变动数据；

以目标交易为上文描述的联机交易为例进行说明，如取款交易的联机交易场景，在取款交易过程中，可能会涉及到余额查询及更新、交易流水的生成、权益账户使用记录的生成、会计凭证的生成、存款及现金科目总账的登记等操作，若某一步骤产生异常，都可能会导致本次取款交易失败。所以，为了方便后续查询导致交易失败的原因，本申请可以在取款交易过程中，对涉及到权益账户变化的每一次操作，所产生的该权益账户的业务变动数据，如上文列举的各数据内容进行提取。

应该理解，对于其他类别的联机交易，所获取的业务变动数据往往不同，且针对取款交易所获取的业务变动数据包括但并不局限于上文列举的内容，本申请对不同交易执行过程中所产生的，表示权益账户变化的业务变化数据的内容不做限制，可视情况而定。

同理，对于批处理交易的场景下，目标交易可以是批处理的多个交易中的任一交易，在批处理交易执行过程中，将会获取每一个目标交易执行期间，表示相应权益账户变化的业务变动数据，获取过程类似，本申请不做详述。其中，可以理解，对于执行批处理交易，在批处理多个交易的每一次操作，可以产生批量的业务变动数据，分别对应批处理交易的相应权益账户。

步骤S23，由每一次操作产生的业务变动数据，生成相应的一条账户变动消息进行缓存；

在整个目标交易执行过程中，可能会产生大量业务变动数据，尤其是对于批处理交易的执行场景，为了方便后续查询不同操作对应的业务变动数据，对于获取的每一次操作的业务变动数据，本申请可以先缓存在交易层面的交易缓存模块中，即预设的业务变动数据缓存空间内。本申请对业务变动数据的缓存实现方法不做限制。

如上述分析，由于每一次引起权益账户变化的操作，都会获取该权益账户相应的业务变动数据，本申请实施例可以将每一次操作的每一个权益账户的业务变动数据，构成相应的账户变动消息，因此，对于同一目标交易来说，可以获得一条或多条账户变动消息，本申请对这些账户变动消息的消息格式及其缓存方式不做限制。

步骤S24，检测执行的目标交易是否交易成功；如果是，进入步骤S25；如果否，执行步骤S29；

随着目标交易的执行进度增多，所缓存的账户变动消息的数量可以逐渐增多，在确定目标交易执行完毕时，可以验证所执行的目标交易是否交易成功，本申请可以依据该目标交易的交易目的进行验证，如上述取款交易的场景，通过验证是否成功取款，来确定取款交易是否成功。

在一些实施例中，执行目标交易的最后一次操作后，若每次操作都成功，可以得到目标交易成功的成功提示信息；反之，存在操作失败的情况，可以得到目标交易失败的失败提示信息，这样，就可以检测最终得到的提示信息内容，确定目标交易是否成功，但并不局限于这种实现方法。

步骤S25，对目标交易对应的多条账户变动消息进行合并封装处理，得到具有预设消息格式的一条交易数据；

按照上述方法确定目标交易成功的情况下，若该目标交易执行过程中，获得了多条账户变动消息，为了保证交易数据完整性、传输可靠性以及数据一致性，需要对这多条账户变动消息进行一次性提交至消息组装模块，对这多条账户变动消息(即对应同一交易请求/目标交易标识的多条业务变动数据)进行合并整合成一条交易消息后，再按照预设通信协议要求，对整合后的一条交易消息进行封装处理，得到预设消息格式的一条交易数据。

需要说明，本申请对多条账户变动消息的合并整合方法不做限制，如可以直接按照执行时间顺序进行拼接等。对于批处理的多个目标交易各自对应的账户变动消息，可以按照上述方式进行合并封装处理，得到对应每一个批处理的目标交易对应的一条交易数据，实现过程不做赘述。

步骤S26，将该交易数据发送至缓存队列进行存储；

为了避免同一目标交易执行过程中产生的不同业务变动数据，一部分发送至缓存队列，另一部分向缓存队列发送过程中发送失败，导致数据库表变动记录不一致，如上文描述，本申请是将一笔交易的各业务变动数据合并生成一条交易数据后，再发送至缓存队列进行存储，保证同一笔交易的各业务变动数据都未发送至缓存队列，或者都发送到缓存队列，实现数据的一致性。而且，这种数据合并发送至缓存队列的交易数据获取方式，节省了调用缓存队列的操作步骤，压缩了交易时间，提高了交易数据获取效率。

在本申请实际应用中，对于上文处理得到的每一个目标交易对应的一条交易数据，可以按照该交易数据的生成时间顺序，顺次写入缓存队列进行存储，对于批量生成的多条交易数据，可以写入缓存队列的相邻单元。其中，该缓存队列可以是消息(MessageQueuing，MQ)队列，即一种先进先出的数据结构，本申请实施例可以将目标交易支持过程中，产生的交易数据缓存到消息队列中，以便后续其他服务监控该消息队列，调取所需的交易数据等。

步骤S27，按照数据提交策略，获取该缓存队列存储的交易数据；

在本申请实施例中，对于用于缓存交易数据的缓存队列，本申请可以周期性或实时对其进行扫描检测，确定该缓存队列中是否缓存有交易数据，若有，可以对缓存的该交易数据进行解析，得到相应的业务变动数据实体，并对其进行缓存，等待提交至数据库存储。

在又一些实施例中，对于缓存队列所缓存的交易数据的解析过程，也可以在确定要向数据库上报业务变动数据时进行解析处理，本申请对具有预设封装格式的交易数据的解析过程及其执行步骤不做限制，可视情况而定。

如上文分析，缓存队列可以存储每一笔目标交易对应的一条交易数据，受最大数据传输量的约束，为了保证数据传输效率和可靠性，本申请实施例提出可以对缓存队列所缓存的交易数据进行定时或定量的数据提交策略，也就是说，可以间隔预设时长后，将缓存队列所存储的一条或多条交易数据上报至数据库；或者将缓存队列所存储的预设条数的交易数据上报至数据库等，本申请对数据提交策略的内容不做限制，包括但并不局限于上文描述的定时或定量提交策略。

步骤S28，将获取的交易数据包含的业务变动数据上报至数据库进行存储；

继上文描述，在缓存队列存储的交易数据满足预设的数据缓存队列的情况下，可以向批量提交模块发送触发命令，以使其将符合预设数据提交策略的交易数据中的业务变动数据上报至数据库存储，如上文描述，可以对这些符合预设数据提交策略的交易数据分别进行解析，得到对应的业务变动数据，再上报至数据库。

步骤S29，依据缓存的业务变动数据，撤销目标交易执行期间对权益账户信息的操作。

无论是联机交易还是批处理交易，交易执行失败的情况下，为了保证数据一致性，本申请需要撤销该执行失败的目标交易执行过程中，对相应权益账户的改变，即恢复至该目标交易执行之前权益账户状态。因此，本申请实施例可以获取截止到目标交易执行失败时刻所缓存的业务变动数据，其可以表示在该目标交易执行过程中对权益账户的改变，所以，依据这些业务变动数据，可以撤销目标交易执行期间对权益账户信息的操作，即恢复到目标交易执行之前的权益账户信息。

结合上文对业务变动数据内容的相关描述，其可以包括权益账户修改前的权益数量、权益账户状态、权益有效期等信息，以及该权益账户修改后的权益数量、权益账户状态、权益有效期等信息，所以，在目标交易执行失败后，可以清空权益账户的业务变动数据，从而保证该权益账户的账户信息与目标交易执行前的信息一致，避免影响对该权益账户操作的准确性。

示例性的，若目标交易是用户参加的一种权益领取活动，在该目标交易执行过程中，即在活动参与过程中，该用户的权益账户可以获取新领取或赋予的权益，在该过程中，本申请会记录领取权益前该权益账户的账户信息，如所具有的权益相关信息等，领取到的该权益的相关信息，以及该权益对权益账户的相应业务数据的改变等内容；在后续业务配置过程中，可能会因业务配置错误导致该权益被撤回，即本次权益领取交易失败，这种情况下，需要清除该权益账户因领取到的该权益所记录的各业务变动数据，恢复至领取该权益之前该权益账户的状态。

若用户将领取到的权益转赠给其他用户的权益账户，需要记录该转赠操作导致该用户的权益账户的相关业务变动数据，以及获得该权益的该其他用户的权益账户的业务变动数据；若该领取到的权益具有一定有效期，在到达有效期后，该权益将失效，对于该检测结果，将会产生针对拥有该权益的权益账户的相应业务变动数据，以表面该权益账户的用户无法再享受该过期权益，依据未具有该权益的业务数据响应相关业务处理操作，具体实现过程本申请不做详述。

由此可见，本申请记录用户领取的某权益变化过程中，产生的相应业务部变动数据，形成一个关于该权益的完整的权益链，这样，在后续查询该权益变化的任一节点，可以直接定位到相应的业务变动数据，以满足应用查询需求。

按照上文描述的参与活动领取权益的实现过程，若用户参加多个活动领取相应的权益，并按照本申请提出的交易数据获取方法，记录权益领取及其使用过程中产生的业务变动数据，若其中某一权益的业务无法正常使用，在查询导致该权益无法使用的原因时，本申请不需要人工根据业务规则手动判断，是权益过期导致业务失效，还是因权益被撤回导致业务失效，本申请可以检测记录各操作对应的业务变动数据，快速且准确定位导致业务失效，权益无法使用的原因。

综上，在本申请实施例中，在联机或批处理交易执行过程中，对于引起相应权益账户变化的每一次操作，会获取该权益账户在数据层面的业务变动数据，在确定这笔目标交易执行成功后，将同一目标交易执行产生的所有业务变动数据合并成一条交易数据后，发送至缓存队列进行存储，从而将缓存队列所存储的满足数据提交策略的交易数据上报至数据库进行存储，以便后续出现涉及到这笔目标交易的某一权益问题时，可以自动对数据库中对应的业务变动数据进行查询，快速且精准定位导致客户端权益变化或使用异常等问题的原因，无需客户长时间等待业务人员手工排查，有助于提高客户体验感受。

而且，在上述目标交易执行过程中，因某些原因导致交易失败，对于在此之前对权益账户造成的改变，本申请将依据所记录的该权益账户的业务变动数据，撤销导致该权益账户状态变化的操作，从而使该权益账户的账户信息恢复至目标交易执行之前的状态，从而避免交易失败而造成的权益损失，保证权益账户信息的一致性。

参照图3，为本申请提出的交易数据获取方法的又一可选示例的流程示意图，本实施例是在上文实施例描述的交易数据获取方法的基础上，描述如何使用数据存储的权益账户的业务变动数据，追溯历史定位问题的可选实现方法，但并不局限于这种实现方式。如图3所示，终端或服务器等计算机设备执行交易数据获取方法过程中，还可以包括但并不局限于以下步骤：

步骤S31，响应于针对目标交易的异常检测请求；

在实际应用中，对于执行目标交易的权益账户的用户，在办理或使用相关业务过程中，若出现业务无法正常使用，无法享受相关权益的情况，可以在客户端的相应异常咨询界面进行异常申报，如选择出现异常的业务，根据需要还可以输入异常问题，点击提交异常按钮，从而生成针对目标交易的异常检测请求，更具地说可以是该目标交易涉及到的异常业务的异常检测请求等，将该异常检测请求发送至计算机设备，以请求获得异常检测结果。

在又一些实施例中，对于权益账户所拥有的各项业务之间，可能会存在一定的关联关系，如某一项业务运行过程中，可能会需要调用其他业务，这种情况下，无论是该业务自身的配置信息异常，或是所调用业务的配置信息异常，都可能会导致该业务异常，所以，在该业务运行过程中出现异常的情况下，为了明确导致该业务异常的原因，可以自动生成针对该异常业务的异常检测请求。

可见，对于上述异常检测请求，可以由权益账户的用户根据需要触发生成，也可以依据目标交易涉及到的业务运行过程中，出现异常时自动生成等，本申请对上述异常检测请求的生成方法不做限制，包括但并不局限于上文描述的两种生成方式。通常情况下，对于该异常检测请求可以包括请求检测的异常内容等，以便计算机设备可以据此确定异常检测对象，本申请对异常检测请求包含的内容不做限制，可视情况而定。

步骤S32，从数据库调取与目标交易对应的交易数据；

计算机设备接收到上述异常检测请求后，通过解析该异常检测请求，可以得到异常检测内容，如目标交易的交易标识、异常业务内容等，如客户参加获得的某一项权益无法使用，具体可以表征为相应业务无法办理等，基于这些解析结果，可以从数据库存储的各权益账户所具有的每一笔交易执行过程中，导致权益账户改变的每一次操作所产生的业务变动数据中，查询与该异常检测请求相匹配的异常业务变动数据，即能够说明可能导致本次业务异常的原因的业务变动数据。

其中，由于同一笔交易执行过程中产生的所有业务变动数据，会合并成一条交易数据存储，本申请实施例在查询异常业务变动数据的过程中，可以先从数据库存储的多条交易数据中，调取当前权益账户执行目标交易所产生的交易数据，即查收与当前权益账户的账户标识和目标交易的交易标识对应的交易数据。

步骤S33，对交易数据包含的多条业务变动数据分别进行异常检测，确定异常业务变动数据；

步骤S34，依据异常业务变动数据，获得异常检测结果；

对于调取的交易数据，其包含的是目标交易执行过程中，导致当前权益账户发生的每一次变化所记录的业务变动数据，本申请实施例可以依据异常检测请求包含的异常内容，对提取到这些业务变动数据进行异常检测，即查询与该异常内容关联的业务变动数据，如查询表示该异常业务的状态发生变化的业务变动数据等，将其作为异常业务变动数据做进一步分析，来确定异常检测结果。

示例性的，仍以上文描述的用户参与多个活动获取权益后，某一些权益无法使用的场景为例，按照上述异常检测方式，若得到的异常业务变动数据为表示该权益过期(即使用时长超过该权益的有效期)的历史记录数据，可以得到权益过期的异常检测结果；若异常业务变动数据为表示该权益对应的业务的提供商，已经撤回该项业务的历史记录数据，由此可以得到因业务撤回导致业务无法办理的异常检测结果等。可见，在业务变动数据异常检测时，直接查询与异常业务关联的各时间点生成的异常业务变动数据，分析该异常业务变动数据的内容，可以直接得到相应内容的异常检测结果，包括但并不局限于上文列举的内容。

步骤S35，将该异常检测结果与执行目标交易的权益账户关联，反馈至登录该权益账户的客户端输出。

对于上文获得的导致目标交易涉及到的某业务无法办理的异常检测结果，本申请可以将其告知至相应用户，即具有执行该目标交易的权益账户的用户，在实际应用中，可以将获得的异常检测结果与该权益账户关联，据此推送至登录该权益账户的客户端输出，如以短消息等方式通知用户这一异常检测结果，也可以将该异常检测结果反馈至该权益账户关联的通讯账号，从而以短信、邮件等方式进行异常检测结果的通知，本申请对该通知方式不做限制，可视情况而定。

综上所述，结合上文实施例描述的权益账户执行每一笔交易，如联机交易或批处理交易等，通过记录交易执行过程中产生的表示每一次权益账户变化的业务变化数据，由此表征本次操作导致权益账户产生的变化。这样，在目标交易涉及到的某一业务异常，需要定位异常原因的情况下，可以对数据库存储的关于该目标交易的数据层面上的各业务变动数据进行异常检测，确定异常业务变动数据，进而由此得到异常检测结果，反馈至登录相应权益账户的客户端输出，以使该权益账户的用户能够及时且精准得到导致业务异常的原因，无需长时间等待业务人员手动一一排查确定导致业务异常的原因，极大提高了异常检测效率，提高了客户体验感受。

参照图4，为本申请提出的交易数据获取装置的一可选示例的结构示意图，该装置可以包括：

交易执行模块41，用于响应针对权益账户的交易请求，执行所请求的目标交易；

业务变动数据记录模块42，用于记录所述目标交易执行期间产生的所述权益账户的业务变动数据；

在本申请实施例中，该业务变动数据包括对所述权益账户信息的一次操作所产生的，操作前后相应业务的状态信息、该操作的操作类型以及所述目标交易的交易标识、交易类型等数据层面上的业务数据表信息，本申请对业务变动数据包含的内容不做限制，可视情况而定。

交易数据生成模块43，用于检测到所述目标交易执行成功，由记录的所述业务变动数据生成所述交易请求的交易数据；

交易数据上报模块44，用于将所述交易数据上报至数据库存储。

在一些实施例中，如图5所示，上述业务变动数据记录模块42可以包括：

业务变动数据获取单元421，用于在所述目标交易执行期间，获取对所述权益账户信息的每一次操作，产生的所述权益账户的业务变动数据；

账号变动消息缓存单元422，用于由每一次操作产生的所述业务变动数据，生成相应的一条账户变动消息进行缓存

可选的，如图5所示，上述交易数据生成模块43可以包括：

合并封装单元431，用于对所述目标交易对应的多条所述账户变动消息进行合并封装处理，得到具有预设消息格式的一条交易数据；

队列存储单元432，用于将所述交易数据发送至缓存队列进行存储。

可选的，如图5所示，上述交易数据上报模块44可以包括：

交易数据获取单元441，用于按照数据提交策略，获取所述缓存队列存储的所述交易数据；

业务变动数据上报单元442，用于将获取的所述交易数据包含的所述业务变动数据上报至数据库存储。

在一种可能的实现方式中，该交易数据获取单元441可以包括：

第一获取单元，用于获取所述缓存队列在预设时长内存储的所述交易数据；所述预设时长是指距离当前时间的时长；

或者，第二获取单元，用于检测到所述缓存队列存储的所述交易数据的数量达到预设条数，获取所述缓存队列存储的所述预设条数的所述交易数据。

在本申请提出的又一些实施例中，如图5所示，上述装置还可以包括：

撤销模块45，用于检测到所述目标交易执行失败，依据记录的所述业务变动数据，撤销所述目标交易执行期间对所述权益账户信息的操作。

基于上文各实施例描述的交易数据获取装置，如图6所示，该装置还可以包括：

异常检测请求响应模块46，用于响应针对所述目标交易的异常检测请求；

交易数据调取模块47，用于从数据库调取与所述目标交易对应的交易数据；

异常检测模块48，用于对所述交易数据包含的多条所述业务变动数据分别进行异常检测，确定异常业务变动数据；

异常检测结果获得模块49，用于依据所述异常业务变动数据，获得异常检测结果；

异常检测结果反馈模块410，用于将所述异常检测结果与执行所述目标交易的权益账户关联，反馈至登录所述权益账户的客户端输出。

需要说明的是，关于上述各装置实施例中的各种模块、单元等，均可以作为程序模块存储在存储器中，由处理器执行存储在存储器中的上述程序模块，以实现相应的功能，关于各程序模块及其组合所实现的功能，以及达到的技术效果，可以参照上述方法实施例相应部分的描述，本实施例不再赘述。

本申请还提供了一种可读存储介质，其上存储有程序，该程序被处理器执行时实现上述交易数据获取方法的各步骤，具体实现过程可以参照上述方法实施例相应部分的描述，本实施例不做赘述。

参照图7，为适用于本申请提出的交易数据获取方法和装置的计算机设备的一可选示例的硬件结构示意图，该计算机设备可以是服务器或具有一定数据处理能力的终端，该服务器可以是独立的物理服务器，或多台物理服务器构成的服务集群，或具有云计算能力的云服务器等，可以通过有线网络或无线网络与终端通信连接，具体通信方式本申请不做详述。如图7所示，该计算机设备可以包括：至少一个通信接口71、至少一个存储器72和至少一个处理器73，其中：

通信接口71、存储器72及处理器73均可以连接通信总线，以实现相互之间的数据交互，本申请对计算机设备内部的线路连接关系不做一一详述，可以依据实际应用场景的通信需求确定。

通信接口71可以包括通信模块的接口，如GSM模块、WIFI模块、实现移动通信网络(如5G、6G网络)数据通信的接口等，以便计算机设备通过这类通信接口实现与其他设备的数据交互；当然，该通信接口71还可以包括如USB接口、串/并口等接口，用于实现计算机设备内部组成部件之间的数据交互，如本申请提出的交易数据获取方法执行过程中产生或所需的各种中间数据等，可以根据实际应用场景的需求确定，本申请不做一一详述。

存储器72可以存储用于实现本申请实施例提供的交易数据获取方法的多个指令构成的程序，由处理器73调用并加载存储器72所存储的程序，从而实现本申请相应实施例提出的交易数据获取方法，具体实现过程可以参照但并不局限于上文相应实施例的描述。

在本申请实施例中，存储器72可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件或其他易失性固态存储器件。处理器73，可以为中央处理器(Central Processing Unit，CPU)、特定应用集成电路(application-specificintegrated circuit，ASIC)、数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件等。

应该理解，本申请上述实施例描述的计算机设备的结构并不构成对本申请实施例中计算机设备的限定，在实际应用中，计算机设备可以包括比图7所示及上文实施例描述的结构组成更多或更少的部件，本申请在此不做一一列举。且，在上述计算机设备为终端的情况下，其还可以包括如显示屏、各种传感器、麦克风、摄像头、电源管理模块、天线等各种输入/输出组件，可以依据该终端的产品类型及其功能确定，本申请在此不做详述。

最后，需要说明的是，本说明书中各个实施例采用递进或并列的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置、计算机设备而言，由于其与实施例公开的方法对应，所以描述的比较简单，相关之处参见方法部分说明即可。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种交易数据获取方法，其特征在于，所述方法包括：

响应针对权益账户的交易请求，执行所请求的目标交易；

记录所述目标交易执行期间产生的所述权益账户的业务变动数据；

检测到所述目标交易执行成功，由记录的所述业务变动数据生成所述交易请求的交易数据；

将所述交易数据上报至数据库存储。

2.根据权利要求1所述的方法，其特征在于，所述记录所述目标交易执行期间产生的所述权益账户的业务变动数据，包括：

在所述目标交易执行期间，获取对所述权益账户信息的每一次操作，产生的所述权益账户的业务变动数据；

由每一次操作产生的所述业务变动数据，生成相应的一条账户变动消息进行缓存。

3.根据权利要求2所述的方法，其特征在于，所述由记录的所述业务变动数据生成所述交易请求的交易数据，包括：

对所述目标交易对应的多条所述账户变动消息进行合并封装处理，得到具有预设消息格式的一条交易数据；

将所述交易数据发送至缓存队列进行存储。

4.根据权利要求3所述的方法，其特征在于，所述将所述交易数据上报至数据库存储，包括：

按照数据提交策略，获取所述缓存队列存储的所述交易数据；

将获取的所述交易数据包含的所述业务变动数据上报至数据库存储。

5.根据权利要求4所述的方法，其特征在于，所述按照数据提交策略，获取所述缓存队列存储的所述交易数据，包括：

获取所述缓存队列在预设时长内存储的所述交易数据；所述预设时长是指距离当前时间的时长；

或者，

检测到所述缓存队列存储的所述交易数据的数量达到预设条数，获取所述缓存队列存储的所述预设条数的所述交易数据。

6.根据权利要求1～5任一项所述的方法，其特征在于，所述业务变动数据包括对所述权益账户信息的一次操作所产生的，操作前后相应业务的状态信息、该操作的操作类型以及所述目标交易的交易标识、交易类型；

所述响应针对权益账户的交易请求，执行所请求的目标交易，包括：

响应针对权益账户的联机交易请求，执行所述请求的目标交易；或者，

响应针对不同权益账户的批处理交易请求，执行所述批处理交易请求各自所请求的目标交易。

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

检测到所述目标交易执行失败，依据记录的所述业务变动数据，撤销所述目标交易执行期间对所述权益账户信息的操作。

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

响应针对所述目标交易的异常检测请求；

从数据库调取与所述目标交易对应的交易数据；

对所述交易数据包含的多条所述业务变动数据分别进行异常检测，确定异常业务变动数据；

依据所述异常业务变动数据，获得异常检测结果；

将所述异常检测结果与执行所述目标交易的权益账户关联，反馈至登录所述权益账户的客户端输出。

9.一种交易数据获取装置，其特征在于，所述装置包括：

交易执行模块，用于响应针对权益账户的交易请求，执行所请求的目标交易；

业务变动数据记录模块，用于记录所述目标交易执行期间产生的所述权益账户的业务变动数据；

交易数据生成模块，用于检测到所述目标交易执行成功，由记录的所述业务变动数据生成所述交易请求的交易数据；

交易数据上报模块，用于将所述交易数据上报至数据库存储。

10.一种计算机设备，其特征在于，所述计算机设备包括：至少一个通信接口、至少一个存储器和至少一个处理器，其中：

所述存储器，用于存储实现如权利要求1～8任一项所述的交易数据获取方法的程序；

所述处理器，用于加载并执行所述存储器存储的所述程序，以实现如权利要求1～8任一项所述的交易数据获取方法。

Images