处理节点的额度控制方法及装置、存储介质、终端

本发明涉及数据配送技术领域，具体地涉及一种处理节点的额度控制方法及装置、存储介质、终端。

在高并发的数据配送系统中，数据需方需要付费查询数据供方的数据资源。具体而言，数据需方可以通过账户充值、授信等方式获取额度。因而，对数据需方的额度管理是数据交易环节中的重要一环。但这种机制存在以下问题：

1.多进程同一时间对同一个额度数据竞争

在高并发系统中，海量用户短时间内对某些数据进行频繁访问和更新。当前一个进程的写数据库操作未完成时后续进程发生读取数据库操作，后续进程读取的状态与前面进程读取的状态相同就会发生实际额度不够也能进行交易，即真实花费会超过额度。

2.授信和余额统一，难以控制

目前的授信(包括供方授信和数据交易平台授信)和余额都是相同的额度进行管理。这样在扣款和对账方面又不便于管理。

本发明解决的技术问题是多进程高并发下的额度竞争问题。

为解决上述技术问题，本发明实施例提供一种处理节点的额度控制方法，所述处理节点处于分布式处理系统中，包括：接收第一额度申请请求，所述第一额度申请请求包括发送方的标识；根据所述发送方的标识判断待执行进程中是否存在关联于所述发送方的第二额度申请请求；当判断结果表明不存在所述第二额度申请请求时，确定所述发送方关联的多个账户的优先级；按照优先级由高到低的顺序依次评估各账户的账户额度，以确定所述第一额度申请请求关联的额度申请成功或失败。

可选的，所述第一额度申请请求来自与所述处理节点对应的发送方。

可选的，所述分布式系统还包括至少一个分配节点，所述分配节点用于对所述发送方的标识进行哈希计算以确定所述发送方对应的处理节点，并将所述发送方发送的额度申请请求发送至对应的处理节点。

可选的，对于所述发送方关联的多个账户，其中不同账户的账户额度的来源不同。

可选的，所述额度控制方法还包括：当判断结果表明存在所述第二额度申请请求时，将所述第一额度申请请求添加至所述待执行进程。

可选的，所述额度控制方法还包括：在所述第二额度申请请求执行完毕后，执行所述第一额度申请请求。

可选的，所述按照优先级由高到低的顺序依次评估各账户的账户额度，以确定所述第一额度申请请求关联的额度申请成功或失败包括：自优先级最高的账户起，判断所述账户的账户额度是否满足所述第一额度申请请求的申请额度；当判断结果表明所述多个账户中任一账户的账户额度满足所述第一额度申请请求的申请额度时，确定所述第一额度申请请求关联的额度申请成功；否则，确定所述第一额度申请请求关联的额度申请失败。

为解决上述技术问题，本发明实施例还提供一种处理节点的额度控制装置，所述处理节点处于分布式处理系统中，包括：接收模块，用于接收第一额度申请请求，所述第一额度申请请求包括发送方的标识；判断模块，用于根据所述发送方的标识判断待执行进程中是否存在关联于所述发送方的第二额度申请请求；确定模块，当判断结果表明不存在所述第二额度申请请求时，确定所述发送方关联的多个账户的优先级；评估模块，用于按照优先级由高到低的顺序依次评估各账户的账户额度，以确定所述第一额度申请请求关联的额度申请成功或失败。

为解决上述技术问题，本发明实施例还提供一种存储介质，其上存储有计算机指令，所述计算机指令运行时执行上述方法的步骤。

为解决上述技术问题，本发明实施例还提供一种终端，包括存储器和处理器，所述存储器上存储有能够在所述处理器上运行的计算机指令，所述处理器运行所述计算机指令时执行上述方法的步骤。

与现有技术相比，本发明实施例的技术方案具有以下有益效果：

本发明实施例提供一种处理节点的额度控制方法，所述处理节点处于分布式处理系统中，包括：接收第一额度申请请求，所述第一额度申请请求包括发送方的标识；根据所述发送方的标识判断待执行进程中是否存在关联于所述发送方的第二额度申请请求；当判断结果表明不存在所述第二额度申请请求时，确定所述发送方关联的多个账户的优先级；按照优先级由高到低的顺序依次评估各账户的账户额度，以确定所述第一额度申请请求关联的额度申请成功或失败。采用本实施例的方案能够有效避免多进程同一时间对同一个额度数据的竞争现象，解决多进程高并发下的额度竞争问题，且实现额度拆分，使得额度管理更精细化。

进一步，所述第一额度申请请求来自与所述处理节点对应的发送方。由此，能够以更高效的方式实现分布式处理系统中同一发送方的请求均落到同一处理节点上执行，避免多个处理节点同时处理同一发送方的不同请求时可能出现的额度竞争情形。

进一步，所述分布式系统还包括至少一个分配节点，所述分配节点用于对所述发送方的标识进行哈希计算以确定所述发送方对应的处理节点，并将所述发送方发送的额度申请请求发送至对应的处理节点。由此，可以在采用nginx实现负载均衡的同时，以执行效率更高的方式确保同一发送方的请求均落到同一处理节点上执行，从而有效解决多进程高并发下的额度竞争问题。

图1是本发明实施例的一种处理节点的额度控制方法的流程图；

图2是图1中步骤S104的一个具体实施方式的流程图；

图3是本发明实施例的一种处理节点的额度控制装置的结构示意图；

图4是本发明实施例一个典型应用场景的示意图。

如背景技术所言，现有数据配送系统中的额度管理机制存在诸多缺陷，无法解决多进程高并发下的额度竞争问题，且对用户账户的管理不够优化。

另一方面，在分布式处理系统中，系统会根据各节点的忙闲程度等因素动态的分配任务，这就导致同一数据需方为进行多个数据配送而分别发送的多条额度申请请求会被分配至多个节点进行处理。以数据需方的余额为100为例，数据需方先发送额度申请请求1以请求进行数据配送操作a，分布式处理系统将额度申请请求1分配至A节点处理，额度申请请求1的需求额度为90；在A节点处理期间，数据需方又发送额度申请请求2以请求进行数据配送操作b，分布式处理系统将额度申请请求2分配至B节点处理，额度申请请求2的需求额度为60。

由于A节点和B节点之间无法互通消息，不知道其他节点也在处理该数据需方的其他额度申请请求，则A节点在处理额度申请请求1时，由于数据需方的余额为100，因而允许进行数据配送操作a；同样的，B节点在处理额度申请请求2时，由于数据需方的余额为100，因而允许进行数据配送操作b。但实际上，额度申请请求1和2的累计需求额度已经超出数据需方的余额。

为解决上述技术问题，本发明实施例提供一种处理节点的额度控制方法，所述处理节点处于分布式处理系统中，包括：接收第一额度申请请求，所述第一额度申请请求包括发送方的标识；根据所述发送方的标识判断待执行进程中是否存在关联于所述发送方的第二额度申请请求；当判断结果表明不存在所述第二额度申请请求时，确定所述发送方关联的多个账户的优先级；按照优先级由高到低的顺序依次评估各账户的账户额度，以确定所述第一额度申请请求关联的额度申请成功或失败。

本领域技术人员理解，采用本实施例的方案能够有效避免多进程同一时间对同一个额度数据的竞争现象，解决多进程高并发下的额度竞争问题，且实现额度拆分，使得额度管理更精细化。

本文中出现的“数据交易平台”是指：向用户提供数据交易服务的门户。通过所述数据交易平台，作为数据供方和数据需方的用户可以实现数据交易的商品挂牌、需求发布、数据订购、交易管理、信息查询、清结算等业务，在本实施例所述额度控制应用场景中主要涉及到结算及额度文件推送。

本文中出现的“数据配送系统(Data Deliver System，简称DDS)是指：执行数据配送操作的系统。具体而言，所述DDS可以负责在数据供方或数据需方连接业务系统，进行数据配送。所述DDS一般部署于前置机中，需方DDS能够将想用的数据标识(Identification，简称ID)传输至供方DDS，供方DDS也能将需要提供的数据传输至需方DDS。用户可以通过数据交易平台连接DDS，以进行数据交易。

本文中出现的“额度”是指：用户在数据交易平台中能够使用以进行数据配送的金额。在本实施例中，额度可以包括充值金额和透支额度。其中，充值金额是用户实际充值得到的额度；透支额度是数据交易平台或其他用户基于该用户的信用而提供的信用额度。例如，所述透支额度可以基于供方授信和/或平台授信的方式取得。

本文中出现的“充值”是指：将用户自有账户中的资金转入到数据交易平台账户。

本文中出现的“提现”是指：用户将数据交易平台账户中可用于提现的资金转入到银行卡或数据交易平台中用于数据交易消费的可用余额。

本文中出现的“授信调整”是指：根据业务发展的需要，对数据交易平台或数据供方给予数据需方的信用额度进行增加或减少。其中，数据交易平台可以理解为第三方平台，起到连接数据供方和数据需方的中间桥梁作用，提供所述数据交易平台。

本文中出现的“赠送调整”是指：根据业务发展的需要，对数据交易平台或数据供方给予数据需方的赠送额度进行增加或减少。例如，数据供方或数据交易平台对数据需方有信赖关系，可以给数据需方赠送额度。

本文中出现的“调账”是指：对用户在数据交易平台侧资金账户进行调整，从而使账户金额符合真实的交易情况。

本文中出现的“清算”是指：根据用户一定时间段内的交易消费和支出变动其在银行侧监管账户资金的过程。

本文中出现的“数据需方”是指:数据的需求方。数据需方通过数据交易平台下单，寻能够提供数据的数据供方，以获得想要的数据。

本文中出现的“数据供方”是指:数据的供应方。数据供方可以为数据需方提供数据。

本文中出现的“Redis集”是指：引入的第三方内存数据库集。提供便捷、快速的数据缓存服务，在数据配送系统中用以实现进程通信，缓存数据。

为使本发明的上述目的、特征和有益效果能够更为明显易懂，下面结合附图对本发明的具体实施例做详细的说明。

图1是本发明实施例的一种处理节点的额度控制方法的流程图。本实施例所述方案可以由所述处理节点执行，所述处理节点可以是一个或多个相通信的服务器。

在本实施例中，所述处理节点可以处于分布式处理系统中，所述分布式处理系统可以用于维持额度控制中心(Budget Control Central，简称BCC)，所述额度控制中心用于对数据交易平台中的数据需方和数据供方的额度进行管理和控制。

具体地，在本实施例中，所述处理节点的额度控制方法可以包括如下步骤：

步骤S101，接收第一额度申请请求，所述第一额度申请请求包括发送方的标识；

步骤S102，根据所述发送方的标识判断待执行进程中是否存在关联于所述发送方的第二额度申请请求；

当所述步骤S102的判断结果为否定的，也即，不存在所述第二额度申请请求时，执行步骤S103，确定所述发送方关联的多个账户的优先级；以及步骤S104，按照优先级由高到低的顺序依次评估各账户的账户额度，以确定所述第一额度申请请求关联的额度申请成功或失败。

当所述步骤S102的判断结果为肯定的，也即，存在所述第二额度申请请求时，执行步骤S105，将所述第一额度申请请求添加至所述待执行进程。

更为具体地，所述第一额度申请请求可以来自与所述处理节点对应的发送方。其中，所述对应是指：同一发送方发送的所有额度申请请求均分配至同一处理节点执行。

在一个或多个实施例中，一个处理节点可以对应多个发送方，但是，同一发送方的所有额度申请请求仅会被分配至对应的所述处理节点。

在一个或多个实施例中，所述分布式系统还可以包括至少一个分配节点，所述分配节点可以用于对所述发送方的标识进行哈希(hash)计算以确定所述发送方对应的处理节点，并将所述发送方发送的额度申请请求发送至对应的处理节点。

本申请发明人经过分析发现，在分布式环境下进行额度控制时，现有技术通常采用分布式锁来避免多进程高并发下的额度竞争。但这种方法，在执行效率上并不高效。

因此，本实施例采用nginx作为负载均衡，分配节点对传输的发送方的标识进行哈希计算得到一个数值，这个数值除以整个节点数取余数，该余数即为所述发送方对应的处理节点。由此，可以保证对于同一个发送方，其发送的所有额度申请请求均会被分配到同一个处理节点，从而保证单一服务处理对应的发送方额度请求。其中，所述节点数可以指所述分布式处理系统包括的处理节点的数量。

进一步地，如果其中一个处理节点挂了，由于数据仍然存在于Redis中，新的处理节点也依然可以有效地处理额度请求。

由此，可以在采用nginx实现负载均衡的同时，以执行效率更高的方式确保同一发送方的请求均落到同一处理节点上执行，从而有效解决多进程高并发下的额度竞争问题，避免分布式锁带来的资源消耗。

在一个或多个实施例中，所述待执行进程可以包括所述处理节点的所有未完成任务。

在一个或多个实施例中，所述第二额度申请请求可以是由所述发送方发送的，在所述第一额度申请请求之前到达所述处理节点的额度申请请求。

在一个或多个实施例中，所述第二额度申请请求的数量可以为一个或多个，也即，在所述待执行进行中，在接收到所述第一额度申请请求的时刻之前，可以已经存在多个第二额度申请请求等待执行。

在一个或多个实施例中，当所述步骤S102的判断结果为否定的时，表明所述待执行进程中没有所述发送方关联的额度申请请求尚未处理。同时，由于所述发送方的所有额度申请请求均分配至所述处理节点执行，因而，通过执行所述步骤S102可以简单、直观地确定当前不存在针对所述发送方的额度竞争问题。

在一个或多个实施例中，对于所述发送方关联的多个账户，其中不同账户的账户额度的来源不同。例如，所述账户可以选自：充值金额、供方授信以及平台授信。

进一步地，所述账户额度可以理解为发送方可以消费的费用，不同账户可以预先优先级，所述优先级用于指示扣款顺序。

例如，所述发送方可以预先设置其平台授信关联的账户优先级最高，充值金额关联的账户优先级最低。

在一个或多个实施例中，所述处理节点可以预先存储有发送方针对各账户优先级的设置结果。

在一个或多个实施例中，当所述步骤S102的判断结果为肯定的时，表明所述待执行进程中至少存在一个尚未处理的该发送方发送的额度申请请求，为避免出现额度竞争，所述处理节点执行所述步骤S105，以将所述第一额度申请添加至所述待执行进程中排队等待执行。

在一个或多个实施例中，在所述步骤S105之后，本实施例所述额度控制方法还可以包括：步骤S106，在所述第二额度申请请求执行完毕后，执行所述第一额度申请请求。

当所述第二额度申请请求包含多个所述发送方发送的额度申请请求时，所述步骤S106可以包括：在所述待执行进程中，排在所述第一额度申请请求之前的，所有所述发送方发送的额度申请请求均执行完毕时，执行所述第一额度申请请求。

具体地，所述待执行进程中各额度申请请求可以按照到达所述处理节点的时间先后顺序排序。

在一个或多个实施例中，参考图2，所述步骤S104可以包括如下步骤：

步骤S1041，自优先级最高的账户起，判断所述账户的账户额度是否满足所述第一额度申请请求的申请额度；

当所述步骤S1041的判断结果为肯定的，也即，所述多个账户中任一账户的账户额度满足所述第一额度申请请求的申请额度时，执行步骤S1042，确定所述第一额度申请请求关联的额度申请成功；

当所述步骤S1041的判断结果为否定的，也即，所述多个账户中所有账户的账户额度均无法满足所述第一额度申请请求的申请额度时，执行步骤S1043，确定所述第一额度申请请求关联的额度申请失败。

具体地，所述第一额度申请请求可以以显式或隐式的方式指示所述申请额度。

例如，所述第一额度申请请求可以指示所述申请额度的具体数值，响应于接收到所述第一额度申请请求，所述处理节点可以从中直观提取得到所述发送方本次的申请额度。

又例如，为降低信令开销，所述第一额度申请请求可以指示一编号，所述处理节点可以根据该编号查预设对应表确定发送方本次申请额度的具体数值，其中，所述预设对应表可以记录有多个数值及对应的编号，所述预设对应表可以预先存储于所述处理节点和所述发送方的服务器。

更为具体地，所述处理节点可以存储有所述发送方的各账户的账户额度。

在一个或多个实施例中，如果出现如下情形，则同样可以认为所述步骤S1041的判断结果为肯定的：所述发送方的多个账户的账户额度之和满足所述第一额度申请请求的申请额度。相应的，确定所述第一额度申请请求关联的额度申请成功后，进行额度扣除操作时，可以按照优先级的顺序依次扣除所述多个账户中的账户额度，直至扣除的额度总数等于所述申请额度。

在一个或多个实施例中，所述处理节点可以定期与所述数据交易平台交互，以获取所述发送方的各账户的最新账户额度。

在一个或多个实施例中，在所述步骤S1042之后，所述处理节点可以指示所述DDS进行所述第一额度申请请求指向的数据配送操作。

在一个或多个实施例中，在所述步骤S1043之后，所述处理节点可以指示所述DDS本次额度申请失败，以使DDS不进行所述第一额度申请请求指向的数据配送操作。

由上，采用本实施例的方案，能够以更高效的方式实现分布式处理系统中同一发送方的请求均落到同一处理节点上执行，解决多进程高并发下的额度竞争问题，且实现额度拆分，使得额度管理更精细化。

图3是本发明实施例的一种处理节点的额度控制装置的结构示意图。本领域技术人员理解，本实施例所述处理节点的额度控制装置3(以下简称为额度控制装置3)可以用于实施上述图1和图2所示实施例中所述的方法技术方案。

具体地，所述处理节点可以处于分布式处理系统中。

更为具体地，在本实施例中，所述额度控制装置3可以包括：接收模块31，用于接收第一额度申请请求，所述第一额度申请请求包括发送方的标识；判断模块32，用于根据所述发送方的标识判断待执行进程中是否存在关联于所述发送方的第二额度申请请求；确定模块33，当判断结果表明不存在所述第二额度申请请求时，确定所述发送方关联的多个账户的优先级；评估模块34，用于按照优先级由高到低的顺序依次评估各账户的账户额度，以确定所述第一额度申请请求关联的额度申请成功或失败。

在一个或多个实施例中，所述第一额度申请请求可以来自与所述处理节点对应的发送方。

在一个或多个实施例中，所述分布式系统还可以包括至少一个分配节点，所述分配节点可以用于对所述发送方的标识进行哈希计算以确定所述发送方对应的处理节点，并将所述发送方发送的额度申请请求发送至对应的处理节点。

在一个或多个实施例中，对于所述发送方关联的多个账户，其中不同账户的账户额度的来源可以不同。

在一个或多个实施例中，所述额度控制装置3还可以包括：添加模块35，当判断结果表明存在所述第二额度申请请求时，将所述第一额度申请请求添加至所述待执行进程。

进一步地，所述额度控制装置3还可以包括：执行模块36，用于在所述第二额度申请请求执行完毕后，执行所述第一额度申请请求。

在一个或多个实施例中，所述评估模块34可以包括：判断子模块341，用于自优先级最高的账户起，判断所述账户的账户额度是否满足所述第一额度申请请求的申请额度；第一确定子模块342，当判断结果表明所述多个账户中任一账户的账户额度满足所述第一额度申请请求的申请额度时，确定所述第一额度申请请求关联的额度申请成功；第二确定子模块343，当判断结果表明所述多个账户中没有账户的账户额度满足所述第一额度申请请求的申请额度时，确定所述第一额度申请请求关联的额度申请失败。

关于所述额度控制装置3的工作原理、工作方式的更多内容，可以参照图1和图2中的相关描述，这里不再赘述。

在一个典型的应用场景中，参考图4，作为数据需方，发送方(图未示)可以通过数据交易平台(图未示)向数据配送系统41发送数据配送请求。相应的，所述数据配送系统41可以执行操作s1，以向额度控制中心42发送所述第一额度申请请求。其中，所述第一额度申请请求可以包括所述发送方的标识以及申请额度。

所述数据配送系统41可以包括多台服务器。

搭载有所述额度控制中心42的分布式处理系统可以包括多个分配节点以及多个处理节点，本场景中以所述分布式处理系统分配节点421、分配节点422、处理节点423、处理节点424和处理节点425为例进行具体阐述。

具体而言，假设所述第一额度申请请求发送至分配节点421，所述分配节点421可以通过哈希计算，并将哈希计算的结果除以处理节点的数量以确定所述发送方对应的处理节点。

在本场景中，假设所述发送方对应处理节点424，则所述分配节点421可以执行操作s2，以将所述第一额度申请请求发送至所述处理节点424。

响应于接收到所述第一额度申请请求，所述处理节点424可以判断自身的待执行进程中是否包含所述发送方关联的第二额度申请请求。

当判断结果表明所述待执行进程中包含所述发送方关联的第二额度申请请求时，所述处理节点424可以将所述第一额度申请请求添加至所述待执行进程。

当判断结果表明所述待执行进程中不包含所述发送方关联的第二额度申请请求时，所述处理节点424可以执行所述第一额度申请请求。

具体地，所述处理节点424可以存储有所述发送方关联的多个账户的优先级，以及各账户的账户额度。

进一步地，所述处理节点424可以按照优先级由高到低的顺序依次比较所述账户额度和所述需求额度，当比较结果表明所述发送方的某一账户的账户额度满足所述需求额度时，所述处理节点424向所述数据配送系统41发送反馈信息，以指示本次额度申请成功。

当比较结果表明所述发送方没有一个账户的账户额度能够满足所述需求额度时，所述处理节点424向所述数据配送系统41发送反馈信息，以指示本次额度申请失败。

进一步地，所述处理节点424可以执行操作s3，以将对所述第一额度申请请求的处理结果写入Redis集43中。

进一步地，所述发送方的账户优先级以及账户额度也可以存储于所述Redis集43中，所述处理节点424可以通过访问所述Redis集43以获取所需信息。当所述处理节点424异常时，其他处理节点可以通过访问所述Redis集43的方式获取所需数据，以继续执行所述处理节点424的任务。

在本场景中，当所述发送方又发送一个新的额度申请请求时，即使所述新的额度申请请求被发送至所述分配节点422，通过执行哈希计算以及根据处理节点数量的取余操作，所述新的额度申请请求同样可以被所述分配节点422发送至所述处理节点424。

进一步地，本发明实施例还公开一种存储介质，其上存储有计算机指令，所述计算机指令运行时执行上述图1和图2所示实施例中所述的方法技术方案。优选地，所述存储介质可以包括计算机可读存储介质。所述存储介质可以包括ROM、RAM、磁盘或光盘等。

进一步地，本发明实施例还公开一种终端，包括存储器和处理器，所述存储器上存储有能够在所述处理器上运行的计算机指令，所述处理器运行所述计算机指令时执行上述图1和图2所示实施例中所述的方法技术方案。例如，所述终端可以为处理节点。

虽然本发明披露如上，但本发明并非限定于此。任何本领域技术人员，在不脱离本发明的精神和范围内，均可作各种更动与修改，因此本发明的保护范围应当以权利要求所限定的范围为准。