任务发送的处理、任务处理的方法、装置、系统及设备与流程

1.本技术涉及计算机技术，尤其涉及一种任务发送的处理、任务处理的方法、装置、系统及设备。


背景技术：

2.随着计算机技术的发展，通过计算机进行任务处理成为一种趋势。
3.目前，任务处理主要依赖数据库。即数据库中设置有任务表，用于存储用户上传的任务。任务处理端定时从任务表拉取单个或批量的任务进行处理，并将任务的处理结果发送至业务的下游系统。
4.然而，定时从任务表拉取任务的方式存在频繁查询任务表，导致数据库压力过大的问题。


技术实现要素：

5.本技术提供一种任务发送的处理、任务处理的方法、装置、系统及设备，用以解决定时从任务表拉取任务的方式存在频繁查询任务表，导致数据库压力过大的问题。
6.第一方面，本技术提供一种任务发送的处理方法，应用于任务提交端，所述方法包括：获取待处理的任务，所述任务为待补充订单信息的订单任务或待添加物品信息的任务，所述任务包括任务类型；根据所述任务的任务类型，以及预设的任务类型与任务队列之间的对应关系，确定与所述任务对应的任务队列；向与所述任务对应的任务队列发送所述任务。
7.第二方面，本技术提供一种任务处理方法，应用于任务处理端，所述任务处理端对应一个任务队列，所述方法包括：获取所述任务队列中待处理的任务，所述任务为待补充订单信息的订单任务或待添加物品信息的任务；调用预先建立的第一任务处理线程对所述任务进行处理，并确定所述任务是否处理成功；若确定所述任务处理成功，则将所述任务的处理结果发送至所述任务对应的业务的下游系统。
8.第三方面，本技术提供一种任务发送的处理装置，包括：
9.获取模块，用于获取待处理的任务，所述任务为待补充订单信息的订单任务或待添加物品信息的任务，所述任务包括任务类型；
10.确定模块，用于根据所述任务的任务类型，以及预设的任务类型与任务队列之间的对应关系，确定与所述任务对应的任务队列；
11.发送模块，用于向与所述任务对应的任务队列发送所述任务。
12.第四方面，本技术提供一种任务处理装置，所述任务处理装置对应一个任务队列，包括：
13.获取模块，用于获取所述任务队列中待处理的任务，所述任务为待补充订单信息的订单任务或待添加物品信息的任务；
14.处理模块，用于调用预先建立的第一任务处理线程对所述任务进行处理，并确定
所述任务是否处理成功；
15.发送模块，用于若确定所述任务处理成功，则将所述任务的处理结果发送至所述任务对应的业务的下游系统。
16.第五方面，本技术提供一种任务处理系统，包括：
17.第三方面所述的任务发送的处理装置；
18.第四方面所述的任务处理装置；
19.任务队列数据库，用于存储多个任务队列；
20.配置中心数据库，用于存储所述任务发送的处理装置和所述任务处理装置的任务配置信息，所述任务发送的处理装置的任务配置信息包括任务类型与任务队列之间的对应关系，所述任务处理装置的任务配置信息包括任务处理装置的标识与任务队列之间的对应关系；
21.任务事件信息数据库，用于存储所述任务的任务快照信息。
22.第六方面，本技术提供一种计算机设备，包括：存储器，处理器；
23.存储器；用于存储所述处理器可执行指令的存储器；
24.其中，所述处理器被配置为执行如第一方面或第二方面所述的方法。
25.第七方面，本技术提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如第一方面或第二方面所述的方法。
26.第八方面，本技术提供一种计算机程序产品，包括计算机程序，该计算机程序被处理器执行时实现第一方面或第二方面所述的方法。
27.本技术提供的一种任务发送的处理、任务处理的方法、装置、系统及设备，通过获取待处理的任务，其中，该任务为待补充订单信息的订单任务或待添加物品信息的任务，且该任务包括任务类型；根据任务的任务类型，以及预设的任务类型与任务队列之间的对应关系，确定与任务对应的任务队列；向与任务对应的任务队列发送任务。由于本实施例是向任务队列发送任务，并使任务处理端从任务队列获取任务以及进行处理，因此，可以避免传统的依赖数据库任务表，存在的频繁刷新任务表，导致数据库压力大的问题。
附图说明
28.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本技术的实施例，并与说明书一起用于解释本技术的原理。
29.图1为现有技术的任务处理系统的架构图；
30.图2为本技术实施例提供的任务处理系统的架构图；
31.图3为本技术实施例提供的任务发送的处理方法的流程图；
32.图4为基于图2的系统架构实施的任务处理方法的逻辑框图；
33.图5为本技术实施例提供的任务处理方法的流程图一；
34.图6为本技术实施例提供的任务处理方法的流程图二；
35.图7为本技术实施例提供的任务处理方法的流程图三；
36.图8为本技术实施例提供的任务处理方法的流程图四；
37.图9为本技术实施例提供的任务发送的处理装置的结构示意图；
38.图10为本技术实施例提供的任务处理装置的结构示意图；
39.图11为本技术实施例提供的计算机设备的结构示意图。
40.通过上述附图，已示出本技术明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本技术构思的范围，而是通过参考特定实施例为本领域技术人员说明本技术的概念。
具体实施方式
41.这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本技术相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本技术的一些方面相一致的装置和方法的例子。
42.图1为现有技术的任务处理系统的架构图。如图1所示，该系统包括：多个任务提交端11、数据库服务器12和多个任务处理端13，多个任务提交端11中每个任务提交端11与数据库服务器12通信连接，多个任务处理端13中每个任务处理端13与数据库服务器12通信连接。
43.其中，每个任务提交端11可以是手机、电脑、ipad、服务器等设备；每个任务处理端13也可以是手机、电脑、ipad、服务器等设备。
44.数据库服务器12可以是一台服务器，也可以是包括多台服务器的服务器集群，数据库服务器12中存储有任务表。
45.上述任务处理系统可以应用于对业务处理过程中产生的任务进行处理。具体的，用户可以通过任务提交端11创建任务，并上传至任务表。任务处理端定时从任务表拉取单个或批量的任务进行处理，并将任务的处理结果存储至数据库，或者直接发送至业务的下游系统。下面以一个具体的应用场景结合图1对任务处理过程进行说明：
46.在电商场景下，为了保障订单快速入库(数据库，以下均指入数据库)，以及为用户快速展示订单数据。目前的处理方式是，由订单系统将订单基础信息入库，并且提交待补充订单完整信息的任务至任务表。任务处理端开启定时任务，该定时任务用于指示任务处理端每间隔一段时间从任务表拉取任务，将订单信息补充完整并下发至下游系统，例如库存系统、计费系统。
47.针对上述场景，任务处理端需要频繁查询任务表，导致数据库压力大。
48.另外，随着任务表中任务的不断增加，数据库的磁盘空间会慢慢变少，为了解决磁盘空间变少的问题，需要定时删除历史任务，而删除历史任务也会产生大量的数据库磁盘碎片，占用数据库存储空间。
49.此外，为了保障任务的处理效率，可以将拉取任务的时间间隔设置为较短时间，但这样数据库压力过高。因此，目前拉取任务的时间间隔都不会过短，那么任务处理端依靠定时任务从任务表拉取任务就会出现任务处理延迟，无法保障任务处理速度的问题。
50.又，任务表所在的数据库一旦发生故障，就会导致任务无法创建，出现异常上抛，影响非任务逻辑的正常执行，以及任务数据无法拉取，影响任务正常处理的问题。
51.针对上述技术问题，本技术的发明人提出如下技术构思：使用任务队列代替数据库任务表，向任务队列推送用户创建的任务，并将任务提交端设置为对任务队列中的任务
进行监听，以及在监听到任务的情况下，从任务队列获取任务，从而避免频繁查询数据库任务表，导致数据库压力过大的问题，实现不依赖数据库任务表，减轻数据库压力的效果。
52.下面结合附图以具体的几个实施例对本技术提供的任务处理方法进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程在某些实施例中不再赘述。
53.图2为本技术实施例提供的任务处理系统的架构图。如图2所示，本实施例的系统架构包括：任务提交端21、数据库服务器22、任务处理端23、配置中心24和任务事件库25。多个任务提交端21中每个任务提交端21分别与数据库服务器22、配置中心24和任务事件库25通信连接。多个任务处理端23中每个任务处理端23分别与数据库服务器22、配置中心24和任务事件库25通信连接。
54.其中，每个任务提交端21可以是手机、电脑、ipad、服务器等设备。
55.数据库服务器22可以是一台服务器，也可以是包括多台服务器的服务器集群，数据库服务器22中设置有任务队列和失败队列。数据库服务器中的任务队列和失败队列可以基于redis中list结构实现，也可以基于zookeeper应用的queue队列实现，还可以基于disruptor(高性能队列)实现。
56.每个任务处理端23也可以是手机、电脑、ipad、服务器等设备。
57.配置中心24可以是基于zookeeper的分布式配置中心。
58.任务事件库25可以是elasticsearch数据库(简称es数据库)。
59.任务提交端21可以在配置中心24配置与创建任务相关的信息，例如该任务的路由信息。具体的，路由信息可以是任务类型与任务队列之间的对应关系，该对应关系用于指示一个任务队列存储一种任务类型的任务。
60.同样地，任务处理端23也可以在配置中心24配置与任务处理相关的信息，例如该任务处理端23与任务队列之间的对应关系，该对应关系用于指示一个任务处理端23从与其对应的任务队列获取任务。
61.任务提交端21获取用户创建的任务，并根据路由信息向任务队列发送该任务。任务处理端23根据配置的信息从对应的任务队列获取任务并进行处理。此外，任务提交端21和任务处理端23也可以在任务事件库25中记录任务的任务快照信息，其中，任务快照信息包括任务状态。
62.下面基于图2所示的系统架构图，对任务提交端创建任务并发送任务进行详细介绍。
63.图3为本技术实施例提供的任务发送的处理方法的流程图，如图3所示，本实施例的任务发送的处理方法，包括如下步骤：
64.s301、获取待处理的任务，该任务为待补充订单信息的订单任务或待添加物品信息的任务，该任务包括任务类型。
65.本实施例的方法的执行主体为图2中示出的任务提交端。
66.图4为基于图2的系统架构实施的任务发送的处理方法和任务处理方法的逻辑框图。下面以图4结合图2对本技术实施例的任务发送的处理方法进行详细介绍：
67.本实施例中，待处理的任务可以是用户通过任务提交端创建的任务。
68.如图4所示，任务提交方包括多个任务提交端，每个用户通过一个任务提交端创建
任务。具体的，每个任务提交端上设置有任务处理的应用，该任务处理的应用用于为用户提供创建任务和将创建的任务发送的功能。进一步的，每个应用又可以包括业务代码和任务框架发送端，业务代码用于为用户提供创建任务的业务处理逻辑，任务框架发送端用于将用户创建的任务进行发送。
69.其中，待补充订单信息的订单任务可以是对订单进行出库需要的订单信息进行补充的任务，也可以是对根据订单进行计费需要的订单信息进行补充的任务。
70.图4中的应用a和应用b分布在不同的任务提交端上。应用a和应用b可以为不同的用户提供创建任务并发送该任务的功能。
71.以补充订单信息的任务为例，应用a和应用b可以分别用于创建对不同的订单补充订单信息的任务。举例来说，应用a用于创建对订单a补充订单信息的任务，应用b用于创建对订单b补充订单信息的任务。
72.应用a和应用b也可以分别用于创建对同一订单补充不同订单信息的任务。举例来说，应用a用于创建对订单a中的第一订单信息进行补充的任务，应用b用于创建对订单b中的第二订单信息进行补充的任务，第一订单信息和第二订单信息为不同的订单信息。
73.s302、根据任务的任务类型，以及预设的任务类型与任务队列之间的对应关系，确定与任务对应的任务队列。
74.图2中的数据库服务器设置有多个任务队列，每个任务队列用于处理一种任务类型的任务。为了避免不同类型的任务都集中在一个任务队列中，所有的任务处理端都从同一个任务队列获取任务，造成数据库服务器压力过大的问题，可以将不同的任务类型与任务队列进行绑定，使得一个任务队列用于接收一种任务类型的任务。具体的，在执行步骤s302或步骤s301之前，任务提交端的用户需要在配置中心配置任务类型与任务队列之间的对应关系，从而在任务提交端的设备启动后，定时轮询地从配置中心获取这种对应关系，以用于实现后续的任务发送。
75.s303、向与任务对应的任务队列发送任务。
76.其中，步骤s302和步骤s303为任务提交端进行任务发送的实施方式，具体可以参阅图4中任务框架发送端进行任务发送的逻辑，包括：根据任务的任务类型确定与该任务对应的任务队列；与确定的任务队列建立通信连接；向确定的任务队列发送任务，以使任务处理端从任务队列获取任务并进行处理。
77.如图4所示，任务队列a对应一种任务类型的任务，任务队列a中的0至17代表18个任务，任务提交端发送的任务都将按照上述数字进行顺序编号并存储在该任务队列a中，其中，任务的编号越小，代表该任务在任务队列中的存储时间越短，反之，任务的编号越大，代表该任务在任务队列中的存储时间越久。
78.本实施例中的任务队列为分布式先进先出队列。任务队列可以采用基于redis中list结构实现的队列。请继续参阅图4，本实施例可以通过图4中的服务提供者接口(service provider interface，spi)实现根据具体的业务场景选择相应队列，以及对spi中队列所需方法的实现进行定制的功能。
79.在图3所示实施例的基础上，图5为本技术实施例提供的一种任务处理方法的流程图一，如图5所示，任务处理方法还包括如下步骤：
80.s501、若任务发送失败，则根据重试发送策略重新向任务队列发送任务。
81.其中，重试发送策略包括：在重试次数小于预设次数的情况下，重复执行向任务队列发送任务的操作；在重试次数达到预设次数的情况下，发送异常操作提醒。
82.在执行步骤s501之前，任务提交端需要在配置中心配置任务的重试次数(预设次数)和相邻两次任务的重试操作之间的时间间隔。
83.任务提交端在第一次向任务队列发送任务失败，并重新向任务队列发送的过程中，需要在每次重新向任务队列发送任务后，向任务事件库写入重新向任务队列发送任务的事件，该重新向任务队列发送任务的事件包括当前次事件对应的重新发送任务的时间，则任务事件库根据重新向任务队列发送任务的事件将任务的重试次数进行加1的操作，并根据当前次事件对应的重新发送任务的时间和预先配置的相邻两次任务的重试操作之间的时间间隔，确定下次重新发送任务的时间。
84.具体的，重复执行向任务队列发送任务的操作，包括：根据预先配置的预设次数和任务事件库中记录的任务的重试次数，确定重试次数是否小于预设次数；并在重试次数小于预设次数的情况下，重复执行向任务队列发送任务的操作；在重试次数达到预设次数的情况下，发送异常操作提醒。
85.本实施例通过在向与任务对应的任务队列发送任务失败的情况下，根据重试发送策略重新向任务队列发送任务，并在重试次数小于预设次数的情况下，重复执行向任务队列发送任务的操作；在重试次数达到预设次数的情况下，发送异常操作提醒。重试发送策略能够使任务实现自动重试发送，增加任务发送的成功率。
86.在上述实施例的基础上，任务提交端在第一次向任务队列发送任务之后，需要向任务事件库写入任务的第一任务快照信息，该第一任务快照信息包括：任务编号、任务对应的业务的编号、任务名称、任务对应的业务的数据、任务提交端的ip地址、任务提交时间和任务状态等。以及，在每次重新向任务队列发送任务后，向任务事件库写入任务的第二任务快照信息，第二任务信息包括向任务队列发送任务的重试次数和任务的下次重新发送时间。
87.其中，任务编号用于唯一标识该任务，任务对应的业务的编号用于唯一标识任务。任务名称能够用于确定任务类型，任务对应的业务的数据具体可以是订单号等数据。在任务提交端向任务队列发送任务之后，任务处理端还未处理该任务时，任务状态为未处理状态。
88.针对每一次的任务快照信息的写入事件，若任务快照信息写入失败，则根据重新写入策略重新向任务事件库写入任务的任务快照信息；其中，重新写入策略包括：在重新写入次数小于预设写入次数的情况下，重复执行向任务事件库写入任务的任务快照信息的操作；在重新写入次数达到预设写入次数的情况下，丢弃任务的任务快照信息。
89.同样地，任务提交端需要在配置中心配置任务快照信息的预设写入次数，并根据预设写入次数和当前次写入次数确定是否能够继续向任务事件库写入任务快照信息。
90.本实施例通过在第一次向任务队列发送任务之后，向任务事件库写入任务的第一任务快照信息，该第一任务快照信息包括：任务对应的业务的数据。相当于在任务事件库中对任务进行了备份，如此，即使数据库中的任务队列发生故障，也不会影响任务拉取，从而保证任务的正常处理。另外，根据重新写入策略重新向任务事件库写入任务快照信息，从而能够使任务快照信息实现自动重试写入，增加任务快照信息写入的成功率。
91.下面基于图2所示的系统架构图，对任务处理端处理任务进行详细介绍。
92.图6为本技术实施例提供的一种任务处理方法的流程图二，如图6所示，本实施例的任务处理方法，包括如下步骤：
93.s601、获取任务队列中待处理的任务。
94.若任务发送成功，则任务处理端可以获取任务队列中待处理的任务。
95.与任务提交端需要将不同的任务类型与任务队列进行绑定，使得一个任务队列用于接收一种任务类型的任务相对应，任务处理端同样需要将任务提交端与任务类型进行绑定。具体的，在执行步骤s601之前，任务提交端的用户需要在配置中心配置该任务提交端的标识与任务队列之间的对应关系，从而在任务提交端的设备启动后，定时轮询地从配置中心获取对应关系，以从任务队列获取任务进行处理。
96.在一些实施方式中，步骤s601包括：根据任务提交端的标识和任务提交端的标识与任务队列之间的对应关系，确定与任务提交端的标识对应的任务队列；与确定的任务队列建立通信连接；监听确定的任务队列中的待处理的任务；若监听到确定的任务队列中的待处理的任务，从确定的任务队列中获取待处理的任务。
97.s602、调用预先建立的第一任务处理线程对任务进行处理，并确定任务是否处理成功。
98.另外，任务处理端还需要在配置中心预先配置对任务队列中的任务进行处理的配置信息，具体包括第一任务处理线程的数量、任务队列中任务的拉取间隔、任务队列中任务的重新处理策略、任务队列中任务的失败策略、延迟线程数、任务队列中任务的监控配置、任务队列中任务的限流策略、数据序列化转换器、任务失败处理器。则步骤s602包括：根据预先配置的第一任务处理线程的数量，建立相应数量的第一任务处理线程；每个第一任务处理线程根据任务的拉取间隔，从任务队列中拉取任务；每个第一任务处理线程对从任务队列中拉取到的任务进行处理。
99.图4为基于图2的系统架构实施的任务处理方法的逻辑框图。下面以图4结合图2对本技术实施例的任务处理方法进行详细介绍：
100.请继续参阅图4，每个任务处理线程对拉取到的任务进行处理，并确定任务是否处理成功，包括：将任务对应的业务数据输入数据序列化转换器进行反序列化处理，得到业务数据的反序列化结果；将业务数据的反序列化结果输入任务前置处理器进行前置处理，得到前置处理结果；将前置处理结果输入主任务处理器中进行处理，得到中间处理结果；将中间处理结果输入任务后置处理器中进行后置处理，得到后置处理结果；根据后置处理结果确定任务是否处理成功。
101.其中，任务的监控配置：允许对任务进行监控埋点，借助外部监控平台收集展示监控信息。
102.任务限流：任务处理方可以设置一最大处理速度，以对任务处理限流，例如是否开启限流，每秒最大任务处理次数。
103.任务失败处理器：用于对失败任务进行处理。
104.可选的，还可以在任务处理失败时，默认为先确定是否满足重新处理条件，若满足，则提交任务队列重新处理；若不满足条件，则进行报警，并发送提醒，包括但不限于发送邮件、短信等形式。
105.请继续参阅图4，本实施例中的第一任务处理线程可以是单独的消费线程，也可以是多个消费线程，多个消费线程可以并行地对任务进行处理，例如一个消费线程对一个任务进行处理。
106.s603、若确定任务处理成功，将任务的处理结果发送至任务对应的业务的下游系统。
107.针对补充出库需要的订单信息的订单任务，若确定对订单进行出库需要的订单信息补充成功，则将补充后的订单发送至出库系统。
108.针对补充计费需要的订单信息的订单任务，若确定对订单进行计费需要的订单信息补充成功，则将补充后的订单发送至计费系统。
109.当然，也可以将补充后的订单存储在图2中的数据库服务器中，并由出库系统或计费系统从数据库服务器中调用。
110.本实施例中，若确定任务处理成功，还可以将任务事件库中该任务的任务状态更新为成功。
111.s604、若确定任务处理失败，则根据重新处理策略重新对任务进行处理。
112.具体的，根据重新处理策略重新对任务进行处理包括：
113.a1、根据预设的处理次数确定当前次的重新处理的次数是否小于预设的处理次数。
114.a2、在重新处理的次数小于预设的处理次数的情况下，重复执行对任务进行处理的操作。
115.本实施例中，任务处理端需要在配置中心配置最大重试次数(预设的处理次数)、最大重试间隔、重试间隔、指数增加间隔时间、指数系数、过期时间等任务处理相关的配置信息。
116.其中，最大重试次数为任务能够重新进行处理的最大次数。
117.最大重试间隔为对任务进行重新处理的最大时间间隔的单位，也就是说相邻两次重新处理的时间间隔不能超过最大重试间隔。
118.重试间隔为任务的相邻两次重新处理之间的最小时间间隔单位。
119.指数增加间隔时间为在相邻两次重新处理之间的最小时间间隔单位的基础上增加的时间间隔。
120.指数系数为指数增加间隔时间的变化程度。
121.过期时间为任务的最晚处理时间。
122.具体的，确定任务的下次重新处理时间，包括：根据重试间隔、指数增加间隔时间和指数系数，确定相邻两次重新处理时间之间的时间间隔；在当前次重新处理时间的基础上增加确定的相邻两次重新处理时间之间的时间间隔，得到下次重新处理时间。
123.下面通过举例对重新处理策略进行说明：
124.假设重试间隔为1秒，指数增加间隔时间为1秒，指数系数为2，最大重试间隔为5秒，任务的第一次重新处理时间为12:00:00，则在第一次重新处理失败的情况下，第二次重新处理时间的计算过程为：指数增加间隔时间为1秒，指数系数为2，则根据重试间隔、指数增加间隔时间和指数系数，第二次重新处理时间与第一次重新处理时间之间的时间间隔为1秒*1秒*1＝1秒；在12:00:00的基础上增加1秒，第二次重新处理时间为12:00:01，在第二
次重新处理失败的情况下，根据重试间隔、指数增加间隔时间和指数系数，第三次重新处理时间与第二次重新处理时间之间的时间间隔为1秒*1秒*2＝2秒；在12:00:01的基础上增加2秒，第三次重新处理时间为12:00:03。
125.其中，根据重新处理策略重新对任务进行处理，若确定任务处理成功，仍然需要将任务事件库中该任务的任务状态更新为成功。
126.具体的，任务对应有下次重新处理时间，则步骤a2中重复执行对任务进行处理的操作，包括：
127.a21、若当前次重复处理后的时间达到任务的下次重新处理时间，则将任务发送至任务队列的头部或尾部。
128.a22、若当前次重复处理后的时间未达到任务的下次重新处理时间，则将任务发送至延迟队列，并在当前次重复处理后的时间达到任务的下次重新处理时间的情况下，将延迟队列中的任务转移至任务队列的头部或尾部。
129.其中，延迟队列包括多个延迟线程，任务在重新处理时会计算任务的下次重新处理时间，即本次任务执行时间到下次执行时间的时间间隔，进而在本地创建多个延迟线程，根据时间间隔对这些未到下次执行时间的任务进行延迟处理。
130.a3、在重新处理的次数达到预设的处理次数的情况下，将任务发送至失败队列进行处理。
131.在步骤a3中，还需要将任务事件库中该任务的任务状态更新为失败。
132.本实施例通过获取任务队列中待处理的任务，该任务为待补充订单信息的订单任务或待添加物品信息的任务；调用预先建立的第一任务处理线程对任务进行处理，并在确定任务处理成功的情况下，将任务的处理结果发送至任务对应的业务的下游系统。由于本实施例是从任务队列中获取任务，并通过第一任务处理线程进行处理，任务队列中的任务在出队列后，则不再存在该任务队列中，因此，任务队列中的任务数量能够基本保持在恒定的数量，从而可以避免定时任务频繁查询数据库任务表，导致数据库压力过大的问题，以及传统数据库任务表的方式存在的任务表数据不断增加，数据库磁盘空间慢慢变少，定时删除历史任务数据也会产生大量数据库磁盘碎片，占用数据库存储空间的问题。另外，多个任务处理线程并行进行任务处理，能够提高任务处理效率。此外，重新处理策略能够提高任务处理的成功率。
133.在图6所示实施例的基础上，图7为本技术实施例提供的一种任务处理方法的流程图三，如图7所示，在重新处理的次数达到预设的处理次数的情况下，将任务发送至失败队列进行处理，包括如下步骤：
134.s701、获取失败队列中的任务。
135.本实施例中，任务提交端的用户需要在配置中心配置该任务提交端的标识与失败队列之间的对应关系，从而在任务提交端的设备启动后，定时轮询地从配置中心获取任务提交端的标识与失败队列之间的对应关系，以从失败队列中获取任务进行处理。
136.在一些实施方式中，步骤s701包括：根据任务提交端的标识和任务提交端的标识与失败队列之间的对应关系，确定与任务提交端的标识对应的失败队列；与确定的失败队列建立通信连接；监听确定的失败队列中的待处理的任务；若监听到确定的失败队列中的待处理的任务，从确定的失败队列中获取待处理的任务。
137.s702、调用预先建立的第二任务处理线程对失败队列中的任务进行处理，并确定失败队列中的任务是否处理成功。
138.另外，任务处理端还需要在配置中心预先配置对失败队列中的任务进行处理的配置信息，具体包括第二任务处理线程的数量、失败队列中任务的拉取间隔、失败队列中任务的重新处理策略、失败策略、延迟线程数、任务监控配置、限流策略、任务失败处理器。则步骤s702包括：根据预先配置的第二任务处理线程的数量，建立相应数量的第二任务处理线程；每个第二任务处理线程根据失败队列中任务的拉取间隔，从失败队列中拉取任务；每个第二任务处理线程对从失败队列中拉取到的任务进行处理。
139.s703、若失败队列中的任务处理成功，则将失败队列中任务的处理结果发送至任务对应的业务的下游系统。
140.在一些实施方式中，针对补充出库需要的订单信息的订单任务，若确定对订单进行出库需要的订单信息补充成功，则将补充后的订单发送至出库系统。
141.在另一些实施方式中，针对补充计费需要的订单信息的订单任务，若确定对订单进行计费需要的订单信息补充成功，则将补充后的订单发送至计费系统。
142.当然，也可以将补充后的订单存储在图2中的数据库服务器中，并由出库系统或计费系统从数据库服务器中调用。
143.s704、若失败队列中的任务处理失败，则确定重复处理次数是否达到预设的重复次数；
144.s705、在重复处理次数小于预设的重复次数的情况下，重新执行调用预先建立的第二任务处理线程对所述失败队列中的任务进行处理的操作。
145.s706、在重复处理次数达到预设的重复次数的情况下，则将任务事件库中所述失败队列中的任务的任务状态设置为失败状态。
146.同样地，任务处理端需要在配置中心预先配置预设的重复次数，并在对失败队列中的任务处理失败的情况下，根据失败策略重新对任务进行处理。具体的，根据失败策略重新对任务进行处理，包括步骤s704和步骤s705。
147.本实施例通过失败队列对任务队列中处理失败的任务继续进行处理，能够进一步提高任务处理成功率。
148.请继续参阅图4，如图4中任务补偿部分示出了任务补偿策略，该任务补偿策略具体是定时拉取任务事件库中超时未处理的任务进行任务处理，以避免该类任务长时间未处理造成超时的情况。具体的实现过程如下：
149.在图6和图7所示实施例的基础上，图8为本技术实施例提供的任务处理方法的流程图四，如图8所示，该任务处理方法还包括如下步骤：
150.s801、确定任务事件库中任务状态为未处理状态的任务。
151.具体的，本实施例是根据任务提交端在任务事件库中写入的任务的任务快照信息中的任务状态，确定任务事件库中任务状态为未处理状态的任务。
152.s802、确定未处理状态的任务中的目标任务，其中，目标任务是任务的过期时间与当前时间的时间差小于或等于预设时间的任务。
153.本实施例中，任务处理端需要在配置中心预先配置任务的过期时间和预设时间等与任务补偿处理相关的配置信息，并确定未处理状态的任务中，任务的过期时间与当前时
间的时间差小于或等于预设时间的任务作为目标任务，目标任务即为超时未处理的任务。
154.s803、根据预设的任务获取信息获取目标任务。
155.本实施例中，任务处理端需要在配置中心预先配置取数开始时间处理器(默认是减1，不设限制)、取数结束时间处理器(默认是当前时间减10分钟，即10分钟前提交的任务)、每次拉取的任务数量等任务获取信息。
156.则步骤s803包括：根据取数开始时间处理器计算开始时间；根据取数结束时间处理器计算结束时间；根据开始时间、结束时间和每次拉取的任务数量，获取位于开始时间和结束时间的范围内，且数量不超过每次拉取的任务数量的目标任务；对目标任务执行上述图6和图7所示实施例的任务处理的方法步骤，并在任务处理成功的情况下，将任务事件库中该任务的任务状态更新为成功，在任务处理失败的情况下，将任务事件库中该任务的任务状态更新为失败。
157.s804、根据预先建立的第三任务处理线程，对获取的目标任务进行处理。
158.本实施例中，任务处理端需要在配置中心预先配置第三任务处理线程的数量等与任务补偿处理相关的配置信息。则步骤s805包括：根据预先配置的第三任务处理线程的数量，建立相应数量的第三任务处理线程；每个第三任务处理线程根据目标任务的拉取间隔，从任务事件库中拉取目标任务；每个第三任务处理线程对从任务事件库中拉取到的目标任务进行处理。
159.请继续参阅图4，在一些可选的实施例中，还可以提供同步服务，同步服务用于为任务处理端的用户提供手动调用任务补偿服务对单个或多个超时未处理任务进行重试的功能。
160.可选的，在任务补偿之前，需要在配置中心进行如下配置：
161.es库配置：为任务补偿时，与es数据库进行连接时的相关配置，如统一资源定位器(uniform resource locator，url)、用户名、密码等连接信息。
162.任务列表：与任务提交端、任务处理端使用的找到对应任务队列的配置类似，区别在于任务提交端、任务处理端是根据任务类型找对应队列，任务补偿为根据任务类型在es库查找任务信息。
163.cron：为一种通用表达式，如：00/2***？表示每2分钟执行一次任务补偿。取数开始时间处理器、取数结束时间处理器用于在任务补偿时查询待进行补偿处理的任务，cron用于配置查询任务的执行频率。
164.本实施例通过确定任务事件库中任务状态为未处理状态的任务，以及确定未处理状态的任务中，任务的过期时间与当前时间的时间差小于或等于预设时间的目标任务，和根据预设的时间段获取目标任务，并根据预先建立的第三任务处理线程，对获取的目标任务进行处理。由于本实施例是针对未处理状态的任务中，任务的过期时间与当前时间的时间差小于或等于预设时间的目标任务进行任务处理，因此，能够减少任务长时间未处理的情况，从而保障任务处理时效，提高任务处理效率，在订单场景下，就能够将补充订单信息的订单快速下发至下游系统。
165.在上述任务处理方法实施例的基础上，图9为本技术实施例提供的任务发送的处理装置的结构示意图。如图9所示，该任务发送的处理装置包括：获取模块91、确定模块92和发送模块93；其中，获取模块91，用于获取待处理的任务，所述任务为待补充订单信息的订
单任务或待添加物品信息的任务，所述任务包括任务类型；确定模块92，用于根据所述任务的任务类型，以及预设的任务类型与任务队列之间的对应关系，确定与所述任务对应的任务队列；发送模块93，用于向与所述任务对应的任务队列发送所述任务。
166.在一种可能的设计中，该装置还包括：所述发送模块93，还用于执行以下操作：若所述任务发送失败，则根据重试发送策略重新向所述任务队列发送所述任务；其中，所述重试发送策略包括：在重试次数小于预设次数的情况下，重复执行向所述任务队列发送所述任务的操作；在所述重试次数达到所述预设次数的情况下，发送异常操作提醒。
167.在一种可能的设计中，所述任务还包括任务快照信息，所述任务快照信息包括第一任务快照信息和第二任务快照信息，则该装置还包括：写入模块94，用于执行以下操作：向任务事件库写入任务的第一任务快照信息，该第一任务快照信息包括如下至少一项：向任务事件库写入任务编号、任务对应的业务的编号、任务名称、任务对应的业务的数据、任务提交端的ip地址、任务提交时间和任务状态；以及，在每次重新向任务队列发送任务后，向任务事件库写入任务的第二任务快照信息，第二任务信息包括向任务队列发送任务的重试次数和任务的下次重新发送时间。
168.在一种可能的设计中，写入模块94，还用于执行以下操作：若所述任务快照信息写入失败，则根据重新写入策略重新向所述任务事件库写入所述任务的任务快照信息；其中，所述重新写入策略包括：在重新写入次数小于预设写入次数的情况下，重复执行向所述任务事件库写入所述任务的任务快照信息的操作；在重新写入次数达到所述预设写入次数的情况下，丢弃所述任务的任务快照信息。
169.本技术实施例提供的任务发送的处理装置，可用于执行上述实施例中任务发送的处理方法的技术方案，其实现原理和技术效果类似，在此不再赘述。
170.在上述任务处理方法实施例的基础上，图10为本技术实施例提供的任务处理装置的结构示意图。如图10所示，该任务处理装置包括：
171.获取模块101，用于获取所述任务队列中待处理的任务，所述任务为待补充订单信息的订单任务或待添加物品信息的任务；
172.处理模块102，用于调用预先建立的第一任务处理线程对所述任务进行处理，并确定所述任务是否处理成功；
173.发送模块103，用于若确定所述任务处理成功，则将所述任务的处理结果发送至所述任务对应的业务的下游系统。
174.在一种可能的设计中，处理模块102，还用于执行以下操作：若确定所述任务处理失败，则根据重新处理策略重新对所述任务进行处理；其中，所述重新处理策略包括：若重新处理的次数小于预设的处理次数，则重复执行对所述任务进行处理的操作；若重新处理的次数达到预设的处理次数，则将所述任务发送至失败队列进行处理。
175.在一种可能的设计中，所述任务对应有下次重新处理时间，发送模块103，还用于执行以下操作：若当前次重复处理后的时间达到所述任务的下次重新处理时间，则将所述任务发送至所述任务队列的头部或尾部；若当前次重复处理后的时间未达到所述任务的下次重新处理时间，则将所述任务发送至延迟队列，并在所述当前次重复处理后的时间达到所述任务的下次重新处理时间的情况下，将所述延迟队列中的所述任务转移至所述任务队列的头部或尾部。
176.在一种可能的设计中，获取模块101，还用于获取所述失败队列中的任务；处理模块102，还用于调用预先建立的第二任务处理线程对所述失败队列中的任务进行处理，并确定所述失败队列中的任务是否处理成功；发送模块103，还用于若所述失败队列中的任务处理成功，则将所述失败队列中任务的处理结果发送至所述任务对应的业务的下游系统；若所述失败队列中的任务处理失败，则在重复处理次数小于预设的重复次数的情况下，重新执行调用预先建立的第二任务处理线程对所述失败队列中的任务进行处理的操作；若所述失败队列中的任务处理失败，则在重复处理次数达到预设的重复次数的情况下，则将任务事件库中所述失败队列中的任务的任务状态设置为失败状态。
177.在一种可能的设计中，该装置还包括：确定模块104；
178.获取模块101，还用于获取任务事件库中任务状态为未处理状态的任务；
179.确定模块104，用于确定所述未处理状态的任务中的目标任务，所述目标任务是任务的过期时间与当前时间的时间差小于或等于预设时间的任务；
180.获取模块101，还用于根据预设的任务获取信息获取所述目标任务；
181.处理模块102，还用于根据预先建立的第三任务处理线程，对获取的所述目标任务进行处理。
182.本技术实施例提供的任务处理装置，可用于执行上述实施例中任务处理方法的技术方案，其实现原理和技术效果类似，在此不再赘述。
183.需要说明的是，应理解以上装置的各个模块的划分仅仅是一种逻辑功能的划分，实际实现时可以全部或部分集成到一个物理实体上，也可以物理上分开。且这些模块可以全部以软件通过处理元件调用的形式实现；也可以全部以硬件的形式实现；还可以部分模块通过处理元件调用软件的形式实现，部分模块通过硬件的形式实现。例如，处理模块102可以为单独设立的处理元件，也可以集成在上述装置的某一个芯片中实现，此外，也可以以程序代码的形式存储于上述装置的存储器中，由上述装置的某一个处理元件调用并执行以上处理模块102的功能。其它模块的实现与之类似。此外这些模块全部或部分可以集成在一起，也可以独立实现。这里的处理元件可以是一种集成电路，具有信号的处理能力。在实现过程中，上述方法的各步骤或以上各个模块可以通过处理器元件中的硬件的集成逻辑电路或者软件形式的指令完成。
184.图11为本技术实施例提供的计算机设备的结构示意图。如图11所示，该计算机设备可以包括：处理器111、存储器112和收发器113。
185.处理器111执行存储器存储的计算机执行指令，使得处理器111执行上述实施例中的方案。处理器111可以是通用处理器，包括中央处理器cpu、网络处理器(network processor，np)等；还可以是数字信号处理器dsp、专用集成电路asic、现场可编程门阵列fpga或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
186.存储器112通过系统总线与处理器111连接并完成相互间的通信，存储器112用于存储计算机程序指令。
187.收发器113可以用于获取待处理的任务。
188.系统总线可以是外设部件互连标准(peripheral component interconnect，pci)总线或扩展工业标准结构(extended industry standard architecture，eisa)总线等。系统总线可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但
并不表示仅有一根总线或一种类型的总线。收发器用于实现数据库访问装置与其他计算机(例如客户端、读写库和只读库)之间的通信。存储器可能包含随机存取存储器(random access memory，ram)，也可能还包括非易失性存储器(non
‑
volatile memory)。
189.本技术实施例提供的计算机设备，可用于执行上述实施例中任务发送的处理方法或任务处理方法的技术方案，其实现原理和技术效果类似，在此不再赘述。
190.本技术实施例还提供一种运行指令的芯片，该芯片用于执行上述实施例中任务发送的处理方法或任务处理方法的技术方案。
191.本技术实施例还提供一种计算机可读存储介质，该计算机可读存储介质中存储有计算机指令，当该计算机指令在计算机上运行时，使得计算机执行上述实施例任务发送的处理方法或任务处理方法的技术方案。
192.本技术实施例还提供一种计算机程序产品，该计算机程序产品包括计算机程序，其存储在计算机可读存储介质中，至少一个处理器可以从计算机可读存储介质读取计算机程序，至少一个处理器执行计算机程序时可实现上述实施例中任务发送的处理方法或任务处理方法的技术方案。
193.最后应说明的是：以上各实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述各实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的范围。