CN117610914A - 业务的风控方法、装置、系统及计算机可读存储介质 - Google Patents

Abstract

本申请公开了一种业务的风控方法、装置、系统及计算机可读存储介质，所述业务的风控方法由风控系统中的风控系统节点执行，该方法包括：从风控基础数据库同步风控基础数据，并将风控基础数据加载至风控系统节点的内存中；根据业务系统发送的业务报文确定风控动态数据，并将风控动态数据加载至风控系统节点的内存中；根据风控基础数据和风控动态数据进行风险计算，得到用户的风险计算结果；将用户的风险计算结果发送至用户终端。本申请将内存机制应用于风控场景，提高了风控的实时性，且由独立部署的风控系统执行，与业务系统解耦，降低了业务逻辑与风控处理之间的相互影响，易于大规模扩展部署，进而能够满足高并发场景的风控需求。

Description

业务的风控方法、装置、系统及计算机可读存储介质

技术领域

本申请涉及风险控制技术领域，尤其涉及一种业务的风控方法、装置、系统及计算机可读存储介质。

背景技术

对于银行等金融领域，风险控制(以下简称“风控”)是业务开展中需要关注的重要因素，根据风控的时机可分为事前控制、事中控制、事后控制。通常根据各个业务的风控的具体要求，建立一个或多个专门的风控系统，负责风险参数、风险模型、风险运算和风险结果等处理。

传统上风控处理通常需要数据采集与存储、数据预处理和加载、模型匹配和运算、数据结果存储、数据结果发布等环节。

以上设计流程严格有序，但应对高并发、高实时性的风险控制场景存在实时性不足，分布式部署时跨数据中心、跨数据库数据传输延时较大等不足。

发明内容

本申请实施例提供了一种业务的风控方法、装置、系统及计算机可读存储介质，以实现业务风控的高实时性和高弹性部署，并满足高并发场景的需求。

本申请实施例采用下述技术方案：

第一方面，本申请实施例提供一种业务的风控方法，所述业务的风控方法由风控系统中的风控系统节点执行，所述业务的风控方法包括：

从风控基础数据库同步风控基础数据，并将所述风控基础数据加载至所述风控系统节点的内存中；

根据业务系统发送的业务报文确定风控动态数据，并将所述风控动态数据加载至所述风控系统节点的内存中；

根据所述风控基础数据和所述风控动态数据进行风险计算，得到用户的风险计算结果；

将所述用户的风险计算结果发送至用户终端。

可选地，所述风控基础数据是从所述风控基础数据库同步的第一风控基础数据，所述从风控基础数据库同步风控基础数据，并将所述风控基础数据加载至所述风控系统节点的内存中包括：

从所述风控基础数据库获取第二风控基础数据的版本标识；

将所述第一风控基础数据的版本标识与所述第二风控基础数据的版本标识进行比较；

若所述第一风控基础数据的版本标识与所述第二风控基础数据的版本标识不一致，则将所述第二风控基础数据更新至所述风控系统节点的内存中；

否则，则不更新。

可选地，所述风控系统为分布式集群的架构，在从风控基础数据库同步风控基础数据之前，所述方法还包括：

将所述风控系统节点的节点信息注册至所述分布式集群的注册中心中，以使所述业务系统通过访问所述注册中心获取节点信息，并根据所述节点信息发送业务报文。

可选地，所述根据所述风控基础数据和所述风控动态数据进行风险计算，得到用户的风险计算结果包括：

根据所述风控动态数据确定所述风控动态数据对应的用户终端；

确定所述风控动态数据对应的用户终端是否为所述风控系统节点中已注册的用户终端；

在所述风控动态数据对应的用户终端为所述风控系统节点中已注册的用户终端的情况下，根据所述风控基础数据和所述风控动态数据进行风险计算，得到所述用户的风险计算结果。

可选地，所述将所述用户的风险计算结果发送至用户终端包括：

基于风险计算结果数据库，确定所述用户的风险计算结果是否发生变化；

在所述用户的风险计算结果发生变化的情况下，将所述用户的风险计算结果发送至用户终端。

可选地，所述将所述用户的风险计算结果发送至用户终端包括：

确定用户终端的在线状态，所述用户终端为在所述风控系统节点中已注册的用户终端；

若所述用户终端的在线状态为在线，则将所述用户的风险计算结果发送至所述用户终端；

否则，则不发送所述用户的风险计算结果。

可选地，在根据所述风控动态数据和所述风控基础数据进行风险计算，得到用户的风险计算结果之后，所述方法还包括：

将所述用户的风险计算结果保留在所述风控系统节点的内存中，并将所述用户的风险计算结果存储至风险计算结果数据库中。

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

接收业务系统的风控数据清理指令；

根据所述业务系统的风控数据清理指令对所述风控系统节点的内存中的风险计算结果进行清理。

第二方面，本申请实施例还提供一种业务的风控装置，所述业务的风控装置应用于风控系统中的风控系统节点，所述业务的风控装置包括：

第一加载单元，用于从风控基础数据库同步风控基础数据，并将所述风控基础数据加载至所述风控系统节点的内存中；

第二加载单元，用于从根据业务系统发送的业务报文确定风控动态数据，并将所述风控动态数据加载至所述风控系统节点的内存中；

风险计算单元，用于根据所述风控基础数据和所述风控动态数据进行风险计算，得到用户的风险计算结果；

发送单元，用于将所述用户的风险计算结果发送至用户终端。

第三方面，本申请实施例还提供一种业务的风控系统，所述业务的风控系统包括多个风控系统节点，所述风控系统节点包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行前述任一所述业务的风控方法。

第四方面，本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的业务的风控系统执行时，使得所述业务的风控系统执行前述任一所述业务的风控方法。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：本申请实施例的业务的风控方法由风控系统中的风控系统节点执行，先从风控基础数据库同步风控基础数据，并将风控基础数据加载至风控系统节点的内存中；然后根据业务系统发送的业务报文确定风控动态数据，并将风控动态数据加载至风控系统节点的内存中；之后根据风控基础数据和风控动态数据进行风险计算，得到用户的风险计算结果；最后将用户的风险计算结果发送至用户终端。本申请实施例的业务的风控方法将内存机制应用于风控场景，提高了风控的实时性，且由独立部署的风控系统执行，与业务系统解耦，降低了业务逻辑与风控处理之间的相互影响，易于大规模扩展部署，进而能够满足高并发场景的风控需求。

附图说明

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

图1为本申请实施例中一种业务的风控方法的流程示意图；

图2为本申请实施例中一种风控系统节点的数据来源示意图；

图3为本申请实施例中一种风控基础数据的更新流程示意图；

图4为本申请实施例中一种风控系统与业务系统的交互流程示意图；

图5为本申请实施例中一种内存数据清理的流程示意图；

图6为本申请实施例中一种业务的风控流程示意图；

图7为本申请实施例中一种业务的风控装置的结构示意图；

图8为本申请实施例中一种业务的风控系统的结构示意图。

具体实施方式

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

以下结合附图，详细说明本申请各实施例提供的技术方案。

传统上的风控处理技术分为两大类：数据仓储模式、数据快速判断模式，前一种通常应用在事后风控领域，后一种通常应用在事中风控领域。

数据仓储模式：需要经过数据采集与存储、数据预处理和加载、模型匹配和运算、数据结果存储、数据结果发布等环节，存在过程处理耗时长、无法满足实时性风控要求。

数据快速判断模式：通过将风控判断步骤集成到业务处理逻辑中以实现事中实时风险控制，但是通常采取数据库方式，多中心多节点部署时数据库之间同步耗时高，实时性较低，且难以灵活大规模扩展部署，无法支撑高并发要求。

下表1为传统的两种风控处理技术的特点对比：

表1

风控处理类别	数据仓储模式	数据快速判断模式
			实时性处理	不支持	支持
部署弹性(多节点快速部署)	弹性低	弹性较低
			高并发	支持较低	支持较低

基于此，本申请实施例提供了一种业务的风控方法，如图1所示，提供了本申请实施例中一种业务的风控方法的流程示意图，本申请实施例的业务的风控方法由风控系统中的风控系统节点执行，所述业务的风控方法至少包括如下的步骤S110至步骤S140：

步骤S110，从风控基础数据库同步风控基础数据，并将所述风控基础数据加载至所述风控系统节点的内存中。

为了满足实际业务场景下的风控处理的实时性和高并发等要求，本申请实施例的风控系统可以采用分布式集群架构，由多个风控系统节点构成，每一个风控系统节点可以看作是等价的，都可用于执行本申请实施例的业务的风控方法。

本申请实施例在对实际业务进行风险控制时，需要先从风控基础数据库中同步风控基础数据，并将同步过来的风控基础数据加载至风控系统节点的内存中以进行后续处理。这里的风控基础数据库可以看作是独立于风控系统的外部数据库，用于对风控基础数据进行维护和更新，作为风控系统的一个外部数据来源。风控基础数据可以理解为是相对于实时动态产生的数据而言变化较小的数据，例如可以包括风控指标、数据来源、风控模型等基础配置数据，当然，具体包括哪些数据维度，本领域技术人员可以根据实际业务场景灵活设置，在此不作具体限定。

步骤S120，根据业务系统发送的业务报文确定风控动态数据，并将所述风控动态数据加载至所述风控系统节点的内存中。

在对实际业务进行风险控制时，还需要接收上游业务系统发送的业务报文，通过对业务报文进行解析可以得到风控动态数据。本申请实施例的风控系统同样也独立于业务系统，因此业务系统也可以作为风控系统的另一个外部数据来源。

由于上游业务系统面向用户终端，基于用户的实际操作触发相应的业务请求，因此，上述风控动态数据可以理解为是基于用户实际操作而产生的动态变化数据，例如可以包括各个不同维度的具体指标值，如转账交易业务中，转账金额这个维度即可以定义为一种风控指标，而具体的转账金额的数值大小需要用户实际输入，因此作为该指标对应的动态数据。从上游业务系统获得的风控动态数据，同样也需要加载至风控系统节点的内存中，以进行后续处理。

相比于传统的将风控逻辑集成到业务处理逻辑中以实现事中实时风险控制的方式来说，本申请实施例通过将风控处理与业务处理逻辑解耦，无论是业务侧还是风控系统侧出现故障或系统升级，都不影响除自身以外的其他系统的正常处理。

此外，由于风控系统需要处理的数据均来源于外部系统或数据库，因此本申请实施例的风控系统节点可以看作是无状态服务节点，采用无状态服务部署的理念，在运行过程不依赖于其他外部因素，配合负载均衡后，可以根据需要灵活进行多数据中心、多节点的部署扩展或收缩，且在扩展或收缩部署过程中不需要既有节点重启，也不影响既有节点在途数据处理，具有高弹性部署能力。

如图2所示，提供了本申请实施例中一种风控系统节点的数据来源示意图。在多数据中心、多节点的分布式架构下，风控系统节点一方面可以从风控基础数据库同步风控基础数据并加载至内存，另一方面可以接收上游业务系统的风控动态数据并加载至内存。

步骤S130，根据所述风控基础数据和所述风控动态数据进行风险计算，得到用户的风险计算结果。

基于内存中存储的风控基础数据和风控动态数据，可以利用事先定义好的风控计算模型或算法实时计算当前业务对应的用户的风险，得到用户的风险计算结果。不同业务场景的风控要求不同，对应的风控模型或算法也不同，本领域技术人员可以根据实际业务场景的需求灵活定义，在此不作具体限定。

风险计算结果同样与具体业务场景相关，例如在银行业务中，可能涉及用户的账户余额不足、保证金不足、爆仓等风险计算结果。

步骤S140，将所述用户的风险计算结果发送至用户终端。

将计算得到的风险计算结果推送至用户终端，以提醒用户当前操作的业务所可能存在的风险。

一方面，采用内存存储和处理数据，能够大大提升节点处理性能，单节点能响应更多并发压力；另一方面，整个环节全部在内存中进行，避免了磁盘IO等耗时动作，从输入至输出，耗时通常约几毫秒级别；再一方面，风控系统节点直接从风控基础数据库同步基础数据，无需进行节点间的基础数据同步，从而降低了多节点之间的协调调度耗时。

本申请实施例的业务的风控方法将内存机制应用于风控场景，提高了风控的实时性，且由独立部署的风控系统执行，与业务系统解耦，降低了业务逻辑与风控处理之间的相互影响，易于大规模扩展部署，进而能够满足高并发场景的风控需求。

在本申请的一些实施例中，所述风控基础数据是从所述风控基础数据库同步的第一风控基础数据，所述从风控基础数据库同步风控基础数据，并将所述风控基础数据加载至所述风控系统节点的内存中包括：从所述风控基础数据库获取第二风控基础数据的版本标识；将所述第一风控基础数据的版本标识与所述第二风控基础数据的版本标识进行比较；若所述第一风控基础数据的版本标识与所述第二风控基础数据的版本标识不一致，则将所述第二风控基础数据更新至所述风控系统节点的内存中；否则，则不更新。

考虑到实际业务场景下，风控基础数据库中存储的风控基础数据也可能随着风控需求的变化而发生变化，因此本申请实施例可以在风控系统启动时和风控基础数据发生变更时，实时加载风控基础数据库中最新的风控基础数据至内存中，保证风险计算使用最新的风控基础数据，进而保证风险计算结果的准确性。

如图3所示，提供了本申请实施例中一种风控基础数据的更新流程示意图。具体地，风控系统节点可以在内存中对风控基础数据的版本进行维护，例如，可以以风控基础数据的数据库表名为主键在内存中初始化版本号为0，记录每张风控基础数据的数据库表的变更版本号，新增一张“内存数据表版本明细表(para_ver)”用来记录每张风控基础数据的数据库表变更版本号以及变更信息，初始化版本号为1，当风控基础数据发生变更时，对应的版本号加1。

风控系统节点可以每隔M毫秒进行一轮风控基础数据的内存版本号与数据库中记录的版本号的对比，若不一致，说明风控基础数据发生变更，则将变更的风控基础数据重新加载至内存中，并更新内存版本号与数据库版本号一致。

在本申请的一些实施例中，所述风控系统为分布式集群的架构，在从风控基础数据库同步风控基础数据之前，所述方法还包括：将所述风控系统节点的节点信息注册至所述分布式集群的注册中心中，以使所述业务系统通过访问所述注册中心获取节点信息，并根据所述节点信息发送业务报文。

为满足实际业务场景下风控处理的实时性和高并发等要求，本申请实施例的风控系统采用分布式集群架构。注册中心是分布式集群架构中的特有概念，是分布式集群架构中所有服务器节点注册信息等相关功能的专用服务器，注册的地址包括服务器的名称与对应IP地址，分布式环境下的服务节点在启动时都会向注册中心注册自己的网络地址和名称等节点信息。通过注册中心统一维护和管理各个服务节点的节点信息，实现服务调度以及服务和注册中心、服务与服务之间的通信。

基于此，如图4所示，提供了本申请实施例中一种风控系统与业务系统的交互流程示意图。本申请实施例的风控系统节点作为分布式集群中的一个服务节点，可以在启动时在注册中心中注册自己的节点信息，这样上游业务系统可以从注册中心拉取到风控系统的所有节点信息，并加载至业务系统的内存中，业务系统通过遍历所有在线的风控系统节点，调用风控系统的HTTP接口以报文形式发送风控动态数据。

在本申请的一些实施例中，所述根据所述风控基础数据和所述风控动态数据进行风险计算，得到用户的风险计算结果包括：根据所述风控动态数据确定所述风控动态数据对应的用户终端；确定所述风控动态数据对应的用户终端是否为所述风控系统节点中已注册的用户终端；在所述风控动态数据对应的用户终端为所述风控系统节点中已注册的用户终端的情况下，根据所述风控基础数据和所述风控动态数据进行风险计算，得到所述用户的风险计算结果。

在用户登录用户终端时，会先将用户终端的唯一标识信息注册到其中一个正常运行的风控系统节点上，因此一个风控系统节点可能只负责管理一个或一部分用户的信息。但由于同一业务场景下，每一个风控节点都会从风控基础数据库中同步到相同的风控基础数据，且上游业务系统也会将风险动态数据发送至所有遍历到的在线的风控系统节点。但风险动态数据是基于用户的实际操作产生的，风险动态数据与用户存在对应关系，因此可能出现的情况是，当前的风控系统节点接收到的风险动态数据所对应的用户可能并不是之前已在自己这里注册的用户，此时风控系统节点由于缺少用户相关信息而无法计算或者无法准确计算用户的风险。

基于此，本申请实施例的风控系统节点在计算用户的风险时，可以先判断当前的风控动态数据对应的用户终端是否为风控系统节点中已注册的用户终端，如果是，则可以根据风控基础数据和风控动态数据进行风险计算，提高风险计算结果的准确性。

此外，当风控基础数据或者风控动态数据发生变化时，风控系统节点还可以根据变化后的数据实时更新风险计算结果。

在本申请的一些实施例中，所述将所述用户的风险计算结果发送至用户终端包括：基于风险计算结果数据库，确定所述用户的风险计算结果是否发生变化；在所述用户的风险计算结果发生变化的情况下，将所述用户的风险计算结果发送至用户终端。

由于用户的风险是实时计算的，因此会得到用户的多个风险计算结果，这些风险计算结果可以由风险计算结果数据库统一维护，在向用户终端推送风险计算结果时，本申请实施例采取的一种推送策略可以是基于风险计算结果数据库中记录的用户的风险计算结果，判断当前的风险计算结果是否发生变化，在当前的风险计算结果发生变化的情况下，再将用户的风险计算结果发送至用户终端，此种方式可以避免频繁向用户终端推送风险计算结果，提高用户的体验。

在本申请的一些实施例中，所述将所述用户的风险计算结果发送至用户终端包括：确定用户终端的在线状态，所述用户终端为在所述风控系统节点中已注册的用户终端；若所述用户终端的在线状态为在线，则将所述用户的风险计算结果发送至所述用户终端；否则，则不发送所述用户的风险计算结果。

本申请实施例采取的另一种推送策略可以是线上推送，在向用户终端推送风险计算结果时，先判断用户终端的在线状态，如果用户终端在线，则将用户的风险计算结果发送至用户终端展示，例如可以在用户终端以弹窗的形式展示，从而便于用户及时、直观地了解自己的风险情况。

当然，除了线上推送的方式，也可以采取其他推送方式，如短信、邮件等方式，具体如何推送，本领域技术人员可以根据实际需求灵活设置，在此不作具体限定。

需要说明的是，上述和四十里中的推送策略也可以根据实际情况结合使用，即在用户的风险计算结果发生变化且用户终端处于在线的情况下，在向用户终端推送风险计算结果。

在本申请的一些实施例中，在根据所述风控动态数据和所述风控基础数据进行风险计算，得到用户的风险计算结果之后，所述方法还包括：将所述用户的风险计算结果保留在所述风控系统节点的内存中，并将所述用户的风险计算结果存储至风险计算结果数据库中。

在得到用户的风险计算结果后，一方面可以将用户的风险计算结果暂时保存在风控系统节点的内存中，另一方面还可以将用户的风险计算结果存储至风险计算结果数据库中。内存中和风险计算结果数据库中保存的风险计算结果都可以作为判断风险计算结果是否发生变化的依据，除此之外，由于内存空间有限，后续可能会涉及内存的定期清理，因此将风险计算结果存储至风险计算结果数据库中，可以实现数据的持久化存储，便于后续数据追溯和分析。

在本申请的一些实施例中，所述方法还包括：接收业务系统的风控数据清理指令；根据所述业务系统的风控数据清理指令对所述风控系统节点的内存中的风险计算结果进行清理。

由于风控系统节点的内存有限，为了避免对节点的处理性能造成影响，本申请实施例可以按照一定频率定期动态重启风控系统，对内存中的风险计算结果进行清理，从而避免内存中遗留大量的垃圾数据，影响风控系统性能。

如图5所示，提供了本申请实施例中一种内存数据清理的流程示意图。以交易系统为例，交易系统通常以日切的方式将系统从当前工作日切换到下一工作日，因此交易系统可以通过遍历当前所有在线的风控系统节点，调用风控系统节点的HTTP接口以报文形式发送日切指令，风控系统节点接收到日切指令后，清理内存所有数据，优化风控系统性能，再重复前述实施例中从风控基础数据库中实时加载风控基础数据至内存的步骤，完成基础数据加载，为下一个交易日的用户风险控制做准备。

为了便于对本申请各实施例的理解，如图6所示，提供了本申请实施例中一种业务的风控流程示意图。首先，从风控基础数据库同步风控基础数据并加载至内存中，通过上游业务系统接收业务报文进行解析，得到风控动态数据并加载至内存中。然后，根据风控基础数据和风控动态数据实时计算用户的风险，并在风控基础数据和/或风控动态数据发生变化时触发用户风险的重新计算。之后，在用户的风险计算结果满足推送条件的情况下，将用户的风险计算结果推送至用户终端。在整个过程中，还可以接收上游业务系统的风控数据清理指令，根据风控数据清理指令清理内存中的所有风控数据，释放内存，并重新从风控基础数据库加载风控基础数据，从而为下一阶段的风险计算做准备。

综上所述，本申请的业务的风控方法的关键点主要在于：

1)内存+风控结合的创新机制；

2)风控处理逻辑与业务逻辑解耦；

4)风控基础数据和风控动态数据的分离和加载机制；

5)用户风险的实时计算；

6)动态重启风控系统，优化风控系统性能的机制。

基于此，本申请的业务的风控方法至少取得了如下的技术效果：

1)高实时性。由于整个环节全部在节点的内存中进行，避免了磁盘IO等耗时动作，从输入至输出，耗时通常约几毫秒级别，也避免了多服务节点之间的协调调度耗时。

2)高弹性部署。采用无状态服务部署理念，在运行过程不依赖于其他外部因素(如数据库)，因此配合负载均衡后，可根据需要灵活进行多数据中心、多节点部署扩展或收缩，在扩展或收缩部署过程中不需要既有节点重启，也不影响既有节点在途数据处理。

3)高并发。本申请从两个方面保障了高并发：一是采用内存存储数据，提升了处理性能，单节点能响应更多并发压力；二是由于具有无状态服务部署特点，可配合负载均衡实现大规模快速部署，进而实现整体高并发。

4)动态重启风控系统。在不停用风控系统服务的情况下，通过上游系统指令自动清理内存数据，动态重启风控系统，优化风控系统性能。

本申请实施例还提供了一种业务的风控装置700，如图7所示，提供了本申请实施例中一种业务的风控装置的结构示意图，所述业务的风控装置应用于风控系统中的风控系统节点，所述业务的风控装置700包括：第一加载单元710、第二加载单元720、风险计算单元730以及发送单元740，其中：

第一加载单元710，用于从风控基础数据库同步风控基础数据，并将所述风控基础数据加载至所述风控系统节点的内存中；

第二加载单元720，用于从根据业务系统发送的业务报文确定风控动态数据，并将所述风控动态数据加载至所述风控系统节点的内存中；

风险计算单元730，用于根据所述风控基础数据和所述风控动态数据进行风险计算，得到用户的风险计算结果；

发送单元740，用于将所述用户的风险计算结果发送至用户终端。

在本申请的一些实施例中，所述风控基础数据是从所述风控基础数据库同步的第一风控基础数据，所述第一加载单元710具体用于：从所述风控基础数据库获取第二风控基础数据的版本标识；将所述第一风控基础数据的版本标识与所述第二风控基础数据的版本标识进行比较；若所述第一风控基础数据的版本标识与所述第二风控基础数据的版本标识不一致，则将所述第二风控基础数据更新至所述风控系统节点的内存中；否则，则不更新。

在本申请的一些实施例中，所述风控系统为分布式集群的架构，所述装置还包括：注册单元，用于在从风控基础数据库同步风控基础数据之前，将所述风控系统节点的节点信息注册至所述分布式集群的注册中心中，以使所述业务系统通过访问所述注册中心获取节点信息，并根据所述节点信息发送业务报文。

在本申请的一些实施例中，所述风险计算单元730具体用于：根据所述风控动态数据确定所述风控动态数据对应的用户终端；确定所述风控动态数据对应的用户终端是否为所述风控系统节点中已注册的用户终端；在所述风控动态数据对应的用户终端为所述风控系统节点中已注册的用户终端的情况下，根据所述风控基础数据和所述风控动态数据进行风险计算，得到所述用户的风险计算结果。

在本申请的一些实施例中，所述发送单元740具体用于：基于风险计算结果数据库，确定所述用户的风险计算结果是否发生变化；在所述用户的风险计算结果发生变化的情况下，将所述用户的风险计算结果发送至用户终端。

在本申请的一些实施例中，所述发送单元740具体用于：确定用户终端的在线状态，所述用户终端为在所述风控系统节点中已注册的用户终端；若所述用户终端的在线状态为在线，则将所述用户的风险计算结果发送至所述用户终端；否则，则不发送所述用户的风险计算结果。

在本申请的一些实施例中，所述装置还包括：存储单元，用于在根据所述风控动态数据和所述风控基础数据进行风险计算，得到用户的风险计算结果之后，将所述用户的风险计算结果保留在所述风控系统节点的内存中，并将所述用户的风险计算结果存储至风险计算结果数据库中。

在本申请的一些实施例中，所述装置还包括：接收单元，用于接收业务系统的风控数据清理指令；清理单元，用于根据所述业务系统的风控数据清理指令对所述风控系统节点的内存中的风险计算结果进行清理。

能够理解，上述业务的风控装置，能够实现前述实施例中提供的业务的风控方法的各个步骤，关于业务的风控方法的相关阐释均适用于业务的风控装置，此处不再赘述。

图8是本申请的一个实施例业务的风控系统的结构示意图。请参考图8，在硬件层面，该业务的风控系统包括多个风控系统节点，风控系统节点包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(Random-Access Memory，RAM)，也可能还包括非易失性存储器(non-volatile memory)，例如至少1个磁盘存储器等。当然，该业务的风控系统还可能包括其他业务所需要的硬件。

处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是ISA(Industry Standard Architecture，工业标准体系结构)总线、PCI(PeripheralComponent Interconnect，外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图8中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。

存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。

处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成业务的风控装置。处理器，执行存储器所存放的程序，并具体用于执行以下操作：

从风控基础数据库同步风控基础数据，并将所述风控基础数据加载至所述风控系统节点的内存中；

根据业务系统发送的业务报文确定风控动态数据，并将所述风控动态数据加载至所述风控系统节点的内存中；

根据所述风控基础数据和所述风控动态数据进行风险计算，得到用户的风险计算结果；

将所述用户的风险计算结果发送至用户终端。

上述如本申请图1所示实施例揭示的业务的风控装置执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital SignalProcessor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field－Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。

该业务的风控系统还可执行图1中业务的风控装置执行的方法，并实现业务的风控装置在图1所示实施例的功能，本申请实施例在此不再赘述。

本申请实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的业务的风控系统执行时，能够使该业务的风控系统执行图1所示实施例中业务的风控装置执行的方法，并具体用于执行：

从风控基础数据库同步风控基础数据，并将所述风控基础数据加载至所述风控系统节点的内存中；

根据业务系统发送的业务报文确定风控动态数据，并将所述风控动态数据加载至所述风控系统节点的内存中；

根据所述风控基础数据和所述风控动态数据进行风险计算，得到用户的风险计算结果；

将所述用户的风险计算结果发送至用户终端。

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

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

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

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

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

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

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

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

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

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

Claims (11)

1.一种业务的风控方法，其特征在于，所述业务的风控方法由风控系统中的风控系统节点执行，所述业务的风控方法包括：

从风控基础数据库同步风控基础数据，并将所述风控基础数据加载至所述风控系统节点的内存中；

根据业务系统发送的业务报文确定风控动态数据，并将所述风控动态数据加载至所述风控系统节点的内存中；

根据所述风控基础数据和所述风控动态数据进行风险计算，得到用户的风险计算结果；

将所述用户的风险计算结果发送至用户终端。

2.根据权利要求1所述业务的风控方法，其特征在于，所述风控基础数据是从所述风控基础数据库同步的第一风控基础数据，所述从风控基础数据库同步风控基础数据，并将所述风控基础数据加载至所述风控系统节点的内存中包括：

从所述风控基础数据库获取第二风控基础数据的版本标识；

将所述第一风控基础数据的版本标识与所述第二风控基础数据的版本标识进行比较；

若所述第一风控基础数据的版本标识与所述第二风控基础数据的版本标识不一致，则将所述第二风控基础数据更新至所述风控系统节点的内存中；

否则，则不更新。

3.根据权利要求1所述业务的风控方法，其特征在于，所述风控系统为分布式集群的架构，在从风控基础数据库同步风控基础数据之前，所述方法还包括：

将所述风控系统节点的节点信息注册至所述分布式集群的注册中心中，以使所述业务系统通过访问所述注册中心获取节点信息，并根据所述节点信息发送业务报文。

4.根据权利要求1所述业务的风控方法，其特征在于，所述根据所述风控基础数据和所述风控动态数据进行风险计算，得到用户的风险计算结果包括：

根据所述风控动态数据确定所述风控动态数据对应的用户终端；

确定所述风控动态数据对应的用户终端是否为所述风控系统节点中已注册的用户终端；

在所述风控动态数据对应的用户终端为所述风控系统节点中已注册的用户终端的情况下，根据所述风控基础数据和所述风控动态数据进行风险计算，得到所述用户的风险计算结果。

5.根据权利要求1所述业务的风控方法，其特征在于，所述将所述用户的风险计算结果发送至用户终端包括：

基于风险计算结果数据库，确定所述用户的风险计算结果是否发生变化；

在所述用户的风险计算结果发生变化的情况下，将所述用户的风险计算结果发送至用户终端。

6.根据权利要求1所述业务的风控方法，其特征在于，所述将所述用户的风险计算结果发送至用户终端包括：

确定用户终端的在线状态，所述用户终端为在所述风控系统节点中已注册的用户终端；

若所述用户终端的在线状态为在线，则将所述用户的风险计算结果发送至所述用户终端；

否则，则不发送所述用户的风险计算结果。

7.根据权利要求1所述业务的风控方法，其特征在于，在根据所述风控动态数据和所述风控基础数据进行风险计算，得到用户的风险计算结果之后，所述方法还包括：

将所述用户的风险计算结果保留在所述风控系统节点的内存中，并将所述用户的风险计算结果存储至风险计算结果数据库中。

8.根据权利要求1～7任一项所述业务的风控方法，其特征在于，所述方法还包括：

接收业务系统的风控数据清理指令；

根据所述业务系统的风控数据清理指令对所述风控系统节点的内存中的风险计算结果进行清理。

9.一种业务的风控装置，其特征在于，所述业务的风控装置应用于风控系统中的风控系统节点，所述业务的风控装置包括：

第一加载单元，用于从风控基础数据库同步风控基础数据，并将所述风控基础数据加载至所述风控系统节点的内存中；

第二加载单元，用于从根据业务系统发送的业务报文确定风控动态数据，并将所述风控动态数据加载至所述风控系统节点的内存中；

风险计算单元，用于根据所述风控基础数据和所述风控动态数据进行风险计算，得到用户的风险计算结果；

发送单元，用于将所述用户的风险计算结果发送至用户终端。

10.一种业务的风控系统，其特征在于，所述业务的风控系统包括多个风控系统节点，所述风控系统节点包括：

处理器；以及

被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行权利要求1～8之任一所述业务的风控方法。

11.一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的业务的风控系统执行时，使得所述业务的风控系统执行权利要求1～8之任一所述业务的风控方法。