CN116862652A - 进件数据的处理方法、装置及电子设备 - Google Patents

Abstract

本申请公开了一种进件数据的处理方法、装置及电子设备，该方法应用于云计算领域，该方法包括：对接收到的多个进件数据进行解析得到每个进件数据的产品编号和业务场景；依据产品编号和业务场景，在多个进件数据中确定第一进件数据和第二进件数据；通过消息中间件计算第一进件数据的风险判定指标；通过线程池计算第二进件数据的风险判定指标；对第一进件数据和第二进件数据的风险判定指标进行决策，得到多个进件数据的决策结果。通过本申请，解决了相关技术中为了让金融机构的风险控制决策系统适应高并发场景，往往采用限流的方式限制高并发场景中大量并发的数据消费请求，使新的数据消费请求无法被及时处理，导致金融机构的工作效率较低的问题。

Description

进件数据的处理方法、装置及电子设备

技术领域

本申请涉及云计算领域，具体而言，涉及一种进件数据的处理方法、装置及电子设备。

背景技术

随着互联网技术的发展和普及，越来越多的人开始接触并使用网络，渐渐地高并发的场景已成为金融机构的系统架构设计中必须考虑的因素之一。为让金融机构的系统能够适应高并发状态，架构设计者们从硬件、网络、系统架构、数据结构的应用、算法优化、多线程技术等多方面进行优化，其中限流技术是常用的解决方法之一。

目前，常用的限流技术大致有三大类：一是合法性验证限流，即利用验证码、IP黑名单等手段有效的防止恶意攻击和爬虫采集；二是容器限流，即利用Tomcat、Nginx等限流手段限制容器的每秒查询率(Queries per second，QPS，表示一个特定的查询服务器在规定时间内所处理流量的多少)，其中Tomcat可以设置最大线程数，当并发超过最大线程数会排队等待执行；三是服务端限流，通过时间窗口算法、漏桶算法、令牌算法等限流算法对服务端处理的数据流量进行限制。

但上述的限流技术在服务器的每秒查询率超过任意规则的阈值后，会立即拒绝新请求的访问，影响了业务的正常运行，降低了金融机构的工作效率。其次，限流技术生效的最小颗粒度是微服务模块，无法做到单一业务微服务内不同产品的自主限流。

针对相关技术中为了让金融机构的风险控制决策系统适应高并发场景，往往采用限流的方式限制高并发场景中大量并发的数据消费请求，使新的数据消费请求无法被及时处理，导致金融机构的工作效率较低的问题，目前尚未提出有效的解决方案。

发明内容

本申请的主要目的在于提供一种进件数据的处理方法、装置及电子设备，以解决相关技术中为了让金融机构的风险控制决策系统适应高并发场景，往往采用限流的方式限制高并发场景中大量并发的数据消费请求，使新的数据消费请求无法被及时处理，导致金融机构的工作效率较低的问题。

为了实现上述目的，根据本申请的一个方面，提供了一种进件数据的处理方法，该方法包括：在接收到上游业务系统发送的多个进件数据的情况下，对所述多个进件数据进行解析，得到每个进件数据的产品编号和每个进件数据的业务场景，其中，所述进件数据是指金融机构对客户的贷款申请进行风险审核时所述客户所提供的数据；依据所述产品编号和所述业务场景，在所述多个进件数据中确定第一进件数据和第二进件数据，其中，所述第一进件数据是指发送至消息中间件的进件数据，所述第二进件数据是指不发送至所述消息中间件的进件数据；通过所述消息中间件对所述第一进件数据进行计算，得到所述第一进件数据的风险判定指标；通过线程池对所述第二进件数据进行计算，得到所述第二进件数据的风险判定指标；通过流程决策模块分别对所述第一进件数据的风险判定指标和所述第二进件数据的风险判定指标进行决策，得到所述多个进件数据的决策结果。

进一步地，通过所述消息中间件对所述第一进件数据进行计算，得到所述第一进件数据的风险判定指标包括：依据所述产品编号对所述第一进件数据分配数据标签，并将所述第一进件数据发送至所述消息中间件，其中，所述数据标签用于指示所述第一进件数据在所述消息中间件中的存储位置；依据集群节点的计算能力在所述消息中间件中确定待消费的目标标签；在所述消息中间件中获取所述目标标签对应的第一进件数据，并通过所述集群节点对所述目标标签对应的第一进件数据进行批量计算，得到所述第一进件数据的风险判定指标。

进一步地，通过线程池对所述第二进件数据进行计算，得到所述第二进件数据的风险判定指标包括：在所述线程池中创建至少一个线程；通过所述至少一个线程分别对所述第二进件数据进行计算，得到所述第二进件数据的风险判定指标。

进一步地，依据所述产品编号和所述业务场景，在所述多个进件数据中确定第一进件数据和第二进件数据包括：确定金融机构中金融产品的消费配置信息，并将所述金融产品的消费配置信息写入数据库的消费配置表中，其中，所述消费配置信息至少包括以下数据：金融产品的产品编号、所述金融产品的业务场景以及所述金融产品是否对接所述消息中间件；依据所述消费配置表、所述产品编号和所述业务场景确定每个进件数据是否发送至所述消息中间件；将发送至所述消息中间件的进件数据确定为所述第一进件数据，并且将不发送至所述消息中间件的进件数据确定为所述第二进件数据。

进一步地，在将所述第一进件数据发送至所述消息中间件之后，所述方法还包括：若所述第一进件数据成功发送至所述消息中间件，则生成所述第一进件数据的成功发送标识，并将所述成功发送标识发送至所述上游业务系统；在所述上游业务系统未接收到所述第一进件数据的成功发送标识的情况下，从所述上游业务系统中重新获取所述第一进件数据。

进一步地，在确定金融机构中金融产品的消费配置信息之后，所述方法还包括：在检测到预设时长内所述多个进件数据的数量小于第一预设数值，或检测到所述消息中间件出现故障时，在所述消费配置表中配置所述金融产品不对接所述消息中间件；在检测到所述预设时长内所述多个进件数据的数量大于第二预设数值，或检测到所述线程池出现故障时，在所述消费配置表中配置所述金融产品对接所述消息中间件。

进一步地，在检测到所述消息中间件出现故障之后，所述方法还包括：获取所述消息中间件中待消费的进件数据；按照预设数据格式对所述待消费的进件数据进行封装，得到封装后的进件数据；通过所述流程决策模块对所述封装后的进件数据进行计算和决策，得到所述待消费的进件数据的决策结果。

进一步地，在通过流程决策模块分别对所述第一进件数据的风险判定指标和所述第二进件数据的风险判定指标进行决策，得到所述多个进件数据的决策结果之后，所述方法还包括：将每个进件数据的风险判定指标和每个进件数据的决策结果存储至Redis数据库中；在接收到所述上游业务系统发送的查询请求时，通过所述Redis数据库获取所述查询请求的查询结果，其中，所述查询请求用于查询所述进件数据的风险判定指标和/或所述进件数据的决策结果。

为了实现上述目的，根据本申请的另一方面，提供了一种进件数据的处理装置，该装置包括：解析单元，用于在接收到上游业务系统发送的多个进件数据的情况下，对所述多个进件数据进行解析，得到每个进件数据的产品编号和每个进件数据的业务场景，其中，所述进件数据是指金融机构对客户的贷款申请进行风险审核时所述客户所提供的数据；确定单元，用于依据所述产品编号和所述业务场景，在所述多个进件数据中确定第一进件数据和第二进件数据，其中，所述第一进件数据是指发送至消息中间件的进件数据，所述第二进件数据是指不发送至所述消息中间件的进件数据；第一计算单元，用于通过所述消息中间件对所述第一进件数据进行计算，得到所述第一进件数据的风险判定指标；第二计算单元，用于通过线程池对所述第二进件数据进行计算，得到所述第二进件数据的风险判定指标；决策单元，用于通过流程决策模块分别对所述第一进件数据的风险判定指标和所述第二进件数据的风险判定指标进行决策，得到所述多个进件数据的决策结果。

进一步地，所述第一计算单元包括：分配子单元，用于依据所述产品编号对所述第一进件数据分配数据标签，并将所述第一进件数据发送至所述消息中间件，其中，所述数据标签用于指示所述第一进件数据在所述消息中间件中的存储位置；第一确定子单元，用于依据集群节点的计算能力在所述消息中间件中确定待消费的目标标签；第一计算子单元，用于在所述消息中间件中获取所述目标标签对应的第一进件数据，并通过所述集群节点对所述目标标签对应的第一进件数据进行批量计算，得到所述第一进件数据的风险判定指标。

进一步地，所述第二计算单元包括：创建子单元，用于在所述线程池中创建至少一个线程；第二计算子单元，用于通过所述至少一个线程分别对所述第二进件数据进行计算，得到所述第二进件数据的风险判定指标。

进一步地，所述确定单元包括：第二确定子单元，用于确定金融机构中金融产品的消费配置信息，并将所述金融产品的消费配置信息写入数据库的消费配置表中，其中，所述消费配置信息至少包括以下数据：金融产品的产品编号、所述金融产品的业务场景以及所述金融产品是否对接所述消息中间件；第三确定子单元，用于依据所述消费配置表、所述产品编号和所述业务场景确定每个进件数据是否发送至所述消息中间件；第四确定子单元，用于将发送至所述消息中间件的进件数据确定为所述第一进件数据，并且将不发送至所述消息中间件的进件数据确定为所述第二进件数据。

进一步地，所述第一计算单元还包括：生成子单元，用于在将所述第一进件数据发送至所述消息中间件之后，若所述第一进件数据成功发送至所述消息中间件，则生成所述第一进件数据的成功发送标识，并将所述成功发送标识发送至所述上游业务系统；第一获取子单元，用于在所述上游业务系统未接收到所述第一进件数据的成功发送标识的情况下，从所述上游业务系统中重新获取所述第一进件数据。

进一步地，所述确定单元还包括：第一配置子单元，用于在确定金融机构中金融产品的消费配置信息之后，在检测到预设时长内所述多个进件数据的数量小于第一预设数值，或检测到所述消息中间件出现故障时，在所述消费配置表中配置所述金融产品不对接所述消息中间件；第二配置子单元，用于在检测到所述预设时长内所述多个进件数据的数量大于第二预设数值，或检测到所述线程池出现故障时，在所述消费配置表中配置所述金融产品对接所述消息中间件。

进一步地，所述确定单元还包括：第二获取子单元，用于在检测到所述消息中间件出现故障之后，获取所述消息中间件中待消费的进件数据；封装子单元，用于按照预设数据格式对所述待消费的进件数据进行封装，得到封装后的进件数据；第三计算子单元，用于通过所述流程决策模块对所述封装后的进件数据进行计算和决策，得到所述待消费的进件数据的决策结果。

进一步地，所述装置还包括：存储单元，用于在通过流程决策模块分别对所述第一进件数据的风险判定指标和所述第二进件数据的风险判定指标进行决策，得到所述多个进件数据的决策结果之后，将每个进件数据的风险判定指标和每个进件数据的决策结果存储至Redis数据库中；获取单元，用于在接收到所述上游业务系统发送的查询请求时，通过所述Redis数据库获取所述查询请求的查询结果，其中，所述查询请求用于查询所述进件数据的风险判定指标和/或所述进件数据的决策结果。

为了实现上述目的，根据本申请的一个方面，提供了一种电子设备，包括一个或多个处理器和存储器，存储器用于存储一个或多个程序，其中，当一个或多个程序被一个或多个处理器执行时，使得一个或多个处理器实现上述任意一项所述进件数据的处理方法。

通过本申请，采用以下步骤：在接收到上游业务系统发送的多个进件数据的情况下，对所述多个进件数据进行解析，得到每个进件数据的产品编号和每个进件数据的业务场景，其中，所述进件数据是指金融机构对客户的贷款申请进行风险审核时所述客户所提供的数据；依据所述产品编号和所述业务场景，在所述多个进件数据中确定第一进件数据和第二进件数据，其中，所述第一进件数据是指发送至消息中间件的进件数据，所述第二进件数据是指不发送至所述消息中间件的进件数据；通过所述消息中间件对所述第一进件数据进行计算，得到所述第一进件数据的风险判定指标；通过线程池对所述第二进件数据进行计算，得到所述第二进件数据的风险判定指标；通过流程决策模块分别对所述第一进件数据的风险判定指标和所述第二进件数据的风险判定指标进行决策，得到所述多个进件数据的决策结果，解决了相关技术中为了让金融机构的风险控制决策系统适应高并发场景，往往采用限流的方式限制高并发场景中大量并发的数据消费请求，使新的数据消费请求无法被及时处理，导致金融机构的工作效率较低的问题。通过消息中间件和线程池两种消费方式对客户贷款申请的进件数据进行消费，能够依据接收到进件数据的数量和实际生产情况灵活地配置进件数据的消费方式，避免了在接收到大量进件数据的高并发场景下无法及时处理进件数据的数据消费请求，导致金融机构的工作效率较低，进而影响金融机构的正常业务运行的情况，提高了金融机构处理进件数据的效率，达到了提高金融机构的工作效率的效果。

附图说明

构成本申请的一部分的附图用来提供对本申请的进一步理解，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例一提供的进件数据的处理方法的流程图；

图2是根据本申请实施例一提供的可选的进件数据的处理方法的示意图一；

图3是根据本申请实施例一提供的可选的进件数据的处理方法的示意图二；

图4是根据本申请实施例一提供的可选的进件数据的处理方法的示意图三；

图5是根据本申请实施例一提供的可选的进件数据的处理方法的示意图四；

图6是根据本申请实施例一提供的可选的进件数据的处理方法的示意图五；

图7是根据本申请实施例二提供的进件数据的处理装置的示意图；

图8是根据本申请实施例五提供的进件数据的处理电子设备的示意图。

具体实施方式

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

需要说明的是，本申请所涉及的用户信息(包括但不限于用户设备信息、用户个人信息、用户申请贷款所填写的信息、查询的信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据、填写的数据、查询的数据、接收到的进件数据等)，均为经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准，并提供有相应的操作入口，供用户选择授权或者拒绝。

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

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

为了便于描述，以下对本申请实施例涉及的部分名词或术语进行说明：

进件数据：进件数据是指一个企业或个人向金融机构申请贷款、信用卡或其他金融产品时提交的申请材料和相关信息，例如，个人身份信息(如姓名、身份证号码、联系方式等)、财务状况(如收入、支出、债务等)、就业情况、资产状况等。金融机构根据进件数据评估客户的信用风险和还款能力，进而决定是否批准申请并确定贷款额度或信用额度。

RocketMQ是一种分布式消息中间件，由阿里巴巴集团开发并开源。它具有高可靠性、高吞吐量、低延迟等特点，适用于大规模分布式系统中的消息通信。RocketMQ提供了消息的可靠传输、顺序传输、分布式消息订阅和广播等功能，它还支持多种消息模式，包括同步、异步、单向等，同时提供了灵活的消息过滤和延迟消息等特性，可以满足各种业务场景的需求。

高并发是指短时间内系统接收到大量操作请求的情况。

实施例一

下面结合优选的实施步骤对本发明进行说明，图1是根据本申请实施例一提供的进件数据的处理方法的流程图，如图1所示，该方法包括如下步骤：

步骤S101，在接收到上游业务系统发送的多个进件数据的情况下，对多个进件数据进行解析，得到每个进件数据的产品编号和每个进件数据的业务场景，其中，进件数据是指金融机构对客户的贷款申请进行风险审核时客户所提供的数据。

在本实施例一中，进件数据是指客户或企业向金融机构申请贷款、信用卡或其他金融产品时提交的申请材料和相关信息，例如，个人身份信息(例如，姓名、身份证号码、联系方式等)、财务状况(例如，收入、支出、债务等)、就业情况、资产状况等。

具体地，客户通过多种渠道向金融机构发起贷款申请后，金融机构中上游业务系统根据客户的贷款申请生成该客户的进件数据，并通过http请求调用风控决策系统消费进件数据，得到该客户贷款申请的决策结果。为了确定进件数据的消费方式，风控决策系统在接收到进件数据后，需要解析出每个进件数据的产品编号和每个进件数据的业务类型。

步骤S102，依据产品编号和业务场景，在多个进件数据中确定第一进件数据和第二进件数据，其中，第一进件数据是指发送至消息中间件的进件数据，第二进件数据是指不发送至消息中间件的进件数据。

为了在高并发场景下及时处理进件数据，可以将接收到的进件数据分为第一进件数据和第二进件数据，进而采用两种不同的消费方式消费两种进件数据。

在一可选的实施例中，风控决策系统一般情况下通过线程池消费上游业务系统发送到的进件数据。当在一段时间内突然接收到大量进件数据的情况下，可以开启进件数据对接消息中间件的功能，通过消息中间件消费突然接收到的大量进件数据。

步骤S103，通过消息中间件对第一进件数据进行计算，得到第一进件数据的风险判定指标。

在本实施例一中，消息中间件用于在风控决策系统中传递进件数据，将进件数据从一个应用程序发送到另一个应用程序。消息中间件独立于风控决策系统部署，避免了消息中间件占用风控决策系统的资源，导致风控决策系统的消费速度较低的问题。风险判定指标是评估和判断客户贷款申请的风险程度的指标，例如，信用评分，通过客户的信用状况和还款能力计算客户的信用评分；收入和负债比，通过客户的收入水平和负债状况计算客户的收入和负债比。具体地，在对多个进件数据进行分类后，采用消息中间件消费第一进件数据(即对第一进件数据进行计算)得到第一进件数据的风险判定指标。

步骤S104，通过线程池对第二进件数据进行计算，得到第二进件数据的风险判定指标。

在本实施例一中，线程池通过对一组线程进行管理和复用来消费多个进件数据，提高了处理数据的性能和效率，同时减少线程的创建和销毁的开销。具体地，在对多个进件数据进行分类后，采用线程池消费第二进件数据(即对第二进件数据进行计算)得到第二进件数据的风险判定指标。

步骤S105，通过流程决策模块分别对第一进件数据的风险判定指标和第二进件数据的风险判定指标进行决策，得到多个进件数据的决策结果。

在本实施例一中，流程决策模块是指风控决策系统中的一个模块，用于根据预设风控策略和进件数据的风险判定指标确定进件数据的决策结果。

综上所述，本申请实施例一提供的进件数据的处理方法，通过在接收到上游业务系统发送的多个进件数据的情况下，对多个进件数据进行解析，得到每个进件数据的产品编号和每个进件数据的业务场景，其中，进件数据是指金融机构对客户的贷款申请进行风险审核时客户所提供的数据；依据产品编号和业务场景，在多个进件数据中确定第一进件数据和第二进件数据，其中，第一进件数据是指发送至消息中间件的进件数据，第二进件数据是指不发送至消息中间件的进件数据；通过消息中间件对第一进件数据进行计算，得到第一进件数据的风险判定指标；通过线程池对第二进件数据进行计算，得到第二进件数据的风险判定指标；通过流程决策模块分别对第一进件数据的风险判定指标和第二进件数据的风险判定指标进行决策，得到多个进件数据的决策结果，解决了相关技术中为了让金融机构的风险控制决策系统适应高并发场景，往往采用限流的方式限制高并发场景中大量并发的数据消费请求，使新的数据消费请求无法被及时处理，导致金融机构的工作效率较低的问题。通过消息中间件和线程池两种消费方式对客户贷款申请的进件数据进行消费，能够依据接收到进件数据的数量和实际生产情况灵活地配置进件数据的消费方式，避免了在接收到大量进件数据的高并发场景下无法及时处理进件数据的数据消费请求，导致金融机构的工作效率较低，进而影响金融机构的正常业务运行的情况，提高了金融机构处理进件数据的效率，达到了提高金融机构的工作效率的效果。

可选地，在本申请实施例一提供的进件数据的处理方法中，通过消息中间件对第一进件数据进行计算，得到第一进件数据的风险判定指标包括：依据产品编号对第一进件数据分配数据标签，并将第一进件数据发送至消息中间件，其中，数据标签用于指示第一进件数据在消息中间件中的存储位置；依据集群节点的计算能力在消息中间件中确定待消费的目标标签；在消息中间件中获取目标标签对应的第一进件数据，并通过集群节点对目标标签对应的第一进件数据进行批量计算，得到第一进件数据的风险判定指标。

在本实施例一中，数据标签是指第一进件数据在消息中间件中的主题(即消息中间件的topic)，消息中间件的topic用于对消息中间件中的第一进件数据进行标识和分类，进而将不同数据标签的第一进件数据存储于消息中间件对应的位置。

具体地，在消费第一进件数据时，风控决策系统按照产品编号为每个第一进件数据分配消息中间件的topic(即上述的数据标签)。然后按照topic将第一进件数据发布到消息中间件对应的topic中。其次，风控决策系统可以根据自身集群节点的计算能力选择一个或多个topic(即上述的目标标签)来接收并消费对应的第一进件数据，得到第一进件数据的风险判定指标。集群节点的计算能力与风控决策系统中包含的计算节点数量有关。例如，当风控决策系统拥有10个计算节点时，可以选择消息中间件中10个topic的第一进件数据进行消费；当风控决策系统拥有5个计算节点时，可以选择消息中间件中4个topic的第一进件数据进行消费。此外，集群节点的计算能力还与金融机构的预设风控策略有关，若风控决策系统对金融机构中A类客户的决策流程较长，则会占用较多的计算资源，可以相应地降低风控决策系统确定目标标签的数量。

需要注意的是，在充分考虑风控决策系统运行的业务场景以及业务场景的可靠性要求的情况下，可以采用RocketMq作为传递第一进件数据的消息中间件。RocketMq支持按时间进行消息(即上述的第一进件数据)回溯，支持按照标识(即上述的数据标签)以及消息内容(即上述的第一进件数据的内容，例如，进件数据的产品编号或业务场景)查询第一进件数据，便于第一进件数据丢失问题的排查及其他业务场景的数据监控。此外，还可以使用Rabbitmq、Kafka等其他消息中间件。

通过为第一进件数据分配消息中间件的topic，实现了第一进件数据的灵活路由和消费机制，使得风控决策系统可以根据自身的计算能力批量处理一个或多个topic中的第一进件数据，达到了平衡风控决策系统的计算负载的效果，进而达到了提高金融机构的业务稳定性的效果。

可选地，在本申请实施例一提供的进件数据的处理方法中，通过线程池对第二进件数据进行计算，得到第二进件数据的风险判定指标包括：在线程池中创建至少一个线程；通过至少一个线程分别对第二进件数据进行计算，得到第二进件数据的风险判定指标。

具体地，在消费第二进件数据时，采用线程池的方式处理第二进件数据，即创建多个线程，将多个第二进件数据分配不同的线程进行并行计算，得到第二进件数据的风险判定指标。通过线程池中的多个线程并行计算多个第二进件数据的风险判定指标，提高了第二进件数据的计算效率，同时由于线程池中共享线程资源，避免了每个线程创建和释放资源的开销，提高了风控决策系统的资源利用率。

可选地，在本申请实施例一提供的进件数据的处理方法中，依据产品编号和业务场景，在多个进件数据中确定第一进件数据和第二进件数据包括：确定金融机构中金融产品的消费配置信息，并将金融产品的消费配置信息写入数据库的消费配置表中，其中，消费配置信息至少包括以下数据：金融产品的产品编号、金融产品的业务场景以及金融产品是否对接消息中间件；依据消费配置表、产品编号和业务场景确定每个进件数据是否发送至消息中间件；将发送至消息中间件的进件数据确定为第一进件数据，并且将不发送至消息中间件的进件数据确定为第二进件数据。

在本实施例一中，在对接收到的进件数据进行分类之前，可以预先确定金融机构中金融产品是否对接消息中间件的配置信息(即上述的消费配置信息)，并将消费配置信息存储在数据库的消费配置表中。当风控决策系统接收到进件数据后，解析出每个进件数据的产品编号和业务场景，再根据每个进件数据的产品编号和业务场景获取每个进件数据在消费配置表中字段“是否对接消息中间件”的字段值。若字段“是否对接消息中间件”的字段值为开启，则确定该进件数据为第一进件数据；若字段“是否对接消息中间件”的字段值为关闭，则确定该进件数据为第二进件数据。

具体地，表一是消费配置表的一个示例。如表一所示，产品1开启了对接消息中间件的功能，产品2关闭了对接消息中间件的功能。在对进件数据进行分类时，授信业务场景下产品1的进件数据即为第一进件数据，授信业务场景下产品2的进件数据即为第二进件数据。

表一消费配置表

产品编码	产品名称	业务场景	是否对接消息中间件
				0000001A	产品1	授信	开启
0000002A	产品2	授信	关闭

通过产品编码和业务场景配置进件数据是否对接消息中间件，能够根据产品和业务场景的实际进件情况灵活地配置进件数据的消费方式，并且通过将每个产品的进件数据的消费方式存储在数据库中，能够持久化保存消费配置表，有益于对消费配置表进行修改和维护，达到了灵活配置进件数据的消费方式的效果。

可选地，在本申请实施例一提供的进件数据的处理方法中，在将第一进件数据发送至消息中间件之后，上述的方法还包括：若第一进件数据成功发送至消息中间件，则生成第一进件数据的成功发送标识，并将成功发送标识发送至上游业务系统；在上游业务系统未接收到第一进件数据的成功发送标识的情况下，从上游业务系统中重新获取第一进件数据。

在本实施例一中，为了避免第一进件数据在传输至消息中间件时传输失败，导致进件数据无法被正常消费的情况，可以在第一进件数据成功发送到消息中间件后，生成该第一进件数据的成功发送标识，并将成功发送标识发送至上游业务系统。若上游业务系统未接收到该第一进件数据的成功发送标识，则认为该第一进件数据在传输过程中出现异常，需要再次向风控决策系统发送该第一进件数据。

需要注意的是，在第二进件数据成功发送到线程池后，也可以生成该第二进件数据的成功发送标识，并将成功发送标识发送至上游业务系统。上游业务系统如果没有接收到该第二进件数据的成功发送标识，则需要重新将该第二进件数据发送至风控决策系统中。

通过生成成功发送标识，并将成功发送标识返回至上游业务系统，避免了进件数据因发送失败丢失，进而影响业务正常运行的情况，达到了增加金融机构的业务可靠性的效果。

可选地，在本申请实施例一提供的进件数据的处理方法中，在确定金融机构中金融产品的消费配置信息之后，上述的方法还包括：在检测到预设时长内多个进件数据的数量小于第一预设数值，或检测到消息中间件出现故障时，在消费配置表中配置金融产品不对接消息中间件；在检测到预设时长内多个进件数据的数量大于第二预设数值，或检测到线程池出现故障时，在消费配置表中配置金融产品对接消息中间件。

在本实施例一中，当进件数据较少，或检测到消息中间件的消费过程出现异常时，可以在消息配置表中将金融产品的消费方式更改为关闭，即不开启消息中间件的消费方式。当进件数据量较大、或线程池的处理方式发生异常等情况时，可以在消费配置表中开启消息中间件的消费方式。

通过在多种场景下检测两种消费方式的异常情况，使得风控决策系统具备良好的监测机制，同时通过在异常情况下设置风控决策系统切换进件数据的消费方式，完善了风控决策系统的异常处理机制，达到了提高风控决策系统的稳定性和可靠性的效果。

可选地，在本申请实施例一提供的进件数据的处理方法中，在检测到消息中间件出现故障之后，上述的方法还包括：获取消息中间件中待消费的进件数据；按照预设数据格式对待消费的进件数据进行封装，得到封装后的进件数据；通过流程决策模块对封装后的进件数据进行计算和决策，得到待消费的进件数据的决策结果。

在本实施例一中，若风控决策系统在发布进件数据或消费进件数据的过程中发现消息中间件服务异常或者其它异常，则会自动关闭进件数据对接消息中间件的设置，采用线程池处理进件数据。此时，若消息中间件中还包含未消费的进件数据，则需要流程决策模块对未消费的进件数据进行补数处理，也可以等待消息中间件服务正常后重新消费未消费的进件数据。

具体地，在消息中间件发生异常后，对消息中间件中未消费的进件数据进行补数处理时，可以在消息中间件的管理界面导出未消费的进件数据，通过风控决策系统的离线数据处理功能对未消费的进件数据进行数据封装，得到离线格式的进件数据(即上述的封装后的进件数据)。然后，将风控决策系统对外服务的接口按照流程决策模块的数据格式进行配置。在风控决策系统对外服务的接口和封装后的进件数据关联后，就可以通过流程决策模块对未消费的进件数据进行补数处理。

通过在消息中间件发生异常时，采用流程决策模块对消息中间件中未消费的进件数据进行补数处理，保证了进件数据的正常消费，完善了风控决策系统的异常处理机制，达到了提高风控决策系统的稳定性和可靠性的效果。

可选地，在本申请实施例一提供的进件数据的处理方法中，在通过流程决策模块分别对第一进件数据的风险判定指标和第二进件数据的风险判定指标进行决策，得到多个进件数据的决策结果之后，上述的方法还包括：将每个进件数据的风险判定指标和每个进件数据的决策结果存储至Redis数据库中；在接收到上游业务系统发送的查询请求时，通过Redis数据库获取查询请求的查询结果，其中，查询请求用于查询进件数据的风险判定指标和/或进件数据的决策结果。

在本实施例一中，在得到进件数据的决策结果后，可以将进件数据的流水号、进件数据的风险判定指标和进件数据的决策结果存储至Redis数据库或ES索引数据库中。图2是本方案处理上游业务系统的查询请求的流程的示意图。如图2所示，在上游业务系统接收到查询客户进件数据的决策结果的查询请求时，可以通过Redis数据库或ES索引数据库快速地获取该客户进件数据的决策结果，响应查询请求，以提高客户进件数据的查询效率。此外，本方案还支持在Redis数据库或ES索引数据库中按照客户进件数据的产品编号、业务场景、进件数据内容查询进件数据的消费状态，以便于进件数据丢失问题的排查及其它业务场景下进件数据的监控。

可选地，在本实施例一中，本方案通过消息中间件处理进件数据的流程可以如图3所示。首先，上游业务系统在接收到进件数据之后，将进件数据分为第一进件数据和第二进件数据，并将第一进件数据和第二进件数据发送至风险决策系统。然后，风险决策系统为第一进件数据分配不同的数据标签，进而将第一进件数据发送至消息中间件RocketMq中的不同主题中，风险决策系统再从RocketMq中获取并消费特定主题的第一进件数据，得到第一进件数据的风险判定指标，并依据第一进件数据的风险判定指标对第一进件数据进行决策，得到第一进件数据的决策结果。在将第一进件数据发送至消息中间件RocketMq后，可以向上游业务系统发送第一进件数据的成功发送标识。最后，风险决策系统将第一进件数据的决策结果存储至Redis数据库中。

可选地，在本实施例一中，本方案通过线程池处理进件数据的流程可以如图4所示。首先，上游业务系统在接收到进件数据之后，将进件数据分为第一进件数据和第二进件数据，并将第一进件数据和第二进件数据发送至风险决策系统。然后，风险决策系统为第二进件数据分配不同的数据标签，进而将第二进件数据发送至线程池中，线程池中不同的线程对第二进件数据进行消费，得到第二进件数据的风险判定指标，并依据第二进件数据的风险判定指标对第二进件数据进行决策，得到第二进件数据的决策结果。在将第二进件数据发送至线程池后，可以向上游业务系统发送第二进件数据的成功发送标识。最后，风险决策系统将第二进件数据的决策结果存储至Redis数据库中。

可选地，在本实施例一中，本方案处理进件数据的流程可以如图5所示。首先，上游业务系统在接收到进件数据之后，将进件数据分为第一进件数据和第二进件数据，并将第一进件数据和第二进件数据发送至风险决策系统。然后，风险决策系统将第一进件数据发送至消息中间件中，将第二进件数据发送至线程池中。其次，风险决策系统从消息中间件中获取并计算第一进件数据，通过线程池计算第二进件数据，得到第一进件数据的风险判定指标和第二进件数据的风险判定指标。最后，风险决策系统中的流程决策模块对第一进件数据的风险判定指标和第二进件数据的风险判定指标进行决策，得到第一进件数据的决策结果和第二进件数据的决策结果。

可选地，在本实施例一中，本方案中风险决策系统处理异常情况的流程可以如图6所示。首先，风险决策系统接收到多个进件数据后，判断每个进件数据是否对接消息中间件，若进件数据对接消息中间件，则将进件数据发送至消息中间件中，若进件数据不对接消息中间件，则将进件数据发送至线程池中。然后，若在进件数据发送至消息中间件的过程中出现异常时，可以更改进件数据的消费方式，即将进件数据设置为不对接消息中间件，将进件数据发送至线程池中。其次，若在消息中间件消费进件数据的过程中出现异常，则可以将未消费的进件数据导出，采用线程池进行消费。最后，对进件数据的风险判定指标进行决策，得到进件数据的决策结果。

需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

实施例二

本申请实施例二还提供了一种进件数据的处理装置，需要说明的是，本申请实施例二的进件数据的处理装置可以用于执行本申请实施例一所提供的用于进件数据的处理方法。以下对本申请实施例二提供的进件数据的处理装置进行介绍。

图7是根据本申请实施例二的进件数据的处理装置的示意图。如图7所示，该装置包括：解析单元701、确定单元702、第一计算单元703、第二计算单元704和决策单元705。

具体地，解析单元701，用于在接收到上游业务系统发送的多个进件数据的情况下，对多个进件数据进行解析，得到每个进件数据的产品编号和每个进件数据的业务场景，其中，进件数据是指金融机构对客户的贷款申请进行风险审核时客户所提供的数据。

确定单元702，用于依据产品编号和业务场景，在多个进件数据中确定第一进件数据和第二进件数据，其中，第一进件数据是指发送至消息中间件的进件数据，第二进件数据是指不发送至消息中间件的进件数据。

第一计算单元703，用于通过消息中间件对第一进件数据进行计算，得到第一进件数据的风险判定指标。

第二计算单元704，用于通过线程池对第二进件数据进行计算，得到第二进件数据的风险判定指标。

决策单元705，用于通过流程决策模块分别对第一进件数据的风险判定指标和第二进件数据的风险判定指标进行决策，得到多个进件数据的决策结果。

本申请实施例二提供的进件数据的处理装置，通过解析单元701在接收到上游业务系统发送的多个进件数据的情况下，对多个进件数据进行解析，得到每个进件数据的产品编号和每个进件数据的业务场景，其中，进件数据是指金融机构对客户的贷款申请进行风险审核时客户所提供的数据；确定单元702依据产品编号和业务场景，在多个进件数据中确定第一进件数据和第二进件数据，其中，第一进件数据是指发送至消息中间件的进件数据，第二进件数据是指不发送至消息中间件的进件数据；第一计算单元703通过消息中间件对第一进件数据进行计算，得到第一进件数据的风险判定指标；第二计算单元704通过线程池对第二进件数据进行计算，得到第二进件数据的风险判定指标；决策单元705通过流程决策模块分别对第一进件数据的风险判定指标和第二进件数据的风险判定指标进行决策，得到多个进件数据的决策结果，解决了相关技术中为了让金融机构的风险控制决策系统适应高并发场景，往往采用限流的方式限制高并发场景中大量并发的数据消费请求，使新的数据消费请求无法被及时处理，导致金融机构的工作效率较低的问题。通过消息中间件和线程池两种消费方式对客户贷款申请的进件数据进行消费，能够依据接收到进件数据的数量和实际生产情况灵活地配置进件数据的消费方式，避免了在接收到大量进件数据的高并发场景下无法及时处理进件数据的数据消费请求，导致金融机构的工作效率较低，进而影响金融机构的正常业务运行的情况，提高了金融机构处理进件数据的效率，达到了提高金融机构的工作效率的效果。

可选地，在本申请实施例二提供的进件数据的处理装置中，上述的第一计算单元703包括：分配子单元，用于依据产品编号对第一进件数据分配数据标签，并将第一进件数据发送至消息中间件，其中，数据标签用于指示第一进件数据在消息中间件中的存储位置；第一确定子单元，用于依据集群节点的计算能力在消息中间件中确定待消费的目标标签；第一计算子单元，用于在消息中间件中获取目标标签对应的第一进件数据，并通过集群节点对目标标签对应的第一进件数据进行批量计算，得到第一进件数据的风险判定指标。

可选地，在本申请实施例二提供的进件数据的处理装置中，上述的第二计算单元704包括：创建子单元，用于在线程池中创建至少一个线程；第二计算子单元，用于通过至少一个线程分别对第二进件数据进行计算，得到第二进件数据的风险判定指标。

可选地，在本申请实施例二提供的进件数据的处理装置中，上述的确定单元702包括：第二确定子单元，用于确定金融机构中金融产品的消费配置信息，并将金融产品的消费配置信息写入数据库的消费配置表中，其中，消费配置信息至少包括以下数据：金融产品的产品编号、金融产品的业务场景以及金融产品是否对接消息中间件；第三确定子单元，用于依据消费配置表、产品编号和业务场景确定每个进件数据是否发送至消息中间件；第四确定子单元，用于将发送至消息中间件的进件数据确定为第一进件数据，并且将不发送至消息中间件的进件数据确定为第二进件数据。

可选地，在本申请实施例二提供的进件数据的处理装置中，上述的第一计算单元703还包括：生成子单元，用于在将第一进件数据发送至消息中间件之后，若第一进件数据成功发送至消息中间件，则生成第一进件数据的成功发送标识，并将成功发送标识发送至上游业务系统；第一获取子单元，用于在上游业务系统未接收到第一进件数据的成功发送标识的情况下，从上游业务系统中重新获取第一进件数据。

可选地，在本申请实施例二提供的进件数据的处理装置中，上述的确定单元702还包括：第一配置子单元，用于在确定金融机构中金融产品的消费配置信息之后，在检测到预设时长内多个进件数据的数量小于第一预设数值，或检测到消息中间件出现故障时，在消费配置表中配置金融产品不对接消息中间件；第二配置子单元，用于在检测到预设时长内多个进件数据的数量大于第二预设数值，或检测到线程池出现故障时，在消费配置表中配置金融产品对接消息中间件。

可选地，在本申请实施例二提供的进件数据的处理装置中，上述的确定单元702还包括：第二获取子单元，用于在检测到消息中间件出现故障之后，获取消息中间件中待消费的进件数据；封装子单元，用于按照预设数据格式对待消费的进件数据进行封装，得到封装后的进件数据；第三计算子单元，用于通过流程决策模块对封装后的进件数据进行计算和决策，得到待消费的进件数据的决策结果。

可选地，在本申请实施例二提供的进件数据的处理装置中，上述的装置还包括：存储单元，用于在通过流程决策模块分别对第一进件数据的风险判定指标和第二进件数据的风险判定指标进行决策，得到多个进件数据的决策结果之后，将每个进件数据的风险判定指标和每个进件数据的决策结果存储至Redis数据库中；获取单元，用于在接收到上游业务系统发送的查询请求时，通过Redis数据库获取查询请求的查询结果，其中，查询请求用于查询进件数据的风险判定指标和/或进件数据的决策结果。

所述进件数据的处理装置包括处理器和存储器，上述的解析单元701、确定单元702、第一计算单元703、第二计算单元704和决策单元705等均作为程序单元存储在存储器中，由处理器执行存储在存储器中的上述程序单元来实现相应的功能。

处理器中包含内核，由内核去存储器中调取相应的程序单元。内核可以设置一个或以上，通过调整内核参数来提高金融机构的工作效率。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)，存储器包括至少一个存储芯片。

本发明实施例三提供了一种计算机可读存储介质，其上存储有程序，该程序被处理器执行时实现进件数据的处理方法。

本发明实施例四提供了一种处理器，处理器用于运行程序，其中，程序运行时执行进件数据的处理方法。

如图8所示，本发明实施例五提供了一种电子设备，设备包括处理器、存储器及存储在存储器上并可在处理器上运行的程序，处理器执行程序时实现以下步骤：在接收到上游业务系统发送的多个进件数据的情况下，对多个进件数据进行解析，得到每个进件数据的产品编号和每个进件数据的业务场景，其中，进件数据是指金融机构对客户的贷款申请进行风险审核时客户所提供的数据；依据产品编号和业务场景，在多个进件数据中确定第一进件数据和第二进件数据，其中，第一进件数据是指发送至消息中间件的进件数据，第二进件数据是指不发送至消息中间件的进件数据；通过消息中间件对第一进件数据进行计算，得到第一进件数据的风险判定指标；通过线程池对第二进件数据进行计算，得到第二进件数据的风险判定指标；通过流程决策模块分别对第一进件数据的风险判定指标和第二进件数据的风险判定指标进行决策，得到多个进件数据的决策结果。

处理器执行程序时还实现以下步骤：通过消息中间件对第一进件数据进行计算，得到第一进件数据的风险判定指标包括：依据产品编号对第一进件数据分配数据标签，并将第一进件数据发送至消息中间件，其中，数据标签用于指示第一进件数据在消息中间件中的存储位置；依据集群节点的计算能力在消息中间件中确定待消费的目标标签；在消息中间件中获取目标标签对应的第一进件数据，并通过集群节点对目标标签对应的第一进件数据进行批量计算，得到第一进件数据的风险判定指标。

处理器执行程序时还实现以下步骤：通过线程池对第二进件数据进行计算，得到第二进件数据的风险判定指标包括：在线程池中创建至少一个线程；通过至少一个线程分别对第二进件数据进行计算，得到第二进件数据的风险判定指标。

处理器执行程序时还实现以下步骤：依据产品编号和业务场景，在多个进件数据中确定第一进件数据和第二进件数据包括：确定金融机构中金融产品的消费配置信息，并将金融产品的消费配置信息写入数据库的消费配置表中，其中，消费配置信息至少包括以下数据：金融产品的产品编号、金融产品的业务场景以及金融产品是否对接消息中间件；依据消费配置表、产品编号和业务场景确定每个进件数据是否发送至消息中间件；将发送至消息中间件的进件数据确定为第一进件数据，并且将不发送至消息中间件的进件数据确定为第二进件数据。

处理器执行程序时还实现以下步骤：在将第一进件数据发送至消息中间件之后，上述的方法还包括：若第一进件数据成功发送至消息中间件，则生成第一进件数据的成功发送标识，并将成功发送标识发送至上游业务系统；在上游业务系统未接收到第一进件数据的成功发送标识的情况下，从上游业务系统中重新获取第一进件数据。

处理器执行程序时还实现以下步骤：在确定金融机构中金融产品的消费配置信息之后，上述的方法还包括：在检测到预设时长内多个进件数据的数量小于第一预设数值，或检测到消息中间件出现故障时，在消费配置表中配置金融产品不对接消息中间件；在检测到预设时长内多个进件数据的数量大于第二预设数值，或检测到线程池出现故障时，在消费配置表中配置金融产品对接消息中间件。

处理器执行程序时还实现以下步骤：在检测到消息中间件出现故障之后，上述的方法还包括：获取消息中间件中待消费的进件数据；按照预设数据格式对待消费的进件数据进行封装，得到封装后的进件数据；通过流程决策模块对封装后的进件数据进行计算和决策，得到待消费的进件数据的决策结果。

处理器执行程序时还实现以下步骤：在通过流程决策模块分别对第一进件数据的风险判定指标和第二进件数据的风险判定指标进行决策，得到多个进件数据的决策结果之后，上述的方法还包括：将每个进件数据的风险判定指标和每个进件数据的决策结果存储至Redis数据库中；在接收到上游业务系统发送的查询请求时，通过Redis数据库获取查询请求的查询结果，其中，查询请求用于查询进件数据的风险判定指标和/或进件数据的决策结果。

本文中的设备可以是服务器、PC、PAD、手机等。

本申请还提供了一种计算机程序产品，当在数据处理设备上执行时，适于执行初始化有如下方法步骤的程序：在接收到上游业务系统发送的多个进件数据的情况下，对多个进件数据进行解析，得到每个进件数据的产品编号和每个进件数据的业务场景，其中，进件数据是指金融机构对客户的贷款申请进行风险审核时客户所提供的数据；依据产品编号和业务场景，在多个进件数据中确定第一进件数据和第二进件数据，其中，第一进件数据是指发送至消息中间件的进件数据，第二进件数据是指不发送至消息中间件的进件数据；通过消息中间件对第一进件数据进行计算，得到第一进件数据的风险判定指标；通过线程池对第二进件数据进行计算，得到第二进件数据的风险判定指标；通过流程决策模块分别对第一进件数据的风险判定指标和第二进件数据的风险判定指标进行决策，得到多个进件数据的决策结果。

当在数据处理设备上执行时，还适于执行初始化有如下方法步骤的程序：通过消息中间件对第一进件数据进行计算，得到第一进件数据的风险判定指标包括：依据产品编号对第一进件数据分配数据标签，并将第一进件数据发送至消息中间件，其中，数据标签用于指示第一进件数据在消息中间件中的存储位置；依据集群节点的计算能力在消息中间件中确定待消费的目标标签；在消息中间件中获取目标标签对应的第一进件数据，并通过集群节点对目标标签对应的第一进件数据进行批量计算，得到第一进件数据的风险判定指标。

当在数据处理设备上执行时，还适于执行初始化有如下方法步骤的程序：通过线程池对第二进件数据进行计算，得到第二进件数据的风险判定指标包括：在线程池中创建至少一个线程；通过至少一个线程分别对第二进件数据进行计算，得到第二进件数据的风险判定指标。

当在数据处理设备上执行时，还适于执行初始化有如下方法步骤的程序：依据产品编号和业务场景，在多个进件数据中确定第一进件数据和第二进件数据包括：确定金融机构中金融产品的消费配置信息，并将金融产品的消费配置信息写入数据库的消费配置表中，其中，消费配置信息至少包括以下数据：金融产品的产品编号、金融产品的业务场景以及金融产品是否对接消息中间件；依据消费配置表、产品编号和业务场景确定每个进件数据是否发送至消息中间件；将发送至消息中间件的进件数据确定为第一进件数据，并且将不发送至消息中间件的进件数据确定为第二进件数据。

当在数据处理设备上执行时，还适于执行初始化有如下方法步骤的程序：在将第一进件数据发送至消息中间件之后，上述的方法还包括：若第一进件数据成功发送至消息中间件，则生成第一进件数据的成功发送标识，并将成功发送标识发送至上游业务系统；在上游业务系统未接收到第一进件数据的成功发送标识的情况下，从上游业务系统中重新获取第一进件数据。

当在数据处理设备上执行时，还适于执行初始化有如下方法步骤的程序：在确定金融机构中金融产品的消费配置信息之后，上述的方法还包括：在检测到预设时长内多个进件数据的数量小于第一预设数值，或检测到消息中间件出现故障时，在消费配置表中配置金融产品不对接消息中间件；在检测到预设时长内多个进件数据的数量大于第二预设数值，或检测到线程池出现故障时，在消费配置表中配置金融产品对接消息中间件。

当在数据处理设备上执行时，还适于执行初始化有如下方法步骤的程序：在检测到消息中间件出现故障之后，上述的方法还包括：获取消息中间件中待消费的进件数据；按照预设数据格式对待消费的进件数据进行封装，得到封装后的进件数据；通过流程决策模块对封装后的进件数据进行计算和决策，得到待消费的进件数据的决策结果。

当在数据处理设备上执行时，还适于执行初始化有如下方法步骤的程序：在通过流程决策模块分别对第一进件数据的风险判定指标和第二进件数据的风险判定指标进行决策，得到多个进件数据的决策结果之后，上述的方法还包括：将每个进件数据的风险判定指标和每个进件数据的决策结果存储至Redis数据库中；在接收到上游业务系统发送的查询请求时，通过Redis数据库获取查询请求的查询结果，其中，查询请求用于查询进件数据的风险判定指标和/或进件数据的决策结果。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。存储器是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

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

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

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

Claims (10)

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

在接收到上游业务系统发送的多个进件数据的情况下，对所述多个进件数据进行解析，得到每个进件数据的产品编号和每个进件数据的业务场景，其中，所述进件数据是指金融机构对客户的贷款申请进行风险审核时所述客户所提供的数据；

依据所述产品编号和所述业务场景，在所述多个进件数据中确定第一进件数据和第二进件数据，其中，所述第一进件数据是指发送至消息中间件的进件数据，所述第二进件数据是指不发送至所述消息中间件的进件数据；

通过所述消息中间件对所述第一进件数据进行计算，得到所述第一进件数据的风险判定指标；

通过线程池对所述第二进件数据进行计算，得到所述第二进件数据的风险判定指标；

通过流程决策模块分别对所述第一进件数据的风险判定指标和所述第二进件数据的风险判定指标进行决策，得到所述多个进件数据的决策结果。

2.根据权利要求1所述的方法，其特征在于，通过所述消息中间件对所述第一进件数据进行计算，得到所述第一进件数据的风险判定指标包括：

依据所述产品编号对所述第一进件数据分配数据标签，并将所述第一进件数据发送至所述消息中间件，其中，所述数据标签用于指示所述第一进件数据在所述消息中间件中的存储位置；

依据集群节点的计算能力在所述消息中间件中确定待消费的目标标签；

在所述消息中间件中获取所述目标标签对应的第一进件数据，并通过所述集群节点对所述目标标签对应的第一进件数据进行批量计算，得到所述第一进件数据的风险判定指标。

3.根据权利要求1所述的方法，其特征在于，通过线程池对所述第二进件数据进行计算，得到所述第二进件数据的风险判定指标包括：

在所述线程池中创建至少一个线程；

通过所述至少一个线程分别对所述第二进件数据进行计算，得到所述第二进件数据的风险判定指标。

4.根据权利要求1所述的方法，其特征在于，依据所述产品编号和所述业务场景，在所述多个进件数据中确定第一进件数据和第二进件数据包括：

确定金融机构中金融产品的消费配置信息，并将所述金融产品的消费配置信息写入数据库的消费配置表中，其中，所述消费配置信息至少包括以下数据：金融产品的产品编号、所述金融产品的业务场景以及所述金融产品是否对接所述消息中间件；

依据所述消费配置表、所述产品编号和所述业务场景确定每个进件数据是否发送至所述消息中间件；

将发送至所述消息中间件的进件数据确定为所述第一进件数据，并且将不发送至所述消息中间件的进件数据确定为所述第二进件数据。

5.根据权利要求2所述的方法，其特征在于，在将所述第一进件数据发送至所述消息中间件之后，所述方法还包括：

若所述第一进件数据成功发送至所述消息中间件，则生成所述第一进件数据的成功发送标识，并将所述成功发送标识发送至所述上游业务系统；

在所述上游业务系统未接收到所述第一进件数据的成功发送标识的情况下，从所述上游业务系统中重新获取所述第一进件数据。

6.根据权利要求4所述的方法，其特征在于，在确定金融机构中金融产品的消费配置信息之后，所述方法还包括：

在检测到预设时长内所述多个进件数据的数量小于第一预设数值，或检测到所述消息中间件出现故障时，在所述消费配置表中配置所述金融产品不对接所述消息中间件；

在检测到所述预设时长内所述多个进件数据的数量大于第二预设数值，或检测到所述线程池出现故障时，在所述消费配置表中配置所述金融产品对接所述消息中间件。

7.根据权利要求6所述的方法，其特征在于，在检测到所述消息中间件出现故障之后，所述方法还包括：

获取所述消息中间件中待消费的进件数据；

按照预设数据格式对所述待消费的进件数据进行封装，得到封装后的进件数据；

通过所述流程决策模块对所述封装后的进件数据进行计算和决策，得到所述待消费的进件数据的决策结果。

8.根据权利要求1所述的方法，其特征在于，在通过流程决策模块分别对所述第一进件数据的风险判定指标和所述第二进件数据的风险判定指标进行决策，得到所述多个进件数据的决策结果之后，所述方法还包括：

将每个进件数据的风险判定指标和每个进件数据的决策结果存储至Redis数据库中；

在接收到所述上游业务系统发送的查询请求时，通过所述Redis数据库获取所述查询请求的查询结果，其中，所述查询请求用于查询所述进件数据的风险判定指标和/或所述进件数据的决策结果。

9.一种进件数据的处理装置，其特征在于，包括：

解析单元，用于在接收到上游业务系统发送的多个进件数据的情况下，对所述多个进件数据进行解析，得到每个进件数据的产品编号和每个进件数据的业务场景，其中，所述进件数据是指金融机构对客户的贷款申请进行风险审核时所述客户所提供的数据；

确定单元，用于依据所述产品编号和所述业务场景，在所述多个进件数据中确定第一进件数据和第二进件数据，其中，所述第一进件数据是指发送至消息中间件的进件数据，所述第二进件数据是指不发送至所述消息中间件的进件数据；

第一计算单元，用于通过所述消息中间件对所述第一进件数据进行计算，得到所述第一进件数据的风险判定指标；

第二计算单元，用于通过线程池对所述第二进件数据进行计算，得到所述第二进件数据的风险判定指标；

决策单元，用于通过流程决策模块分别对所述第一进件数据的风险判定指标和所述第二进件数据的风险判定指标进行决策，得到所述多个进件数据的决策结果。

10.一种电子设备，其特征在于，包括一个或多个处理器和存储器，所述存储器用于存储一个或多个程序，其中，当所述一个或多个程序被所述一个或多个处理器执行时，使得所述一个或多个处理器实现权利要求1至8中任意一项所述的进件数据的处理方法。