风险测算方法和风险测算系统

摘要

本申请提供了一种风险测算方法和风险测算系统，可以针对不同的风险场景生成计算任务，并采用多线程的方式分布式并行计算，有利于提高运算速度和运行效率。该方法应用于包括管理节点、分发服务器以及多个计算节点的系统，包括：管理节点获取多个用户进行外汇交易时产生的风险数据，分别根据多个用户的风险数据生成多个风险指令，并向分发服务器发送多个风险指令；分发服务器接收多个风险指令，并根据预先生成的路由信息，将多个风险指令分发到多个计算节点中的全部或部分计算节点；全部或部分计算节点接收多个风险指令，并根据多个风险指令，计算多个用户的风险评定参数，风险评定参数用于评价至少一个用户的风险等级。

说明书

技术领域

本申请涉及信息技术领域，尤其涉及一种风险测算方法和风险测算系统。

背景技术

在银行金融市场领域，外汇保证金交易系统可以提供做多和做空的双向交易。在客户存入保证金开始交易后，外汇保证金交易系统的风险测算模块可以不断计算客户的资金充足率，当资金充足率不足时，会发短信通知客户追加保证金或者通过强行平仓的方式来控制风险。

传统的风险测算过程采用轮询的方式对所有的客户进行逐一计算资金充足率，随着客户的增多，计算量不断增大，计算时间越来越长，最后产生超时等性能问题。另外，当市场发生剧烈波动时，风险测算模块的计算量会剧增，可能会因为性能不足而无法及时准确地计算出客户风险指标，无法及时通知用户存在的风险，进而影响到后续的客户追加保证金和强制平仓的操作，导致客户以不利的价格成交，产生不必要的损失，也增加了银行等金融机构被投诉的风险。

发明内容

本申请提供了一种风险测算方法和风险测算系统，可以针对不同的风险场景生成计算任务，并采用多线程的方式分布式并行计算，有利于提高运算速度和运行效率，便于及时地进行资金风险控制。

第一方面，提供了一种风险测算方法，可以应用于包括管理节点、分发服务器以及多个计算节点的系统，该方法包括：管理节点获取多个用户进行外汇交易时产生的风险数据，分别根据多个用户的风险数据生成多个风险指令，并向分发服务器发送多个风险指令，多个风险指令分别包括多个用户的标识信息；分发服务器接收多个风险指令，并根据预先生成的路由信息，将多个风险指令分发到多个计算节点中的全部或部分计算节点，路由信息包括多个计算节点与多个用户的标识信息之间的对应关系；全部或部分计算节点接收多个风险指令，并根据多个风险指令，计算多个用户的风险评定参数，风险评定参数用于评价至少一个用户的风险等级。

结合第一方面，在第一方面的某些实现方式中，全部或部分计算节点接收多个风险指令，并根据多个风险指令，计算多个用户的风险评定参数，包括：全部或部分计算节点中的第一计算节点接收多个风险指令中的第一风险指令；第一计算节点根据第一风险指令，利用与第一风险指令的类型对应的算法计算第一用户的风险评定参数。

结合第一方面，在第一方面的某些实现方式中，第一风险指令包括多个用户中的第一用户的标识信息；在第一计算节点根据第一风险指令，利用与第一风险指令的类型对应的算法计算第一用户的风险评定参数之前，方法还包括：第一计算节点根据第一用户的标识信息，判断第一风险指令是否为签约指令或者第一用户是否存在指令队列；若第一风险指令不是签约指令或者第一用户已存在指令队列，第一计算节点将第一风险指令插入第一用户的指令队列。

结合第一方面，在第一方面的某些实现方式中，方法还包括：新建第一用户的指令队列。

结合第一方面，在第一方面的某些实现方式中，系统还包括备用分发服务器，上述方法还包括：分发服务器周期性地向管理节点发送分发服务器的第一心跳信息；管理节点接收来自分发服务器的第一心跳信息，并开启第一定时器；若管理节点在第一定时器超时之前未收到来自分发服务器的第二心跳信息，则管理节点确定分发服务器发生故障；管理节点将多个风险指令从分发服务器切换至备用分发服务器。

结合第一方面，在第一方面的某些实现方式中，系统还包括集中监控节点，上述方法还包括：管理节点向集中监控节点发送第一警报信息，第一警报信息用于表示分发服务器发生故障；集中监控节点接收第一警报信息，并向运维人员显示通知消息，通知消息用于通知运维人员检查分发服务器。

结合第一方面，在第一方面的某些实现方式中，系统还包括备用计算节点，上述方法还包括：多个计算节点中的第二计算节点周期性地向管理节点发送第二计算节点的第三心跳信息；管理节点接收来自第二计算节点的第三心跳信息，并开启第二定时器；若管理节点在第二定时器超时之前未收到来自第二计算节点的第四心跳信息，则管理节点确定第二计算节点发生故障；管理节点通知分发服务器将发送给第二计算节点的风险指令转移路由至备用计算节点。

结合第一方面，在第一方面的某些实现方式中，系统还包括集中监控节点，上述方法还包括：管理节点向集中监控节点发送第二警报信息，第二警报信息用于表示第二计算节点发生故障；集中监控节点接收第二警报信息，并向运维人员显示通知消息，通知消息用于通知运维人员检查第二计算节点。

结合第一方面，在第一方面的某些实现方式中，系统还包括备用管理节点，备用管理节点和管理节点之间是根据预设规则自动切换的。

结合第一方面，在第一方面的某些实现方式中，风险指令的类型包括下列至少一个：资金类、交易类、时间类、特殊类、或者系统类。

结合第一方面，在第一方面的某些实现方式中，风险数据包括下列至少一个：开仓、平仓、出入金、手工强平、自动强平、即时报价、时间间隔、隔夜息差、或签约。

结合第一方面，在第一方面的某些实现方式中，包括开仓、平仓、手工强平或者自动强平的风险数据对应的风险指令的类型为交易类；包括出入金的风险数据对应的风险指令的类型为资金类；包括即时报价的风险数据对应的风险指令的类型为报价类；包括时间间隔的风险数据对应的风险指令的类型为时间类；包括隔夜息差的风险数据对应的风险指令的类型为特殊类；包括签约的风险数据对应的风险指令的类型为系统类。

第二方面，提供了一种风险测算系统，该系统包括管理节点、分发服务器以及多个计算节点。该管理节点用于：获取多个用户进行外汇交易时产生的风险数据，分别根据多个用户的风险数据生成多个风险指令，并向分发服务器发送多个风险指令，多个风险指令分别包括多个用户的标识信息；分发服务器用于：接收多个风险指令，并根据预先生成的路由信息，将多个风险指令分发到多个计算节点中的全部或部分计算节点，路由信息包括多个计算节点与多个用户的标识信息之间的对应关系；多个计算节点中全部或部分计算节点用于：接收多个风险指令，并根据多个风险指令，计算多个用户的风险评定参数，风险评定参数用于评价多个用户的风险等级。

结合第二方面，在第二方面的某些实现方式中，全部或部分计算节点中第一计算节点用于：接收多个风险指令中的第一风险指令；根据第一风险指令，利用与第一风险指令的类型对应的算法计算第一用户的风险评定参数。

结合第二方面，在第二方面的某些实现方式中，第一风险指令包括多个用户中的第一用户的标识信息；第一计算节点还用于：根据第一用户的标识信息，判断第一风险指令是否为签约指令或者第一用户是否存在指令队列；若第一风险指令不是签约指令或者第一用户已存在指令队列，将第一风险指令插入第一用户的指令队列。

结合第二方面，在第二方面的某些实现方式中，第一计算节点还用于：新建第一用户的指令队列。

结合第二方面，在第二方面的某些实现方式中，系统还包括备用分发服务器，分发服务器还用于：周期性地向管理节点发送分发服务器的第一心跳信息；管理节点还用于：接收来自分发服务器的第一心跳信息，并开启第一定时器；若在第一定时器超时之前未收到来自分发服务器的第二心跳信息，则确定分发服务器发生故障；将多个风险指令从分发服务器切换至备用分发服务器。

结合第二方面，在第二方面的某些实现方式中，系统还包括备用计算节点；多个计算节点中的第二计算节点用于：周期性地向管理节点发送第二计算节点的第三心跳信息；管理节点还用于：接收来自第二计算节点的第三心跳信息，并开启第二定时器；若在第二定时器超时之前未收到来自第二计算节点的第四心跳信息，则确定第二计算节点发生故障；并通知分发服务器将发送给第二计算节点的风险指令转移路由至备用计算节点。

结合第二方面，在第二方面的某些实现方式中，系统还包括集中监控节点；管理节点还用于：向集中监控节点发送第二警报信息，第二警报信息用于表示第二计算节点发生故障；集中监控节点还用于：接收第二警报信息，并向运维人员显示通知消息，通知消息用于通知运维人员检查第二计算节点。

结合第二方面，在第二方面的某些实现方式中，系统还包括备用管理节点，备用管理节点和管理节点之间是根据预设规则自动切换的。

结合第二方面，在第二方面的某些实现方式中，风险指令的类型包括下列至少一个：资金类、交易类、时间类、特殊类、或者系统类。

结合第二方面，在第二方面的某些实现方式中，风险数据包括下列至少一个：开仓、平仓、出入金、手工强平、自动强平、即时报价、时间间隔、隔夜息差、或签约。

结合第二方面，在第二方面的某些实现方式中，包括开仓、平仓、手工强平或者自动强平的风险数据对应的风险指令的类型为交易类；包括出入金的风险数据对应的风险指令的类型为资金类；包括即时报价的风险数据对应的风险指令的类型为报价类；包括时间间隔的风险数据对应的风险指令的类型为时间类；包括隔夜息差的风险数据对应的风险指令的类型为特殊类；包括签约的风险数据对应的风险指令的类型为系统类。

本申请实施例提供的风险测算方法和风险测算系统，将多个用户的风险数据生成多个用户的风险指令，并分发给不同的计算节点进行分布式并行计算，可以有效的提高运算速度和运行效率，提升交易系统的性能，从而及时地实现资金风险控制。

附图说明

图1是本申请实施例提出的一种风险测算系统的架构示意图；

图2是本申请实施例提出的一种风险测算方法的示意性流程图；

图3是本申请实施例提出的另一种风险测算方法的示意性流程图；

图4是本申请实施例提出的一种计算节点内部的处理方法的示意性流程图。

具体实施方式

下面将结合附图，对本申请中的技术方案进行描述。

银行的外汇交易业务指的是将一国的货币按一定的比例兑换成另一国的货币，这个兑换比例叫做汇率。针对个人客户，有两种外汇交易系统：1)实盘交易系统，进行外汇买卖的时候完成实物交割，不能进行做空交易；外汇保证金交易系统，客户在签约并存入不低于交易货币名义本金一定比例金额的人民币或外币保证金之后，便可以进行做多和做空两个方向的交易。

对于外汇保证金交易系统，在客户存入保证金开始交易后，外汇保证金交易系统的风险测算模块可以不断计算客户的资金充足率，评定风险等级，以便进行相应的风险控制处理。例如，当资金充足率不足时，会发短信通知客户追加保证金或者通过强行平仓的方式来控制风险。

传统的风险测算过程采用轮询的方式对所有的客户进行逐一计算资金充足率，随着客户的增多，计算量不断增大，计算时间越来越长，最后产生超时等性能问题。另外，当市场发生剧烈波动时，风险测算模块的计算量会剧增，可能会因为性能不足而无法及时准确地计算出客户风险指标，无法及时通知用户存在的风险，进而影响到后续的客户追加保证金和强制平仓的操作，导致客户以不利的价格成交，产生不必要的损失，也增加了银行等金融机构被投诉的风险。

有鉴于此，本申请实施例提供了一种风险测算方法和风险测算系统，可以针对不同的风险场景生成计算任务，并采用多线程的方式分布式并行计算，有利于提高运算速度和运行效率，便于及时地进行资金风险控制。

为便于理解，首先介绍本申请实施例所涉及的相关术语。

1、做多：是指预期未来价格上涨，以目前价格买入一定数量的股票等价格上涨后，高价卖出，从而赚取差价利润的交易行为。做多的特点为先买入后卖出的交易方式。

2、做空：是指预期未来价格下跌，将手中股票按目前价格卖出，待行情跌后买进，获利差价利润的交易方式。做空的特点为先卖出后买入的交易方式。

3、保证金：一般指客户投资一定数量的资金作为保证金，按一定杠杆倍数在扩大的投资金额范围内进行外汇交易。例如，持有头寸的客户需要缴纳的，作为交易盈亏风险准备的资金。

4、资金充足率：指客户保证金账户中可以用作保证金的资金总和与客户做交易占用的保证金额度之间的比率。

5、云计算：是分布式计算的一种，指的是通过网络“云”将巨大的数据计算处理程序分解成无数个小程序，然后通过多部服务器组成的系统进行并行处理和分行，最后将小程序得到的结果合并返回给用户。

6、四不像(fourinone)：是一种四合一分布式轻量级云计算平台，集成了分布式计算(hadoop)、zookeeper、消息队列(message queue,MQ)、分布式缓存(memcache)四大主要的分布式计算功能，对复杂的分布式计算应用进行了大量简化和归纳。

7、风险指令：是一种数据结构，包含了可能发生风险的各种场景下用于计算资金充足率所需要的数据信息。不同的风险场景下，风险指令的格式不同。

8、分布式调度：在分布式系统中，根据路由算法将风险指令或计算任务按一定的优先级顺序分配给不同计算节点执行的过程。

9、线程同步：多线程通过特定的设置来控制线程之间的执行顺序。

下面结合图1至图4，详细介绍本申请实施例的风险测算系统和风险测算方法。

图1示出了本申请实施例提供的一种风险测算系统100的架构图，该风险测算系统100包括：管理节点、分发服务器以及多个计算节点。其中，多个计算节点以第一计算节点和第二计算节点为例进行说明。应理解，多个计算节点中应不限于第一计算节点和第二计算节点，计算节点的个数仅仅为一个示例。

示例性地，该风险测算系统100可以是基于fourinone开源云平台作为基础开发框架所构建的系统。

管理节点可以监控分发服务器、第一计算节点以及第二计算节点的心跳信息，以了解分发服务器、第一计算节点以及第二计算节点的运行状态，可以更好的引导分发服务器进行路由规划和路由重定向。

分发服务器可以从管理节点获取指令，并根据路由表向第一计算节点和第二计算节点分发指令。

第一计算节点和第二计算节点可以对指令进行解析和计算处理。

可选地，上述风险测算系统100还可以包括备用分发服务器。该备用分发服务器可以用于：当分发服务器故障时，接替分发服务器的任务。

可选地，上述风险测算系统100还可以包括备用计算节点。该备用计算节点可以用于：当第一计算节点或者第二计算节点故障时，接替第一计算节点或者第二计算节点的任务。

可选地，上述风险测算系统100还可以包括集中监控平台。集中监控平台可以用于：接收管理节点发送的警报信息，并向运维人员发送短信通知该风险测算系统100的问题。

可选地，上述风险测算系统100还可以包括备用管理节点。该备用管理节点可以用于：当管理节点故障时，接替管理节点的任务。备用管理节点和管理节点之间可以是根据预设规则自动切换的。例如，该预设规则可以是zookeeper算法。

可选地，在上述风险测算系统100中，当多个计算节点中某个计算节点负载量过大时，在该风险测算系统100中可以启动一个新的计算节点并重启分发服务器就可以进行性能扩展，实现动态可伸缩性。

基于上述风险测算系统100，本申请实施例提供了风险测算方法。图2为本申请实施例提供的一种风险测算方法200的示意性流程图。该方法200可以应用于上述风险测算系统100，但本申请实施例不限于此。

该方法200可以包括下列步骤：

S201，管理节点获取多个用户进行外汇交易时产生的风险数据，分别根据多个用户的风险数据生成多个风险指令，多个风险指令分别包括多个用户的标识信息。

用户进行外汇交易时，进行的某些操作可能会产生风险，导致资产受损。本申请实施例将用户进行外汇交易时，可能产生风险的操作而产生的数据称为风险数据。例如，用户在外汇保证金交易系统的页面展示部分进行外汇交易时，进行了风险操作，管理节点可以获取到该风险操作产生的风险数据。

可选地，风险数据可以包括下列至少一个：开仓、平仓、出入金、手工强平、自动强平、即时报价、时间间隔、隔夜息差、或签约。

多个用户在外汇保证金交易系统上进行交易，管理节点均可以获取该多个用户进行外汇交易时产生的风险数据。管理节点获取到该多个用户的风险操作产生的风险数据后，分别根据多个用户的风险数据生成多个风险指令，该风险指令中可以包括在该风险下计算风险评定参数所需要的数据信息。另外，该风险指令中还包括用户的标识信息，用于区分不同用户的风险指令。

在不同的风险下，管理节点计算风险评定参数所需要的数据信息不同，故在不同的风险下，生成风险指令的数据结构不同。

可选地，风险指令的类型可以包括下列至少一个：资金类、交易类、时间类、特殊类、或者系统类。

可选地，包括开仓、平仓、手工强平或者自动强平的风险数据对应的风险指令的类型为交易类；包括出入金的风险数据对应的风险指令的类型为资金类；包括即时报价的风险数据对应的风险指令的类型为报价类；包括时间间隔的风险数据对应的风险指令的类型为时间类；包括隔夜息差的风险数据对应的风险指令的类型为特殊类；包括签约的风险数据对应的风险指令的类型为系统类。

S202，管理节点向分发服务器发送多个风险指令，相应地，分发服务器接收该多个风险指令。

可选地，管理节点还可以将多个风险指令存储在风险指令队列中，相应地，分发服务器从风险指令队列中获取风险指令。

S203，分发服务器根据预先生成的路由信息，将多个风险指令分发到多个计算节点中的全部或部分计算节点，路由信息包括多个计算节点与多个用户的标识信息之间的对应关系。

该路由信息中的对应关系可以是分发服务器根据路由算法确定的。

分发服务器获取到风险指令后，可以根据风险指令中用户的标识信息，在路由信息中确定该用户的标识信息对应的计算节点，并将该风险指令分发到对应的计算节点。

可选地，若分发服务器在路由信息中找不到该用户的标识信息对应的计算节点，则可以通过负载均衡的方法，将该风险指令分发到多个计算节点中处理风险指令最少的计算节点。

可选地，若分发服务器在路由信息中找不到该用户的标识信息对应的计算节点，则可以通过轮询的方式，将该风险指令依次分发到多个计算节点。例如，分发服务器获取到风险指令1后，根据路由信息，将风险指令1分发到风险指令1中用户的标识信息对应的计算节点2，若分发服务器获取到风险指令2后，根据路由信息，找不到风险指令2中用户的标识信息对应的计算节点，则分发服务器将该风险指令1分发到与计算节点2相邻的计算节点(计算节点1或计算节点3)。

S204，全部或部分计算节点接收多个风险指令，并根据多个风险指令，计算多个用户的风险评定参数，风险评定参数用于评价多个用户的风险等级。

不同的计算节点接收到不同用户的风险指令后，采集相应的数据信息，并行计算用户的风险评定参数。该风险评定参数可以评价用户的风险等级，以确定是否要发送短信通知用户追加保证金或者通过强行平仓的方式来控制风险。示例性地，该风险评定参数可以是资金充足率。

应理解，风险指令的类型不同，其数据结构不同，计算风险评定参数所需要的数据信息不同，故计算节点可以利用与风险指令的类型对应的算法计算用户的风险评定参数。

本申请实施例提供的风险测算方法，将多个用户的风险数据生成多个用户的风险指令，并分发给不同的计算节点进行分布式并行计算，可以有效的提高运算速度和运行效率，提升交易系统的性能，从而及时地实现资金风险控制。

作为一个可选的实施例，上述方法200还可以包括：分发服务器周期性地向管理节点发送分发服务器的第一心跳信息；管理节点接收来自分发服务器的第一心跳信息，并开启第一定时器；若管理节点在第一定时器超时之前未收到来自分发服务器的第二心跳信息，则管理节点确定分发服务器发生故障；管理节点将多个风险指令从分发服务器切换至备用分发服务器。

分发服务器可以每隔一段时间向管理节点发送第一心跳信息。例如，分发服务器可以每隔3秒向管理节点发送第一心跳信息，对应地，管理节点可以每隔3秒获取分发服务器的第一心跳信息。

第一定时器的时间可以是管理节点预设的。例如，该定时器的时间可以是6秒，若管理节点接收到第一心跳信息后，间隔6秒，仍未收到来自分发服务器的第二心跳信息，则管理节点可以确定分发服务器发生故障；管理节点将多个风险指令从分发服务器切换至备用分发服务器。

备用分发服务器监听到配置变化时，将会接管分发服务器的工作，即分发服务器发生故障后，管理节点可以备用分发服务器将会替代分发服务器的所有功能，并将该分发服务器的可用标志置为备用分发服务器。

可选地，管理节点可以通过扫描消息总线来监控分发服务器的心跳信息，当发现心跳信息异常时，将分发服务器切换至备用分发服务器。

应理解，备用分发服务器在系统开始运行时，不进行任务分发，在有分发服务器失效时接管失效分发服务器的所有任务。

本申请实施例提供的风险测算方法，管理节点可以通过分发服务器的心跳信息检测分发服务器的工作状况，并设置备用分发服务器，当分发服务器发生故障时，使用备用分发服务器替代分发服务器，保证系统的正常运行，有利于提升系统的可用性，提升交易系统的性能，从而及时地实现资金风险控制。

作为一个可选的实施例，上述方法200还可以包括：管理节点向集中监控节点发送第一警报信息，第一警报信息用于表示分发服务器发生故障；集中监控节点接收第一警报信息，并向运维人员显示通知消息，通知消息用于通知运维人员检查分发服务器。

本申请实施例提供的风险测算方法，集中监控节点接收到第一警报信息后，可以向运维人员发送通知消息，便于运维人员及时发现分发服务器的问题，及时地修复分发服务器，有利于提升系统的可用性，提升交易系统的性能，从而及时地实现资金风险控制。

作为一个可选的实施例，上述方法200可以还包括：多个计算节点中的第二计算节点周期性地向管理节点发送第二计算节点的第三心跳信息；管理节点接收来自第二计算节点的第三心跳信息，并开启第二定时器；若管理节点在第二定时器超时之前未收到来自第二计算节点的第四心跳信息，则管理节点确定第二计算节点发生故障；管理节点通知分发服务器将发送给第二计算节点的风险指令转移路由至备用计算节点。

第二计算节点可以每隔一段时间向管理节点发送第二计算节点的第三心跳信息。例如，第二计算节点可以每隔5秒向管理节点发送第二计算节点的第三心跳信息，对应地，管理节点可以每隔5秒获取第二计算节点的第三心跳信息。

第二计算节点向管理节点发送第三心跳信息的时间间隔与分发服务器向管理节点发送第一心跳信息的时间间隔可以相同，也可以不同，本申请实施例不做限定。

第二定时器的时间可以是管理节点预设的。例如，该定时器的时间可以是10秒，若管理节点接收到第三心跳信息后，间隔10秒，仍未收到来自第二计算节点的第四心跳信息，则管理节点可以确定第二计算节点发生故障；管理节点通知分发服务器将发送给第二计算节点的风险指令转移路由至备用计算节点。

第二计算节点发生故障后，管理节点可以引导分发服务器进行路由规划和路由重定向，即管理节点可以通知分发服务器将第二计算节点的所有功能转移路由至备用计算节点。

可选地，管理节点可以通过扫描消息总线来监控第二计算节点的心跳信息，当发现心跳信息异常时，将第二计算节点切换至备用计算节点。

应理解，备用计算节点在系统开始运行时，不分配任务，在有计算节点失效时接管失效计算节点的所有任务。

本申请实施例提供的风险测算方法，管理节点可以通过第二计算节点的心跳信息检测第二计算节点的工作状况，并设置备用计算节点，当第二计算节点发生故障时，使用备用计算节点替代第二计算节点，保证系统的正常运行，有利于提升系统的可用性，提升交易系统的性能，从而及时地实现资金风险控制。

作为一个可选的实施例，上述方法200还包括：管理节点向集中监控节点发送第二警报信息，第二警报信息用于表示第二计算节点发生故障；集中监控节点接收第二警报信息，并向运维人员显示通知消息，通知消息用于通知运维人员检查第二计算节点。

本申请实施例提供的风险测算方法，集中监控节点接收到第二警报信息后，可以向运维人员发送通知消息，便于运维人员及时发现第二计算节点的问题，及时地修复第二计算节点，有利于提升系统的可用性，提升交易系统的性能，从而及时地实现资金风险控制。

本申请实施例提供的风险测算方法，通过备用管理节点和管理节点之间的切换，当管理节点满足不了需求时，自动切换备用管理节点，有利于提升系统的可用性，提升交易系统的性能，从而及时地实现资金风险控制。

下面，以图3所示的风险测算方法300的示意性流程图为例，对本申请实施例提供的风险测算方法进行详细地说明。该方法300可以应用于上述风险测算系统100。

如图3所示，风险测算系统100在运行时，该风险测算方法300可以包括以下步骤：

S301，管理节点可以获取签约、开平仓(开仓和平仓)、出入金(出金和入金)、手工强平、即时报价、时间间隔、隔夜息差以及自动强平等风险数据，并根据该风险数据，生成风险指令。

其中，用户进行签约、开仓、平仓、出金以及入金可以产生签约、开平仓以及出入金的风险数据。管理员手动进行强平操作可以产生手动强平的风险数据。报价引擎可以产生即时报价的风险数据，时终进程可以产生时间间隔的风险数据，日终批量可以产生隔夜息差的风险数据。管理节点可以通过检测用户的风险状态产生自动强平的风险数据。

管理节点可以获取签约的风险数据后，生成签约的风险指令；可以获取开平仓的风险数据后，生成开平仓的风险指令；可以获取出入金的风险数据后，生成出入金的风险指令；可以获取手动强平的风险数据后，生成手工强平的风险指令；可以获取即时报价的风险数据后，生成报价的风险指令；可以获得时间间隔的风险数据后，生成时间的风险指令；可以获得隔夜息差的风险数据后，生成隔夜息差的风险指令；还可以获取到自动强平的风险数据后，生成自动强平的风险指令。

管理节点生成风险指令后，可以将该风险指令保存在风险指令列表中。

S302，分发服务器可以轮询风险指令列表中的风险指令，并可以根据用户的标识信息(例如，用户的客户号)和路由信息，将风险指令分发到对应的计算节点。

具体地，分发服务器在进行分布式调度时，可以通过读风险指令处理指针表得知当前应该处理风险指令队列表中的风险指令序号范围，以此为依据查询风险指令。例如，分发服务器在进行分布式调度时，每次查询1000个风险指令，则可以通过读风险指令处理指针表中的0至999以获取1000个风险指令进行处理。

分发服务器获取风险指令后，可以根据用户的标识信息判断该用户是否在路由表中。若用户在路由表中，直接根据路由表确定该用户所在的计算节点；若用户不在路由表中，则根据负载均衡算法或轮询的方式确定该新增用户对应的计算节点。

S303，多个计算节点中的全部或部分计算节点接收到风险指令后，可以将接收到的风险指令存在指令队列中，并进行指令解析。

指令解析是指计算节点判断该风险指令是否为签约指令。

示例性地，若多个计算节点中第一计算节点接收到第一风险指令，该则第一风险指令包括第一用户的标识信息，第一计算节点可以根据第一用户的标识信息，判断该第一风险指令是否为签约指令或者第一用户是否存在指令队列中。

应理解，第一用户的标识信息用于表示该第一风险指令是该第一用户进行风险操作产生的风险指令。

若第一风险指令为签约指令或者第一用户不存在指令队列，第一计算节点可以新建第一用户的指令队列。该第一用户的指令队列用于存储该第一用户进行风险操作产生的风险指令。

若第一风险指令不是签约指令且第一用户已存在指令队列，第一计算节点可以将第一风险指令插入第一用户的指令队列。

S304，多个计算节点中的全部或部分计算节点根据解析结果进行分布式计算，得到资金充足率，并根据资金充足率评定用户的风险状态。若用户的风险状态为风险，则将该用户的风险状态保存在风险用户清单中。

例如，第一计算节点可以从第一用户的指令队列中获取第一风险指令，并根据第一风险指令，采集相应的数据信息，并采集产品参数、用户寸头以及用户资金等信息，利用与第一风险指令的类型对应的算法计算第一用户的资金充足率。

可选地，风险用户清单中还可以保存用户的资金充足率和客户号等信息。

上述评定用户是否为风险状态的标准可以是预设的。

S305，管理节点可以检测用户的风险状态，若用户的风险状态为强平状态，则触发自动强平；若用户的风险状态为追保状态，则通知用户追保。

例如，计算节点可以预先设定资金充足率小于等于20％时，用户的风险状态为强平状态，管理节点需要触发自动强平；资金充足率大于20％但小于等于50％时，用户的风险状态为追保状态，管理节点需要通知用户进行追保操作。应理解，资金充足率大于50％时，用户的风险状态为安全。

可选地，上述方法300还包括：

S306，管理节点可以对分发服务器和多个计算节点进行监控，得到分发服务器和多个计算节点的运行状态，进而引导引导分发服务器进行路由规划和路由重定向。例如，管理节点可以监控分发服务器和多个计算节点的心跳信息。

作为一个可选的实施例，上述第一计算节点内部对第一风险指令的解析和处理可以是一个N×N的多线程并发流程。线程可以包括用户签约处理线程、指令处理线程、各个处理器类、结果处理线程以及异常客户处理线程等类型。每类线程均可以使用各自的线程池实现并发。其中，用户签约处理线程可以用于根据签约指令生成每个用户在该产品下的风险指令队列，并将获取的该用户的非签约指令(除签约指令外的其他风险指令)插入该用户指令队列；指令处理线程可以用于处理用户风险指令队列中未处理的指令，并调用各个处理器类处理；各个处理器类可以用于获取风险指令中包括的数据信息，并采集产品参数、用户头寸以及用户资金等数据，计算该用户的资金充足率和该用户的浮动盈亏，并将结果插入用户结果队列；结果处理线程可以从用户结果队列中取出计算结果并更新风险用户表；异常用户处理线程进行异常风险指令处理。

图4示出了第一计算节点内部的处理方法400的示意性流程图。如图4所示，图中包括线程1、线程2、线程3、线程4以及线程5，分别对应上述用户签约处理线程、指令处理线程、各个处理器类、结果处理线程以及异常客户处理线程。

第一计算节点内部的处理方法400可以包括以下步骤：

S401，第一计算节点接收分发服务器的第一风险指令后，可以通过线程3(例如，各个处理器类的parse)根据第一用户的标识信息判断该第一风险指令是否为签约指令。

可选地，第一计算节点还可以根据第一用户的标识信息判断该第一用户是否存在指令队列中。

S402，若该第一风险指令为签约指令(或者第一用户不存在指令队列)，则插入签约指令队列中。其中，该签约指令队列包括多个用户的签约指令。例如，该签约指令队列可以是SING_QUEUE。

S403，第一计算节点可以通过线程1(例如，ComputeNodeSignThread)从签约指令队列中取出签约指令，并根据该签约指令中第一用户的标识信息，新建该第一用户的指令队列，并在总用户指令队列添加该第一用户的指令队列以更新总用户指令队列，该第一用户的指令队列用于存储该第一用户的风险指令。

S404，若该第一风险指令不是签约指令(或者第一用户存在指令队列)，则根据第一风险指令中第一用户的标识信息，将该第一风险指令插入该第一用户的指令队列中，并更新总用户指令队列。其中，第一用户的指令队列用于存储该第一用户的风险指令，总用户指令队列用于存储多个用户的指令队列。例如，该总用户指令队列可以为CUSTOMER_VIEW_CMD_QUEUES。

可选地，第一计算节点可以通过线程3(例如，各个处理器类的parse)根据总用户指令队列中的风险指令查询第一计算节点是否包括了处理所有风险指令的线程。

S405，第一计算节点可以通过线程2(例如，ComputeNodeProcessorThread)从总用户指令队列中选取未处理的风险指令，然后通过线程3(例如，各个处理器类的process)处理该风险指令，即计算用户的资金充足率，并判断是否处理成功。

S406，若第一计算节点处理成功，则将计算结果插入用户结果队列中。例如，该用户结果队列可以为CUSTOMER_VIEW_LOG_QUEUES。

S407，第一计算节点可以通过线程4(例如，ComputeNodeLogThread)从用户结果队列中取出计算结果，若该计算结果为风险结果，则更新风险用户表。

S408，若第一计算节点未处理成功，则通过线程2(例如，ComputeNodeProcessorThread)将该风险指令插入异常用户队列。例如，该异常用户队列可以为ERROR_CUS_SET。

可选地，第一计算节点通过线程5(例如，ComputeNodeErrorCusThread)从对该异常用户队列中取出风险指令并进行异常风险指令处理。

作为一个可选的实施例，在上述风险测算系统100在运行前，需要先启动管理节点，再启动多个计算节点和分发服务器。

示例性地，管理节点中包括消息总线，该消息总线类似于Map的MQ树，当计算节点和分发服务器启动时，可以先通过远程方法调用(remote method invocation，RMI)进行服务注册，然后再将多个计算节点和分发服务器的详细信息保存在总线里。

分发服务器启动后，可以启动轮询分发进程。该分发进程进行初始化时，可以根据当前的计算节点数量和用户总数生成路由表(即上述路由信息)，将路由表分发给多个计算节点。应理解，该路由表中包括多个计算节点与多个用户的对应关系。例如，该多个计算节点包括计算节点1、计算节点2以及计算节点3，该用户总数为3000。分发服务器生成的路由表可以是计算节点1对应1000个用户，计算节点2对应500个用户，该计算节点3对应1000个用户。

该多个计算节点接收到路由表后，可以根据该路由表进行初始化，即查询本计算节点负责处理的用户的资金和持仓信息，加载入内存。

上述分发进程等所有计算节点反馈初始化完成信息后，可以进行风险指令处理。

应理解，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read-only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以权利要求的保护范围为准。