一种任务处理方法、应用服务器及系统与流程

本说明书实施例涉及互联网技术领域，尤其涉及一种任务处理方法、应用服务器及系统。

背景技术：

随着互联网的快速发展，促进了互联网业务系统的不断改进和发展，为人们的生活带来极大的便利。但是随着业务的增多，在开发环境中，为了验证各自的业务，线下部署了多种不同代码逻辑的服务器，各服务器部署的代码可能不一致。许多任务在进行任务处理的过程中很容易被调度到了其他业务的服务器上，被分配的服务器没有处理分配到的任务的代码逻辑，导致任务处理失败。

技术实现要素：

本说明书实施例提供及一种任务处理方法、应用服务器及系统。

第一方面，本说明书实施例提供一种任务处理方法，应用于任务处理系统中，所述任务处理系统包括任务处理装置和多个应用服务器，所述任务处理方法包括：

所述任务处理装置获取待处理任务的任务信息，并基于所述任务信息中的用户标识，将所述任务信息分发至与所述用户标识对应的第一应用服务器，其中，所述第一应用服务器属于所述多个应用服务器，所述任务信息中包含创建所述待处理任务的第二应用服务器的服务器标识以及所述待处理任务对应的用户标识，所述第二应用服务器中设置有用于处理所述待处理任务的处理模块；

所述第一应用服务器接收所述任务信息，基于所述任务信息生成待处理任务列表，并将所述待处理任务列表广播至所述多个应用服务器，所述待处理任务列表中携带有所述服务器标识；

所述多个应用服务器中的每个应用服务器接收所述待处理任务列表，并在确认所述待处理任务列表中的所述服务器标识与自身服务器标识一致后，对所述待处理任务进行处理。

第二方面，本说明书实施例提供一种任务处理系统，包括任务处理装置和多个应用服务器，其中：

所述任务处理装置用于获取待处理任务的任务信息，并基于所述任务信息中的用户标识，将所述任务信息分发至与所述用户标识对应的第一应用服务器，其中，所述第一应用服务器属于所述多个应用服务器，所述任务信息中包含创建所述待处理任务的第二应用服务器的服务器标识以及所述待处理任务对应的用户标识，所述第二应用服务器中设置有用于处理所述待处理任务的处理模块；

所述第一应用服务器接收所述任务信息，基于所述任务信息生成待处理任务列表，并将所述待处理任务列表广播至所述多个应用服务器，所述待处理任务列表中携带有所述服务器标识；

所述多个应用服务器中的每个应用服务器接收所述待处理任务列表，并在确认所述待处理任务列表中的所述服务器标识与自身服务器标识一致后，对所述待处理任务进行处理。

第三方面，本说明书实施例提供一种应用于应用服务器，所述方法包括：

创建目标待处理任务，将所述应用服务器的服务器标识添加至所述目标待处理任务的任务信息中；

接收待处理任务列表，所述待处理任务列表中存储有每个待处理任务的任务信息；

遍历所述待处理任务列表中每个待处理任务的任务信息，确定任务信息中服务器标识与所述应用服务器的服务器标识一致的所述目标待处理任务；

对所述目标待处理任务进行处理。

第四方面，本说明书实施例提供一种应用服务器，包括：

创建单元，用于创建目标待处理任务，将所述应用服务器的服务器标识添加至所述目标待处理任务的任务信息中；

接收单元，用于接收待处理任务列表，所述待处理任务列表中存储有每个待处理任务的任务信息；

确定单元，用于遍历所述待处理任务列表中每个待处理任务的任务信息，确定任务信息中服务器标识与所述应用服务器的服务器标识一致的所述目标待处理任务；

处理单元，用于对所述目标待处理任务进行处理。

第五方面，本说明书实施例提供一种应用服务器，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述第三方面任务处理方法的步骤。

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

本说明书实施例有益效果如下：

在本说明书实施例提供的应用于任务处理系统的任务处理方法，由于应用服务器在任务创建时，对应的任务信息中包括创建该任务的服务器标识，记录该任务由哪台服务器创建，进而，在进行任务处理时，任务处理装置获取待处理任务的任务信息，并基于任务信息中的用户标识，将任务信息分发至与用户标识对应的第一应用服务器，其中，第一应用服务器属于多个应用服务器，任务信息中包含创建待处理任务的第二应用服务器的服务器标识以及待处理任务对应的用户标识，第二应用服务器中设置有用于处理待处理任务的处理模块，进而，第一应用服务器接收任务信息，基于任务信息生成待处理任务列表，并将待处理任务列表广播至多个应用服务器，待处理任务列表中携带有服务器标识，最后，多个应用服务器中的每个应用服务器接收待处理任务列表，并在确认待处理任务列表中的服务器标识与自身服务器标识一致后，对待处理任务进行处理。这样，就可以将需要处理的任务列表广播到所有应用服务器，接受到任务列表的应用服务器只处理自己创建的任务，丢弃其他任务，从而保证逻辑的一致性，确保任务处理的成功率。

附图说明

图1为本说明书实施例第一方面提供的任务处理系统示意图；

图2为本说明书实施例第一方面提供的任务处理系统应用于开户场景示意图；

图3为本说明书实施例第一方面提供的任务处理系统中现有分发方式示意图；

图4为本说明书实施例第一方面提供的任务处理系统中任务处理方式示意图；

图5为本说明书实施例第一方面提供的任务处理系统应用到具体示例的系统流程图；

图6为本说明书实施例第一方面提供的任务处理系统中将异步任务中的参数信息转换为josn格式的一个具体示例；

图7为本说明书实施例第一方面提供的任务处理系统中具体异步任务调度示例图；

图8为本说明书实施例第二方面提供的应用于任务处理系统的任务处理方法流程图；

图9为本说明书实施例第三方面提供的应用于应用服务器的任务处理方法流程图；

图10为本说明书实施例第四方面提供的应用服务器结构示意图；

图11为本说明书实施例第五方面提供的应用服务器结构示意图。

具体实施方式

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

第一方面，本说明书实施例提供一种任务处理系统，请参考图1，包括任务处理装置101和多个应用服务器102，其中：

任务处理装置101用于获取待处理任务的任务信息，并基于任务信息中的用户标识，将任务信息分发至与用户标识对应的第一应用服务器，其中，第一应用服务器属于多个应用服务器，任务信息中包含创建待处理任务的第二应用服务器的服务器标识以及待处理任务对应的用户标识，第二应用服务器中设置有用于处理待处理任务的处理模块；

第一应用服务器接收任务信息，基于任务信息生成待处理任务列表，并将待处理任务列表广播至多个应用服务器，待处理任务列表中携带有服务器标识；

多个应用服务器中的每个应用服务器接收待处理任务列表，并在确认待处理任务列表中的服务器标识与自身服务器标识一致后，对待处理任务进行处理。

其中，任务处理系统还包括调度中心103，调度中心103用于周期性地触发异步任务，通知任务处理装置101处理预设任务列表中的待处理任务，以使得任务处理装置101从预设任务列表中获取待处理任务的任务信息。

任务处理系统还包括通信装置，通信装置用于在任务处理装置获取待处理任务的任务信息之前，接收用户终端发送的业务请求，并通知与业务请求对应的第二应用服务器创建与业务请求对应的待处理任务。

其中，第二应用服务器在接收到通信装置的通知后，创建与业务请求对应的待处理任务，添加服务器标识至待处理任务的任务信息中。

具体的，在本实施例中，首先通过通信装置接收用户终端发送的业务请求，并通知对应的第二应用服务器创建与业务请求对应的待处理任务，具体的，用户终端发送一些业务请求，系统将其分配至对应的第二应用服务器，第二应用服务器针对用户的业务请求创建待处理任务，为了解决各应用服务器代码逻辑不一致导致任务处理失败的问题，在第二应用服务器创建业务请求对应的待处理任务时，第二服务器具备处理该待处理任务的处理模块(代码逻辑)，将自己的服务器标识添加至待处理任务的任务信息中，并将待处理任务与任务信息存储至预设任务表中。

然后，调度中心103周期性地触发异步任务，通知任务处理装置103处理预设任务表中预设条数的待处理任务。比如：每次调度1000条待处理任务。通知任务处理装置103处理预设任务表中指定的预设条数的待处理任务。

进而，任务处理装置103，在接收调度中心103发送的待处理任务的任务信息后，进行任务的三层分发。首先，进行第一层分发，基于任务信息中的用户标识，将任务信息分发至与该用户标识对应的第一应用服务器。然后，进行第二层分发，第一应用服务器基于分配到的任务信息，按预设策略读取对应的待处理任务，生成待处理任务列表，将待处理任务列表广播至所有应用服务器。最后，进行第三层分发，系统中每个应用服务器处理待处理任务列表中与自身服务器标识一致的待处理任务，丢弃与自身服务器标识不一致的待处理任务。这样，就可以将需要处理的任务列表广播到所有应用服务器，接受到任务列表的应用服务器只处理自己创建的任务，丢弃其他任务，从而保证逻辑的一致性，确保任务处理的成功率。

本实施例中的任务处理系统可以是一个开户服务系统，待处理任务为开户任务，具体的，本实施例主要以开户场景对本实施例中的任务处理系统的任务处理过程进行详细描述。

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

首先，通信装置接收用户终端发送的开户请求信息。

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

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

然后，将开户请求分配至对应的第二应用服务器，第二应用服务器针对开户请求创建开户任务，将自己的服务器标识添加至该开户任务的任务信息中，将开户任务保存在预设任务表中。

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

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

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

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

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

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

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

然后，调度中心103周期性地触发异步任务，提取预设任务表中的开户任务。

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

进一步地，根据调度中心103配置的cron表达式，周期性的触发异步任务。具体比如，调度中心103中存有配置文件，基于配置文件中的cron表达式，按照约定的时间周期来执行异步任务触发消息的发送。异步任务触发消息发送到任务处理装置103，对应预设任务表中的开户任务。

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

其中，任务处理装置103包括接收单元、第一分单元、第二分发单元、第三分发单元。进一步，根据业务规模的扩大，业务模式扩展更加多样性等考虑，任务处理装置103可以扩展到第四、第五或更多层的处理单元，使得任务处理装置103中的各个应用服务器处于任务分配均衡，负载稳定的状态。进一步地，任务处理装置103可以为多层结构的应用服务器集群。

以上述三层分发单元为例，第一层是任务处理装置101把调度中心103指示的100个开户任务按用户标识进行拆分。具体的，按照开户任务信息中uid的数值范围将开户请求信息进行拆分，将拆分后的开户请求信息按照uid分发到多个应用服务器中。

比如：用户的开户数据按照用户标识uid的维度，倒数二，三位分别存储到100个数据库的100个表中。假设系统提供finauth_rz_00～finauth_rz_99总共100个数据库，对应有fa_task_00～fa_task_99总共100个任务表。如果当前用户的用户标识208800000190，由于倒数二三位是19，所以该用户对应的开户任务的相关数据存储到finauth_rz_19数据库的fa_task_19表中。调度中心103调度的100个开户任务对应的用户标识uid＝2088000001到2088000991，按照uid倒数二三两位，可以拆分为100份。

具体的，可以根据数值匹配方式将开户任务的开户任务信息分配至指定的第一应用服务器。每台应用服务器可以处理的用户的范围就是通过一个单元配置中心来控制的，假如应用服务器a的处理范围是00，那么用户标识uid倒数二三两位是00的开户任务信息分配给服务器a。

当然，还可以采用随机分发方式。比如：包括200个应用服务器，随机选择100个第一应用服务器，为每个第一应用服务器随机分配一个00-99的数字，接收到该数字的第一应用服务器可处理匹配的用户标识对应的开户任务。如果应用服务器b分配到数字01，表示应用服务器b可从finauth_rz_01数据库的fa_task_01表中读取到用户标识为uid＝2088000011的开户任务数据，进行任务处理。

然后进行第二层分发。每个第一应用服务器就分配到的开户任务信息，读取到用户标识，根据用户标识的倒数二三两位确定出进行任务捞取的数据库，假设开户任务信息的用户标识的倒数二三两位为03，该应用服务器可从finauth_rz_03数据库的fa_task_03表中进行开户任务捞取，可每次读取预设数量(如：5个、10个等)的开户任务。针对读取到的开户任务，生成开户任务列表，将其广播至全网所有的应用服务器。在具体实施过程中，预设数量可根据实际需要进行设定，在此，本申请不做限制。

在进行广播之前，第一应用服务器需要判断当前环境，如果当前环境为线下开发环境，由于在线下开发环境中，开发人员可根据也根据业务需求部署应用服务器，各个应用服务器的处理功能并不对等。如示意图3所示，假如三个业务分支代码分别部署在a、b、c三台应用服务器，分别在a、b、c三台服务器上创建了任务id为1的a银行二类户开户，任务id为2的a银行二类户查询，任务id为3的b银行二类户开户任务，三层任务派发时将捞取的任务随机分配，如果把任务id2分配到应用服务器c，任务id3分配到应用服务器a，由于a银行和b银行的开户逻辑不一致，因此应用服务器a和应用服务器c的处理器也是不同的，这样会导致接受到任务的应用服务器a与应用服务器c没有合适的处理器来处理任务，由于创建任务的应用服务器是部署了处理该任务的处理程序。因此，在线下开发环境中，才需要将任务分配给创建该任务的应用服务器。在本实施例中，可采用分布式的广播方式，将任务列表发送至多个主节点，再由各个主节点将其广播至多个应用服务器。如果当前环境为线下开发环境，第一应用服务器将读取到的开户任务对应的任务列表发送至全网所有的应用服务器。

最后，进行第三层分发，如果在线下开发环境，每个应用服务器在接收到该任务列表后，循环遍历该任务列表中每一个任务，判断任务是否由自己创建，即如果待处理任务列表中待处理任务的任务信息中的服务器标识与自身服务器标识一致，表明该任务是由自身创建，获取该任务对应的任务数据进行处理。如果任务不是由自身创建则丢弃，通过这种广播方式实现各种创建的任务各自处理。

针对前述图3中的示例，在采用了本实施例中的系统后，请参看图4，在原来任务模型的基础上增加了host字段，用于记录服务器标识，该字段记录当前任务由哪台服务器创建，之前的三条任务会打包成为任务列表发送到主节点应用服务器，然后主节点应用服务器会实现对应范围内应用服务器的广播，使得每一台应用服务器都可以获取到全量的1、2、3三条任务，各个服务器判断任务的host是否和当前服务器的host一致，如果一致则处理，不一致则丢弃，从而实现了由创建任务的服务器来执行任务。解决了不同服务器代码流不一致，接受到的任务处理不了或者处理逻辑不正确的问题。

如果当前环境不是线下开发环境，可将读取到的任务再次通过远程方法调用随机派发到应用服务器中，应用服务器根据不同的任务类型来进行不同的报文组装，通过网关发送开户或者开户结果查询的任务到金融机构服务器。

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

图5为本应用到一个具体示例的系统流程图。如图所示，finsignweb是用户终端的支付app，finauth即为上述实施例二中的开户服务系统中的应用服务器，主要职责包括：面向机构的签约；面向客户类鉴权、核身及签约请求中与机构能力相关的流程服务编排，包括：机构四要素鉴权、三要素鉴权、机构多证件校验能力、机构短信校验、机构免签等能力编排撮合等。开户服务系统由三层分发机制的finauth设备集群构成。用户首先通过finsignweb将填写银行卡信息、身份信息等申请开户的请求信息发送给三层分发机制的finauth应用服务器集群的开户服务系统。由系统校验信息合法性，校验通过的开户请求信息通过异步线程保存开户请求信息到预设任务表中。系统中调度中心103定时触发异步任务，由任务处理装置103处理异步开户任务，调用三层分发机制处理异步任务，对于开户请求封装成报文通过网关发送到银行，银行会反馈受理结果。

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

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

在第二层分发中，接收到任务处理装置发送的开户请求信息的finauth应用服务器，根据开户请求信息中的uid和状态信息从对应的数据库中提取满足条件的任务，生成任务列表，任务列表广播至各个应用服务器。

在第三层分发中，每个应用服务器再根据从该任务列表中提取到自己创建的任务进行处理。具体的，应用服务器根据对任务进行报文组装，通过网关发送开户或者开户结果查询的任务到金融机构服务器。

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

通过本实施例中的系统，在进行三层任务分发时，可以将需要处理的任务列表广播到所有应用服务器，接受到任务列表的应用服务器只处理自己创建的任务，丢弃其他任务，从而保证逻辑的一致性，确保任务处理的成功率。

第二方面，基于同一发明构思，本说明书实施例提供一种任务处理方法，应用于任务处理系统中，所述任务处理系统包括任务处理装置和多个应用服务器，请参考图8，所述任务处理方法包括如下步骤：

s801：所述任务处理装置获取待处理任务的任务信息，并基于所述任务信息中的用户标识，将所述任务信息分发至与所述用户标识对应的第一应用服务器，其中，所述第一应用服务器属于所述多个应用服务器，所述任务信息中包含创建所述待处理任务的第二应用服务器的服务器标识以及所述待处理任务对应的用户标识，所述第二应用服务器中设置有用于处理所述待处理任务的处理模块；

s802：所述第一应用服务器接收所述任务信息，基于所述任务信息生成待处理任务列表，并将所述待处理任务列表广播至所述多个应用服务器，所述待处理任务列表中携带有所述服务器标识；

s803：所述多个应用服务器中的每个应用服务器接收所述待处理任务列表，并在确认所述待处理任务列表中的所述服务器标识与自身服务器标识一致后，对所述待处理任务进行处理。

在一种可选方式中，所述任务处理系统还包括调度中心，所述方法还包括：

所述调度中心周期性地触发异步任务，通知所述任务处理装置处理预设任务列表中的待处理任务，以使得所述任务处理装置从所述预设任务列表中获取待处理任务的任务信息。

在一种可选方式中，所述任务处理系统还包括通信装置，在所述任务处理装置获取待处理任务的任务信息之前，所述方法还包括：

所述通信装置接收用户终端发送的业务请求，并通知与所述业务请求对应的所述第二应用服务器创建与所述业务请求对应的待处理任务；

所述第二应用服务器创建与所述业务请求对应的待处理任务，添加所述服务器标识至所述待处理任务的任务信息中。

在一种可选方式中，所述调度中心周期性地触发异步任务，包括：所述调度中心根据配置的cron表达式，周期性的触发所述异步任务。

在一种可选方式中，所述任务处理装置基于所述任务信息中的用户标识，将所述任务信息分发至与所述用户标识对应的第一应用服务器，包括：

所述任务处理装置按照所述用户标识的数值范围将所述任务信息进行拆分，将拆分后的任务信息分发至对应的第一应用服务器中。

在一种可选方式中，所述第一应用服务器接收所述任务信息，基于所述任务信息生成待处理任务列表，包括：

所述第一应用服务器从所述任务信息指示的数据库中读取所述待处理任务，基于读取到的待处理任务，生成待处理任务列表。

在一种可选方式中，所述第一应用服务器将所述待处理任务列表广播至所述多个应用服务器，包括：

所述第一应用服务器确定当前环境，判断所述当前环境是否为线下开发环境，如果是，将所述待处理任务列表广播至所述多个应用服务器。

在一种可选方式中，所述第一应用服务器在所述判断所述当前环境是否为线下开发环境之后，所述方法还包括：

所述第一应用服务器确定所述当前环境不是线下开发环境情况下，将读取到的待处理任务随机分发到所述多个应用服务器。

在一种可选方式中，所述待处理任务为开户任务。

本实施例中的任务处理的详细过程已在前述第一方面实施例中详细阐述，具体可参照第一方面实施例中对应的内容，在此，本申请不做赘述。

第二方面，基于同一发明构思，本说明书实施例提供一种任务处理方法，请参考图8，包括如下步骤：

s801：接收调度中心发送的待处理任务的任务信息，每个任务信息中包括创建对应待处理任务的服务器标识；

s802：基于每个任务信息中的用户标识，将所述任务信息分发至多个应用服务器；

s803：控制所述多个应用服务器中每个应用服务器基于分配到的任务信息，按第二预设策略读取对应的待处理任务，生成待处理任务列表，将所述待处理任务列表广播至所有应用服务器；

s804：控制每个所述应用服务器处理所述待处理任务列表中与自身服务器标识一致的待处理任务。

在一种可选方式中，所述基于每个任务信息中的用户标识，将所述任务信息分发至多个应用服务器，包括：

按照所述用户标识的数值范围将所述任务信息进行拆分；

将拆分后的任务信息分发至对应的应用服务器中。

在一种可选方式中，所述控制所述多个应用服务器中每个应用服务器基于分配到的任务信息，按第二预设策略读取对应的待处理任务，包括：

控制所述多个应用服务器中每个应用服务器从分配到的任务信息指示的数据库中读取预设数量的待处理任务。

在一种可选方式中，所述将所述待处理任务列表广播至所有应用服务器，包括：

确定当前环境；

判断所述当前环境是否为线下开发环境；

如果是，将所述待处理任务列表广播至所有应用服务器。

在一种可选方式中，在所述判断所述当前环境是否为线下开发环境之后，所述方法还包括：

如果所述当前环境不是线下开发环境，所述多个应用服务器中每个应用服务器将读取到的待处理任务随机分发到多个应用服务器。

在一种可选方式中，所述待处理任务为开户任务，所述开户任务存储在预设任务表中，所述调度中心周期性地触发异步任务，提取所述预设任务表中的开户任务中的任务信息。

本实施例中的任务处理的详细过程已在前述第一方面实施例中详细阐述，具体可参照第一方面实施例中对应的内容，在此，本申请不做赘述。

第三方面，基于同一发明构思，本说明书实施例提供一种任务处理方法，应用于应用服务器，请参考图9，包括如下步骤：

s901：创建目标待处理任务，将所述应用服务器的服务器标识添加至所述目标待处理任务的任务信息中；

s902：接收待处理任务列表，所述待处理任务列表中存储有每个待处理任务的任务信息；

s903：遍历所述待处理任务列表中每个待处理任务的任务信息，确定任务信息中服务器标识与所述应用服务器的服务器标识一致的所述目标待处理任务；

s904：对所述目标待处理任务进行处理。

具体的，如前述第一实施例所述的内容，应用服务器需要在接收到指派的业务请求时，创建目标待处理任务后，将该应用服务器的服务器标识添加至所述目标待处理任务的任务信息中，表明该目标待处理任务为自己创建。该目标待处理任务会被分发到一个第一应用服务器进行任务捞取，当该第一应用服务器捞取到的任务包括该目标待处理任务后，生成一个待处理任务列表，该待处理任务列表中携带了该目标待处理任务的任务信息，该任务信息中就包含了创建该目标待处理任务的应用服务器的服务器标识，第一应用服务器会将待处理任务列表广播至所有的应用服务器。进而，在当前的应用服务器接收到包含该目标待处理任务的待处理任务列表后，可通过提取任务列表中每个待处理任务的任务信息，匹配出与自身服务器标识一致的目标待处理任务，对该目标待处理任务进行处理。丢弃其他不是自己创建的任务，从而保证逻辑的一致性，确保任务处理的成功率。

进一步，如果本实施例中的应用服务器被选定为进行任务捞取的第一服务器，则会接收到任务处理装置分发的任务信息，基于该任务信息去生成待处理任务列表。具体的，可从任务信息指示的数据库中捞取预设数量的待处理任务，生成待处理任务列表，待处理任务列表中每个待处理任务携带了任务信息，该任务信息中包含了创建该任务的应用服务器的服务器标识。然后，应用服务器会将该待处理任务列表广播至全网所有的应用服务器，每个应用服务器即可处理待处理任务列表中与自身服务器标识一致的待处理任务，丢弃与自身服务器标识不一致的待处理任务。

第四方面，基于同一发明构思，本说明书实施例提供一种应用服务器，请参考图10，包括如下单元：

创建单元1001，用于创建目标待处理任务，将所述应用服务器的服务器标识添加至所述目标待处理任务的任务信息中；

接收单元1002，用于接收待处理任务列表，所述待处理任务列表中存储有每个待处理任务的任务信息；

确定单元1003，用于遍历所述待处理任务列表中每个待处理任务的任务信息，确定任务信息中服务器标识与所述应用服务器的服务器标识一致的所述目标待处理任务；

处理单元1004，用于对所述目标待处理任务进行处理。

本实施例中的应用服务器进行任务处理的详细过程已在前述第三方面实施例中详细介绍，在此，本申请不做赘述。

第五方面，基于与前述实施例中任务处理方法同样的发明构思，本发明还提供一种任务处理装置，如图11所示，包括存储器1104、处理器1102及存储在存储器1104上并可在处理器1102上运行的计算机程序，处理器1102执行程序时实现前文任务处理方法的任一方法的步骤。

其中，在图11中，总线架构(用总线1100来代表)，总线1100可以包括任意数量的互联的总线和桥，总线1100将包括由处理器1102代表的一个或多个处理器和存储器1104代表的存储器的各种电路链接在一起。总线1100还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本实施例中的方法不再对其进行进一步描述。总线接口1106在总线1100和接收器1101和发送器1103之间提供接口。接收器1101和发送器1103可以是同一个元件，即收发机，提供用于在传输介质上与各种其他装置通信的单元。处理器1102负责管理总线1100和通常的处理，而存储器1104可以被用于存储处理器1102在执行操作时所使用的数据。

第六方面，基于与前述实施例中任务处理方法的发明构思，本发明还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现前文任务处理方法的任一方法的步骤。

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

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

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

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

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