CN109598603A - 一种开户任务处理方法及开户服务系统 - Google Patents

Abstract

本说明书实施例提供了一种开户任务处理方法，通过将用户终端发送的开户请求转换为异步任务处理，周期性的交由多层任务处理平台进行分发处理。由此，使得开户处理具备了重试的能力，保证了用户体验的同时，通过多层任务处理平台的分发能力，更能够将任务均衡派发到所有应用服务设备上去执行，大大提升系统整体处理的能力。

Description

一种开户任务处理方法及开户服务系统

技术领域

本说明书涉及计算机技术领域，尤其涉及一种开户任务处理方法及开户服务系统。

背景技术

以往，跨境的个人汇款业务，主要是以线下汇款、线下收款为主，效率较低、流程较长、汇款手续费及汇率费用高，用户不方便，体验较差。当前电商平台已经在海外多个国家得到普及，同时国内移动支付业务，例如支付宝业务，在近两年更是推广到国外大量商家。而通过移动支付业务在海外实施跨境汇款时，需要借助MoneyGram分布于30多个国家的分支机构，全球200多个国家与地区拥有的35万个网点实现快速汇款，此业务上要求通过移动支付在银行申请开立二类户，然后通过MoneyGram境外汇入的资金提取到银行二类户中。但是银行受理开户请求后需要对用户身份进行核实，核实通过后再进行开户处理，整个过程耗时比较长，受理开户后到开户成功可能需要5分钟到24小时不等，如果支付页面一直等待会给用户系统崩溃的假象。

发明内容

鉴于上述问题，提出了本说明书以便提供一种克服上述问题或者至少部分地解决上述问题的开户任务处理方法及开户服务系统。

第一方面，本说明书提供一种开户任务处理方法，包括：将接收的开户请求信息保存在本地任务表中；返回所述用户终端开户请求信息已被同步受理的消息通知；周期性地触发异步任务，提取本地任务表中的开户请求信息；将所述开户请求交由多层任务处理平台进行分发处理。

第二方面，本说明书提供一种开户服务系统，包括：通信模块，用于接收用户终端发送的开户请求信息，返回所述用户终端开户请求信息已被同步受理的消息通知，以及将开户结果返回给所述用户终端；本地任务表，用于将所述开户请求信息进行保存；调度中心，用于周期性地触发异步任务，通知多层任务处理平台处理异步任务；多层任务处理平台，用于根据异步任务提取本地任务表中的开户请求信息，对所述开户请求进行分发处理；查询模块，用于查询所述开户请求处理后对应的开户结果。

第三方面，本说明书提供一种服务器，包括处理器和存储器：所述存储器用于存储上述任一项所述方法的程序；所述处理器被配置为用于执行所述存储器中存储的程序实现上述任一项所述方法的步骤。

第四方面，本说明书实施例提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述任一项所述方法的步骤。

本说明书上述一个或多个技术方案，至少具有如下一种或多种技术效果：

在实施本说明书的技术方案中，通过将用户终端发送的开户请求转换为异步任务处理，周期性的交由多层任务处理平台进行分发处理。这样，通过调度中心的调度再来触发异步任务处理从而将同步请求转换成异步任务处理，使得开户具备重试的能力，尤其具备了定时重试的能力，保证了用户体验。

进一步，通过多层任务处理平台的分发能力，能够将任务均衡派发到所有应用服务设备上去执行，大大提升系统整体处理的能力。

再进一步，通过此方法应用于开户服务系统中，由于调度的每次触发的任务数固定，因此使得系统更加具备高并发处理时的泄洪的能力，进而，还可以任何时候都能保证到金融机构(比如银行)的请求数量固定，方便做时间集中的业务推广活动。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本说明书的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1为本说明书的方案的一个应用场景例子的示意图；

图2为本说明书第一实施例中的一种开户任务处理方法的流程图；

图3为本说明书第二实施例中的一种开户服务系统的模块示意图；

图4为本说明书的方案应用到一个具体示例的系统流程图；

图5为本说明书的方案中将异步任务中的参数信息转换为JOSN格式的一个具体示例；

图6为本说明书的方案一个具体异步任务调度示例图；

图7为本说明书第三实施例中的应用一种开户任务处理方法的服务器的示例。

具体实施方式

下面通过附图以及具体实施例对本说明书技术方案做详细的说明，应当理解本说明书实施例以及实施例中的具体特征是对本说明书技术方案的详细的说明，而不是对本说明书技术方案的限定，在不冲突的情况下，本说明书实施例以及实施例中的技术特征可以相互组合。

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

实施例

请参考图1，本说明书的技术方案涉及的一个实施例的应用场景示意图。位于用户侧的用户终端1、2……n，在发起开户请求时，都发送给开户服务系统(系统侧)，通过开户服务系统转换为异步任务，控制任务并发数量，向金融机构发起开户请求业务。用户终端1、2……n的数量可以是海量用户在同一时间段的集中开户请求，可以同步被开户服务系统接收，也可以全时段实时被接收。开户服务系统主要包含调度中心和多层任务处理平台用于处理这些用户终端1、2……n的开户请求，通过异步线程将各个用户终端1、2……n的开户请求保存在本地任务表中。然后根据调度中心配置的时间周期，周期性的触发异步任务以调取本地任务表中保存的开户请求，交由多层任务处理平台逐层分发给平台内的应用服务设备，从而一方面能够将任务均衡派发到平台中所有应用服务设备上去执行，显著提升系统整体处理的能力，另一方面控制了向金融机构发起开户业务的任务数量，缓解金融机构的处理负担。

请参考图2，本说明书第一实施例提供一种开户任务处理方法，该开户任务处理方法包括如下步骤：

S201：接收用户终端发送的开户请求信息。

其中，发起开户请求的用户终端的数量可能是成千上万，甚至亿万级的海量用户，同时用户终端发起开户请求的时间也是无法准确预估的，在一个实施方式中，可以是接收多个用户终端分别发送的开户请求的信息，具体地，其中，可以同时接收、也可以在一个时间段内集中接收大量的开户请求信息，另外，还可以接收同一个用户终端中由于用户误操作、网络延迟或者网络不稳定等因素，重复发起多个开户请求信息。这样的情况自然带来对海量开户请求的同步受理和高并发处理。

此时，可以在用户终端侧通过支付APP设置重发限制，当监测到用户在短时间内发起多次开户请求(如：重复发起多个开户请求)时，限制开户请求信息向外发送，页面提示用户操作过于频繁，暂缓尝试开户。由此也可以减轻金融机构和应用本方法的开户服务系统无必要的请求负担，同时也杜绝了一些不法分子或恶意用户通过流量风暴的方式给系统造成请求拥塞瘫痪或对系统造成破坏。

S202：将所述开户请求信息保存在本地任务表中。

其中，可以先对接收到的开户请求信息进行校验，校验所述开户请求的信息中的交易参数的合法性，将校验通过的开户请求信息保存在本地任务表中。

进一步，所述校验可以包括对开户请求信息的身份校验，如：对用户身份证号、身份证照片、护照号、护照照片、用户本人近照、银行卡号，和/或出生年月等信息进行基本校验核查。具体比如：身份证号位数/规则，护照号位数/规则，出生年月与身份证号匹配度，通过图片识别手段检测身份证照片/护照照片的真伪，用户本人近照是否为人脸正面图片等。从而保证虚假用户开设金融账户导致的系统资金风险，进一步也可防止发给金融机构的虚假开户请求信息泛滥。

再进一步地，所述校验还可以包括安全性校验，如：对开户请求信息进行必要的数据安全检测，以防通过信息中特殊字段或预留扩展字段被篡改，导致携带恶意代码，对系统安全造成极大隐患。

其中，本地任务表仅将校验通过的开户请求信息进行保存。进一步，对未通过校验的开户请求信息予以抛弃，并通知对应的用户终端所述开户请求校验未通过，请用户重新核实开户填写信息是否准确。

另外，可以对于反复校验失败的开户请求信息进行加黑名单处理，提取失败开户请求信息对应的UID和开户填写信息存入黑名单日志信息，同时系统侧下发控制消息，限制该用户终端上支付APP的使用。

进一步地，校验通过的开户请求信息保存在本地任务表之后，返回所述用户终端开户请求已被成功受理的消息通知。由此，用户可以及时获知开户请求是否被成功受理的消息，不会因为金融机构的处理时长不确定导致用户体验下降。

再进一步地，通过异步线程将所述开户请求信息保存到本地任务表中。这样使得大量可能同步发送的海量用户终端的开户请求都转换为异步任务，等待后续触发后再进行处理，从而使得时间点比较集中的开户业务申请有条不紊的周期性按批次处理，保证整个系统任务处理负载均衡稳定，对金融机构比如中国银行的业务负担的影响不至于加重。

S203：周期性地触发异步任务，提取本地任务表中的开户请求信息。

其中，由调度中心负责周期性地触发异步任务，所述异步任务用于处理保存在本地任务表中的开户请求信息，实现开户请求同步受理、异步处理。

进一步地，根据调度中心配置的CRON表达式，周期性的触发所述异步任务。具体比如，调度中心中存有配置文件，基于配置文件中的CRON表达式，按照约定的时间周期来执行异步任务触发消息的发送。所述异步任务触发消息发送到多层任务处理平台，对应本地任务表中的开户请求信息。

再进一步地，由调度中心按照配置文件设置每次周期性发送的异步任务数量。所述异步任务可以对应一条开户请求信息的处理，也可以对应多条开户请求信息的处理。每次发送的异步任务数量也可以设置为一件或特定数量的多件。按照异步任务中的配置要求提取本地任务表中相应数量的开户请求的信息，交由多层任务处理平台进行分发处理。

S204：将提取的所述开户请求信息交由多层任务处理平台进行分发处理。

其中，所述多层任务处理平台至少包括第一层分流单元、第二层分配单元，以及第三层执行单元。进一步，根据业务规模的扩大，业务模式扩展更加多样性等考虑，多层任务处理平台可以扩展到第四、第五或更多层的处理单元，使得多层任务处理平台中的各个应用服务设备处于任务分配均衡，负载稳定的状态。进一步地，所述多层任务处理平台可以为多层结构的应用服务设备集群。

以上述三层为例，所述第一层分流单元按照所述开户请求信息中UID的数值范围将所述开户请求信息进行拆分；将拆分后的开户请求信息按照UID分发到第二层分配单元中多个应用服务设备中。

所述第二层分配单元中的多个应用服务设备按照UID及类型参数，将所述开户请求信息再次拆分；将再次拆分后的开户请求信息按照UID及类型参数分发到第三层执行单元中的多个任务处理器中。

所述第三层执行单元中的多个任务处理器根据不同的类型参数封装不同的报文，通过网关发送给金融机构。

进一步地，所述多个任务处理器接收金融机构返回的受理结果信息。

S205：查询所述开户请求信息处理后对应的开户结果信息。

其中，在开户请求信息处理后，按照一定时间周期向金融机构发起开户结果查询请求，由多个任务处理器封装开户结果查询报文发送给金融机构。等待金融机构返回开户结果信息。

进一步地，将开户结果信息存储在开户数据库中，以备用户终端或者基于业务要求进行调取和查看。

S206：将所述开户结果返回给所述用户终端。

其中，开户结果信息可以主动推送给对应的用户终端，也可以等待用户终端发起开户结果查询请求时，再将所述开户结果返回给用户终端。这样有效避免了系统数据流量负载不均衡的情形。

请参照图3，本说明书第二实施例还提供了一种开户服务系统，包括：

通信模块301，用于接收用户终端发送的开户请求信息，并将开户结果返回给所述用户终端；通信模块301的具体处理例如步骤S201、S206所述。

本地任务表302，用于将所述开户请求信息进行保存；本地任务表302的具体处理例如步骤S202。

调度中心303，用于周期性地触发异步任务，通知多层任务处理平台处理异步任务；调度中心303的具体处理例如步骤S203、S204。

多层任务处理平台304，用于根据异步任务提取本地任务表中的开户请求信息，对所述开户请求信息进行分发处理；多层任务处理平台304的具体处理例如步骤S203、S204。

查询模块305，用于查询所述开户请求处理后对应的开户结果；查询模块305具体处理例如步骤S205。

具体的，在本实施例中，此开户服务系统通常设置在服务器中，也可以设置在服务器集群中，还可以设置在终端设备，如手机、ipad、平板电脑、笔记本电脑等设备，还可以是台式电脑等设备，当然还可以是其它电子设备，在此，本说明书不做限制。开户服务系统进行开户任务处理的方法已在前述第一实施例中进行详细阐述，在此，本实施例不再赘述。

作为一种可选的实施例，所述的开户服务系统，还可以包括：校验单元，用于校验所述开户请求信息中的交易参数的合法性；其中，所述本地任务表，用于仅将校验通过的开户请求信息进行保存。由于发起开户请求的用户终端的数量可能是成千上万，甚至亿万级的海量用户，可能存在大量的用户开户请求信息不合法，交易参数不合规则。

进一步地，所述校验还可以包括对开户请求信息的身份校验，比如对用户身份证号、身份证照片、护照号、护照照片、用户本人近照、银行卡号，和/或出生年月等信息进行基本校验核查，具体比如身份证号位数/规则，护照号位数/规则，出生年月与身份证号匹配度，通过图片识别手段检测身份证照片/护照照片的真伪，用户本人近照是否为人脸正面图片等，从而保证虚假用户开设金融账户导致的系统资金风险，进一步也可防止发给金融机构的虚假开户请求信息泛滥。

再进一步地，所述校验还可以包括安全性校验，对开户请求信息进行必要的数据安全检测，以防通过信息中特殊字段或预留扩展字段被篡改，导致携带恶意代码，对系统安全造成极大隐患。

在此情况下，所述本地任务表仅将校验通过的开户请求信息进行保存。进一步，对未通过校验的开户请求信息予以抛弃，并通知对应的用户终端所述开户请求校验未通过，请用户重新核实开户填写信息是否准确。

另外，可以对于反复校验失败的开户请求信息进行加黑名单处理，提取失败开户请求信息对应的UID和开户填写信息存入黑名单日志信息，同时系统侧下发控制消息，限制该用户终端上支付APP的使用。

作为一种可选的实施例，校验通过的开户请求信息保存在本地任务表之后，所述通信模块301，还用于返回所述用户终端开户请求已被成功受理的消息通知。由此，用户可以及时获知开户请求是否被成功受理的消息，不会因为金融机构的处理时长不确定导致用户体验下降。

所述调度中心303，具体例如负责根据配置的CRON表达式，周期性的触发所述异步任务。其中，所述异步任务用于处理保存在本地任务表中的开户请求的信息。所述调度中心303中存有配置文件，基于配置文件中的CRON表达式，按照约定的时间周期来执行异步任务触发消息的发送。所述异步任务触发消息发送到多层任务处理平台304，对应本地任务表中的开户请求信息。

由调度中心303按照配置文件设置每次周期性发送的异步任务数量，所述异步任务可以对应一条开户请求信息处理，也可以对应多条开户请求信息处理。每次发送的异步任务数量也可以设置为一件或特定数量的多件。按照异步任务中的配置要求提取本地任务表中相应数量的开户请求信息，交由多层任务处理平台304进行分发处理。

所述多层任务处理平台304，还用于通过异步线程将所述开户请求信息保存到本地任务表中。这样使得大量可能同步发送的海量用户终端的开户请求都转换为异步任务，等待后续触发后再进行处理，从而使得时间点比较集中的开户业务申请有条不紊的周期性按批次处理，保证整个系统任务处理负载均衡稳定，对金融机构比如中国银行的业务负担的影响不至于加重。

进一步地，所述多层任务处理平台304，具体例如为多层结构的应用服务设备集群，其至少包括第一层分流单元、第二层分配单元，以及第三层执行单元；所述第一层分流单元、第二层分配单元，以及第三层执行单元各由多个应用服务设备组成。

当然，根据业务规模的扩大，业务模式扩展更加多样性等考虑，多层任务处理平台可以扩展到第四、第五或更多层的处理单元，使得多层任务处理平台中的各个应用服务设备处于任务分配均衡，负载稳定的状态。

以上述三层为例，所述第一层分流单元按照所述开户请求信息中UID的数值范围将所述开户请求进行拆分；将拆分后的开户请求信息按照UID分发到第二层分配单元中多个应用服务设备中。

所述第二层分配单元中的多个应用服务设备按照UID及类型参数，将所述开户请求再次拆分；将再次拆分后的开户请求信息按照UID及类型参数分发到第三层执行单元中的多个任务处理器中。

所述第三层执行单元中的多个任务处理器根据不同的类型参数封装不同的报文，通过网关发送给金融机构。

作为一种可选的实施例，多层任务处理平台304查询所述开户请求处理后对应的开户结果。进一步地，在第三层执行单元中设置多个任务处理器(查询模块305)还负责查询所述开户请求处理后对应的开户结果。

其中，在开户请求处理后，按照一定时间周期向金融机构发起开户结果查询请求，由多个任务处理器封装开户结果查询报文发送给金融机构。等待金融机构返回开户结果信息。

进一步地，将开户结果信息存储在开户数据库中，以备用户终端或者基于业务要求进行调取和查看。

作为一种可选的实施例，所述开户服务系统将所述开户结果返回给所述用户终端。

其中，所述开户服务系统可以将开户结果信息主动推送给对应的用户终端，也可以等待用户终端发起开户结果查询请求时，再将所述开户结果返回给用户终端。这样有效避免了系统数据流量负载不均衡的情形。

再者，所述通信模块301，还用于接收用户终端查询开户结果请求，并将所述开户结果返回给所述用户终端。

图4为本说明书的方案应用到一个具体示例的系统流程图。如图所示，整个流程包含了用户、finsignweb、finauth设备、网关、中国银行(金融机构)，以及任务调度中心之间的交互流程，其中finsignweb是用户终端的支付APP，而finauth设备即为上述实施例二中的开户服务系统中的应用服务设备，主要职责包括：面向机构的签约；面向客户类鉴权、核身及签约请求中与机构能力相关的流程服务编排，包括：机构四要素鉴权、三要素鉴权、机构多证件校验能力、机构短信校验、机构免签等能力编排撮合等。所述开户服务系统由三层分发机制的finauth设备集群构成。

此实施例的系统流程开始，用户首先通过终端上的finsignweb填写银行卡信息、身份信息等申请开户的请求信息，之后通过finsignweb将申请开户的请求信息发送给三层分发机制的finauth应用服务设备集群的开户服务系统；由所述finauth集群开户服务系统校验信息合法性，将校验通过的开户请求信息通过异步线程保存开户请求信息到本地任务表中，返回用户终端受理结果，即向finsighweb返回所述开户请求信息被同步成功受理的通知消息，finsignweb进而通知用户受理结果。由任务调度中心定时触发异步任务通知所述finauth集群开户服务系统，系统接收到定时触发异步任务后交由多层任务处理平台处理异步开户任务，调用三层分发机制处理异步任务，对于申请开户请求封装成开户报文通过网关发送到中国银行，中国银行会反馈受理结果，通过网关返回给finauth集群开户服务系统。进一步地，finauth集群开户服务系统在收到银行反馈的受理结果后，再发起开户结果查询请求，通过网关发送开户结果报文向中国银行查询，中国银行查询到开户结果后通过网关返回开户结果给finauth集群开户服务系统并本地保存。当用户需要查询开户结果，通过finsignweb发送查询开户结果请求给finauth集群开户服务系统，系统将之前保存的开户结果返回给finsignweb以通知用户。

进一步地，开户服务系统在收到开户请求时会将开户请求信息通过异步线程将其转换为异步任务，异步任务包含了任务类型，业务ID，业务类型，任务状态，任务优先级，触发时间，重试次数，结束时间等参数信息，同时将异步任务中的参数信息转换为JOSN格式存储到扩展信息中(如图5所示)，因此这个任务调度模型就可以抽象为通用的异步任务，而不需要去关心具体的业务含义，当调度中心触发了三层任务的处理时，捞取的任务会按照任务类型找到合适的任务处理器来处理业务，在银行二类户的项目中已经有了开户申请，开户查询的任务。未来还可以根据业务的需要扩展出更多的其他异步任务处理器，任务处理器之间相互隔离，新增的业务也不会对原有业务造成影响。使得异步任务具备很好的扩展能力。

图6所示，为本说明书的方案一个具体异步任务调度示例图。调度中心根据配置的CRON表达式，周期性的发送消息到消息中心，消息中心将消息投递到finauth应用服务设备集群，在第一层的任务拆分中根据当前应用部署单元的UID处理范围对开户请求信息进行拆分，拆分的开户请求信息通过远程方法调用派发到本应用部署单元的其他finauth应用服务设备上。设置所述集群中的部分设备只为一定范围内的用户终端进行服务，例如：用户终端UID＝2088000001到2088000991，按照UID倒数二三两位，可以拆分为100份，每台设备可以处理的用户的范围就是通过一个单元配置中心来控制的，假如当前finauth应用服务设备A的处理范围是00-19，那么满足条件的就是指用户UID倒数二三两位是满足00-19区间的。

在第二层中再根据UID和状态信息从本地任务表中提取满足条件的任务，然后将任务再次通过远程方法调用随机派发到第三层的任务处理器中，任务处理器根据不同的任务类型来进行不同的报文组装，通过网关发送开户或者开户结果查询的任务到金融机构。具体比如：第二层也有很多设备分别处理不同UID的信息，以其中一台设备为例：处理UID倒数二，三位为00的用户提交的开户申请任务，并且任务的状态为初始化或者重试(对于超时，失败和成功的状态无需再次处理)，同时任务的触发时间到达了当前时间的才需要处理，例如：一个任务触发时间是明天12：00，那么今天不管周期调度多少次都不会执行此任务。转换为查询SQL就是select*from fa_task_00(存储UID倒数二，三位为00的用户提交的开户任务表)where

UID倒数二，三位＝‘00’

And taskStatus in(‘INIT’，’RETRY’)--状态为初始化和重试的

And gmt_fire＜＝now()--触发时间要小于或者等于系统当前时间。

通过三层任务的分发将可以处理的任务均衡的分配到finauth应用服务设备集群的每一台设备中，大大提升了系统的处理能力。

对于反馈受理结果中明确校验失败的，系统会将任务状态设置为FAIL，对于需要重试的将任务状态设置为RETRY，处理成功的则设置为SUCCESS，对于RETRY的任务会在下次调度时再次发起请求，直到超过了重试的次数如果还不成功则设置为TIMEOUT。

对于开户受理成功的任务，系统会在接下来的任务调度中执行开户结果查询的请求，获取到明确的开户结果后更新任务状态，并且将开户结果信息回写到业务表中，具体地，可以存储到一个数据库的一个表中，该表作为业务表，可以用于存储用户到银行机构申请开户结果信息，例如：开户成功后存储账号。

本说明书第三实施例还提供了一种服务器，包括存储器702、处理器701及存储在存储器702上并可在处理器701上运行的计算机程序，所述处理器701执行所述程序时实现前文所述方法的步骤。为了便于说明，仅示出了与本说明书实施例相关的部分，具体技术细节未揭示的，请参照本说明书实施例方法部分。该服务器，可以是包括各种电子设备形成的服务器设备，PC电脑、网络云服务器，甚至手机、平板电脑、PDA(Personal DigitalAssistant，个人数字助理)、POS(Point of Sales，销售终端)、车载电脑、台式电脑等任意电子设备上设置的服务器功能。

具体地，图7示出的与本说明书实施例提供的技术方案相关的服务器组成结构框图，总线700可以包括任意数量的互联的总线和桥，其将包括由处理器701代表的一个或多个处理器和存储器702代表的存储器的各种电路链接在一起。总线700还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口703在总线700和接收器和/或发送器704之间提供接口，接收器和/或发送器704可以是分开独立的接收器或发送器也可以是同一个元件如收发机，提供用于在传输介质上与各种其他装置通信的单元。处理器701负责管理总线700和通常的处理，而存储器702可以被用于存储处理器701在执行操作时所使用的数据。

基于这样的理解，本说明书实现上述第一实施例的方法中的全部或部分流程，也可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

尽管已描述了本说明书的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本说明书范围的所有变更和修改。

显然，本领域的技术人员可以对本说明书进行各种改动和变型而不脱离本说明书的精神和范围。这样，倘若本说明书的这些修改和变型属于本说明书权利要求及其等同技术的范围之内，则本说明书也意图包含这些改动和变型在内。

Claims (21)

1.一种开户任务处理方法，包括：

接收用户终端发送的开户请求信息；

将所述开户请求信息保存在本地任务表中；

返回所述用户终端开户请求已被同步受理的消息通知；

周期性地触发异步任务，以提取本地任务表中的开户请求信息；

将所述开户请求信息交由多层任务处理平台进行分发处理；

将所述开户请求信息处理后对应的开户结果信息返回给所述用户终端。

2.如权利要求1所述的方法，所述将所述开户请求信息保存在本地任务表中，包括：

校验所述开户请求信息中的参数的合法性，以将校验通过的开户请求信息保存在本地任务表中。

3.如权利要求2所述的方法，所述返回所述用户终端开户请求已被同步受理的消息通知，还包括：

返回所述用户终端开户请求已被同步成功受理的消息通知。

4.如权利要求1所述的方法，所述将所述开户请求信息保存在本地任务表中，包括：

通过异步线程将所述开户请求信息保存到本地任务表中。

5.如权利要求1所述的方法，所述多层任务处理平台至少包括：第一层分流单元、第二层分配单元，以及第三层执行单元。

6.如权利要求5所述的方法，将所述开户请求信息交由多层任务处理平台进行分发处理，包括：

所述多层任务处理平台至少包括第一层分流单元、第二层分配单元，以及第三层执行单元；

所述多层任务处理平台的第一层分流单元按照所述开户请求信息中UID的数值范围将所述开户请求进行拆分；

将拆分后的开户请求信息按照UID分发到第二层分配单元中多个应用服务设备中；

所述第二层分配单元中的多个应用服务设备按照UID及类型参数，将所述开户请求再次拆分；

将再次拆分后的开户请求信息按照UID及类型参数分发到第三层执行单元中的多个任务处理器中。

7.如权利要求6所述的方法，包括：所述多个任务处理器根据不同的类型参数封装不同的报文，通过网关发送给金融机构。

8.如权利要求1所述的方法，包括：所述多层任务处理平台为应用服务设备集群。

9.如权利要求1所述的方法，周期性地触发异步任务，提取本地任务表中的开户请求信息，包括：

根据调度中心配置的CRON表达式，周期性的触发所述异步任务。

10.如权利要求1所述的方法，所述将所述开户请求信息处理后对应的开户结果信息返回给所述用户终端，包括：

当接收到用户终端对开户结果信息的查询请求后，将所述开户结果信息返回给所述用户终端。

11.一种开户服务系统，包括：

通信模块，用于接收用户终端发送的开户请求信息，返回所述用户终端开户请求已被同步受理的消息通知，以及将开户结果信息返回给所述用户终端；

本地任务表，用于将所述开户请求信息进行保存；

调度中心，用于周期性地触发异步任务，以通知多层任务处理平台处理异步任务；

多层任务处理平台，用于根据所述异步任务提取本地任务表中的开户请求信息，对所述开户请求进行分发处理；

查询模块，用于查询所述开户请求信息处理后对应的开户结果信息。

12.如权利要求11所述的开户服务系统，还包括：

校验单元，用于校验所述开户请求信息中的参数的合法性；

所述本地任务表，用于仅将校验通过的开户请求信息进行保存。

13.如权利要求12所述的开户服务系统，所述通信模块，还包括：用于返回所述用户终端开户请求已被同步成功受理的消息通知。

14.如权利要求11所述的开户服务系统，所述多层任务处理平台，还包括：用于通过异步线程将所述开户请求信息保存到本地任务表中。

15.如权利要求11所述的开户服务系统，所述多层任务处理平台为应用服务设备集群，其至少包括：第一层分流单元、第二层分配单元，以及第三层执行单元；所述第一层分流单元、第二层分配单元以及第三层执行单元，各由多个应用服务设备组成。

16.如权利要求15所述的开户服务系统，还包括：

所述第一层分流单元，用于按照所述开户请求信息中UID的数值范围将所述开户请求进行拆分，并将拆分后的开户请求信息按照UID分发到第二层分配单元中的多个应用服务设备中；

所述第二层分配单元中的多个应用服务设备，用于按照UID及类型参数，将所述开户请求再次拆分，并将再次拆分后的开户请求信息按照UID及类型参数分发到第三层执行单元中的多个任务处理器中。

17.如权利要求16所述的开户服务系统，所述第三层执行单元中的多个任务处理器，包括：

用于根据不同的类型参数封装不同的报文，并通过网关发送给金融机构。

18.如权利要求11所述的开户服务系统，所述调度中心，还包括：用于根据配置的CRON表达式，周期性的触发所述异步任务。

19.如权利要求11所述的开户服务系统，所述通信模块，还包括：用于接收用户终端对开户结果信息的查询请求，并将所述开户结果信息返回给所述用户终端。

20.一种服务器，包括处理器和存储器：

所述存储器用于存储执行权利要求1至10任一项所述方法的程序；

所述处理器被配置为用于执行所述存储器中存储的程序。

21.一种计算机可读存储介质，其存储有计算机程序，其特征在于，该程序被处理器执行时实现权利要求1至10任一项所述方法的步骤。