用于处理订单的方法、装置、设备和存储介质与流程 专利技术说明

计算;推算;计数设备的制造及其应用技术1.本公开的示例实施例总体涉及计算机领域，特别地涉及用于处理订单的方法、装置、设备和计算机可读存储介质。背景技术：2.在支付过程中，订单可能因为各种网络或处理异常而无法被有效地完成。由此，订单补单(即，推进订单执行到中台)已经成为订单系统中的一项重要任务。3.传统的补单系统通过轮询数据库来发现带处理的订单。然而，这样的方式通常是低效地，且造成漏单、卡单等情况。技术实现要素：4.在本公开的第一方面，提供了一种处理订单的方法。该方法包括：确定与目标时间窗相关联的一组订单，一组订单尚未完成；向与一组订单相关联的业务方请求一组订单被执行；响应于从业务方接收到指示一组订单完成的消息，查询由业务方维护的订单数据库，以验证一组订单是否完成；以及响应于一组订单被验证为完成，更新一组订单的状态以指示订单完成。5.在本公开的第二方面，提供了一种用于处理订单的装置。该装置包括确定模块，被配置为确定与目标时间窗相关联的一组订单，一组订单尚未完成；请求模块，被配置为向与一组订单相关联的业务方请求一组订单被执行；验证模块，被配置为响应于从业务方接收到指示一组订单完成的消息，查询由业务方维护的订单数据库，以验证一组订单是否完成；以及更新模块，被配置为响应于一组订单被验证为完成，更新一组订单的状态以指示订单完成。6.在本公开的第三方面，提供了一种电子设备。该设备包括至少一个处理单元；以及至少一个存储器，至少一个存储器被耦合到至少一个处理单元并且存储用于由至少一个处理单元执行的指令。指令在由至少一个处理单元执行时使设备执行第一方面的方法。7.在本公开的第四方面，提供了一种计算机可读存储介质。介质上存储有计算机程序，程序被处理器执行时实现第一方面的方法。8.应当理解，本发明内容部分中所描述的内容并非旨在限定本公开的实施例的关键特征或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的描述而变得容易理解。附图说明9.结合附图并参考以下详细说明，本公开各实施例的上述和其他特征、优点及方面将变得更加明显。在附图中，相同或相似的附图标记表示相同或相似的元素，其中：10.图1a至图1c示出了传统的支付流程的示意图；11.图2示出了本公开的实施例能够在其中实现的示例环境的示意图；12.图3示出了根据本公开的一些实施例的任务的状态变化示意图；13.图4示出了根据本公开的一些实施例的生产者模块的处理过程的示意图；14.图5示出了根据本公开的一些实施例的消费者模块的处理过程的示意图；15.图6示出了根据本公开的一些实施例的订单处理系统的示例框图；16.图7示出了根据本公开的一些实施例的处理订单的示例过程的流程图；17.图8示出了根据本公开的一些实施例的用于处理订单的装置的框图；以及18.图9示出了能够实施本公开的多个实施例的设备的框图。具体实施方式19.下面将参照附图更详细地描述本公开的实施例。虽然附图中示出了本公开的某些实施例，然而应当理解的是，本公开可以通过各种形式来实现，而且不应该被解释为限于这里阐述的实施例，相反，提供这些实施例是为了更加透彻和完整地理解本公开。应当理解的是，本公开的附图及实施例仅用于示例性作用，并非用于限制本公开的保护范围。20.在本公开的实施例的描述中，术语“包括”及其类似用语应当理解为开放性包含，即“包括但不限于”。术语“基于”应当理解为“至少部分地基于”。术语“一个实施例”或“该实施例”应当理解为“至少一个实施例”。术语“一些实施例”应当理解为“至少一些实施例”。下文还可能包括其他明确的和隐含的定义。21.在常规的交易过程中，如图1a所示，通常是由订单系统110来发起支付，并发起接口调用120。相应地，支付系统130可以向订单系统110返回消息通知，以指示订单的处理状态，例如，订单处理成功、处理失败、或在处理中。22.然而，在一些情况下，订单系统110调用支付接口可能出现网络超时或网络断联等情况。如图1b所示，例如，接口调用120可能无法被发送至支付系统130。然而，在这种情况下，订单系统110中已经生成相应的订单，但支付系统130中可能没有订单，这种情况下，应当需要重新发起调用。23.在另一些情况下，如图1c所示，支付系统130同步返回订单系统110时可能出现网络超时或者断联。在这种情况下，订单系统110和支付系统130都已经生成对应的订单，但是由于支付系统130同步返回网联问题导致支付系统无法感知订单是否成功，这个时候就需要一个机制去再次确认订单的状态，确保订单的状态达到终态。24.由此，对于订单系统而言，补单是一项重要的任务。补单就是将处在中间态的订单进行补偿，直到推进到终态(成功或失败)。补单的及时性和有效性是影响用户体验的关键因素。25.本公开的实施例提供了一种用于处理订单的方案。在该方案中，可以确定与目标时间窗相关联的一组尚未完成的订单。进一步，可以向与该组订单相关联的业务方请求该组订单被执行。26.如果从业务方接收到指示一组订单完成的消息，则可以进一步查询由业务方维护的订单数据库，以验证该组订单是否完成。如果该组订单被验证为完成，则可以更新该组订单的状态以指示订单完成。27.基于这样的方式，一方面，本公开的实施例能够基于时间窗的方式来进行补单，从而提高补单的效率。另一方面，通过二次验证的机制，本公开的实施例还能够提高补单的有效性。28.以下将结合附图详细描述根据本公开实施例的示例方案。29.图2示出了根据本公开的一些实施例的示例环境200的示意图。如图2所示，环境200包括补单设备210，其可以被配置为与业务方220通信，以执行订单230的补偿操作(也称为，补单操作)。30.在一些实施例中，这样的补单设备210可以包括由补单方(例如，补单中心)管理的任何适当的电子设备。这样的补单设备210例如可以通过订单数据库来获取订单230，并利用业务方220所提供的接口来推进订单230被执行至终态。31.关于补单设备210的具体处理过程将在下文结合附图详细描述。32.示例状态机33.在一些实施例中，补单设备210可以通过状态机来管理订单230的补偿。图3示出了根据本公开的一些实施例的任务的状态变化示意图300。34.在一些实施例中，补单设备210可以获取与预定时间窗相关联的一组尚未完成(即，未到终态)的订单。关于该组订单的确定过程将在下文结合图4详细描述。35.相应地，补单设备210可以生成与该组订单对应的任务。这样的任务例如可以被设置为初始态310。36.进一步地，补单设备210可以利用业务方220所提供的执行接口(或服务)来请求该组订单被执行。相应地，如果补单设备210从业务方220确定该组订单被成功执行(即，到达终态)，则该任务可以进行到待定态320。37.相反，如果任务执行失败或者任务执行超时，则该任务可以进行到处理态330。相应地，在处理态330，补单设备210可以执行任务的重新执行。例如，补单设备210可以利用利用业务方220所提供的执行接口(或服务)来重新请求该组订单被执行。38.如果重新执行该任务使得该组订单达到终态，则该任务可以类似地进行到待定态。相反，如果该任务执行失败或执行超时，则补单设备210可以再次执行该任务。39.在一些实施例中，补单设备210可以根据固定的时间间隔来执行任务的重新执行或再次执行。例如，补单设备210可以在上次执行后的固定时间间隔后重新执行该任务。40.在一些实施例中，补单设备210还可以根据任务已经重新执行的次数来确定再次请求的时间间隔。具体地，补单设备210可以确定任务已经被重新执行的次数，并基于该次数来确定时间间隔，使得该时间间隔正相关于次数。例如，如果任务已经重新执行了2次，则其第3次重新执行的时刻到第2次重新执行的时刻的间隔例如可以大于第2次重新执行的时刻到第1次重新执行的时刻的间隔。基于这样的方式，本公开的实施例可以降低业务方接口的负载压力。41.进一步地，补单设备210可以根据所确定的用于重新请求的时间间隔，并基于上次重新执行任务的历史时刻和所确定的时间间隔二者来确定目标时刻。附加地，补单设备210可以在所确定的目标时刻来执行该任务，以向业务方重新请求与该任务相关联的订单被执行。42.在一些实施例中，如果任务的重新执行次数已经超过阈值数目或与该任务已经过期，则补单设备210可以将该任务标记为未成功。具体地，如果是因为超过最大重试次数(即，阈值数目)，则补单设备210可以将该任务标记为失败态360。备选地，如果是因为任务已经过期，则补单设备210可以将该任务标记为过期态370。43.继续参考图3，如上文所讨论，如果业务方反馈该组订单均已经完成，则该任务可以进行到待定态320。进一步地，补单设备210可以在框340执行二次验证。具体地，补单设备210可以查询由业务方220维护的订单数据库，以验证该组订单是否已经完成。44.如果二次验证未过，即订单数据库仍然存在被标记为未完成的订单，则该任务将被重新置回初始态310，并重新执行如图3所示的状态机运行过程。在一些实施例中，在二次验证未通过的情况下，补单设备210例如还可以生成告警信息，以指示业务方的订单数据库与业务方接口所返回的状态不匹配。45.相反，如果二次验证通过，则补单设备210可以将该任务置为成功态350，以指示该至少一个未完成的订单已经被成功地推进到完成态，即完成了补单操作。46.基于以上所介绍的状态机切换过程，本公开的实施例能够通过任务状态转换的方式来有效地管理订单的补单过程，从而提高补单的可靠性。47.在一些实施例中，补单设备210还可以维护与任务对应的执行信息，也称为流水表。例如，补单设备210可以维护与任务的重新执行相关联的执行信息。48.这样的执行信息例如可以包括与该任务相关联的一组订单的信息，例如订单的标识。备选地或附加地，这样的执行信息例如还可以包括关于每次重新执行的执行描述信息，例如，重新执行的时刻，重新执行的结果(例如，使得被成功推进到终态的订单的数目、未被成功推进到终态的订单数目)等。备选地或附加地，这样的执行信息例如还可以包括任务执行失败或执行超时的原因描述信息，例如，由业务方返回的订单未被成功推进到终态的原因。49.通过维护这样的执行信息，本公开的实施例能够方便补单方来显式地管理补单过程。附加地，补单设备210例如还可以提供这样的执行信息，以用于分析该任务。50.示例生产者模块51.在一些实施例中，补单设备210可以利用生产者模块和消费者模块来管理任务的生成、流转和消费。52.图4示出了根据本公开的一些实施例的生产者模块的处理过程400的示意图。如图4所示，生产者模块可以包括触发器405、任务服务410、任务数据库415。查询服务420、本地数据备份425和源数据库430例如可以由业务方所提供。53.在一些实施例中，本地数据备份425，也称为订单数据副本，例如可以是通过异构方式所构建的源数据库430的数据镜像，其可以被部署在补单方本地，以提高访问效率，并降低业务方的数据库访问压力。54.如图4所示，在432，触发器405(也称为任务触发器405)可以被配置为定期地触发任务服务410，以生成任务。相应地，在434，任务服务410可以查询任务数据库415，并在436来确定与该任务待被分配的任务标识。55.进一步地，在438，任务服务410可以调用由业务方提供的查询服务420。在440，查询服务420可以确定与对应于该任务的时间窗相关联的一组尚未完成的订单。56.在一些实施例中，在440a，查询服务420可以利用本地数据备份425来查询订单的状态，从而确定一组尚未完成的订单。57.备选地，在440b，查询服务420也可以利用业务方的源数据库430(也即，订单数据库)来查询订单那的状态，从而确定一组尚未完成的订单。应当理解，由于本地数据备份425是源数据库430的异构镜像，其数据实时性通常弱于源数据库430。然而，得益于这样的本地数据备份425可以被部署在补单方本地，这可以有效地降低业务方的数据库访问压力。58.进一步地，查询服务420可以向任务服务410返回查询结果。例如，查询服务420可以返回该时间窗内的全部订单都已经完成执行的查询结果。或者，查询服务420也可以返回指示该时间窗内尚未完成的一组订单的查询结果。59.进一步地，在444，任务服务410可以根据订单状态信息来执行动作。具体地，如果查询服务420是根据源数据库430返回了该时间窗的全部订单都已经完成的查询结果，则任务服务410可以不创建该任务。60.备选地，如果查询服务420是根据本地数据备份425或源数据库430返回了指示尚未完成的一组订单的查询结果，则任务服务410可以根据该查询结果创建与该组订单对应的任务。61.备选地，如果查询服务420是根据本地数据备份425返回了该时间窗的全部订单都已经完成的查询结果，则任务服务410可以继续执行如图4所示的446至454的过程。62.具体地，在446，任务服务410可以向查询服务420发起二次验证的请求。进一步地，查询服务420可以查询源数据库430，以核验该时间窗的全部订单是否已经全部完成。63.在450，源数据库430可以返回验证结果，并在452由查询服务将验证结果返回至任务服务410。进一步地，在454，任务服务410可以根据该验证结果来执行对应的动作。具体地，如果验证结果指示该时间窗内的全部订单已经完成执行，则任务服务410可以不创建任务。相反，如果验证结果指示该时间窗内的一组订单尚未完成执行，则任务服务410可以创建与该组订单的任务。64.基于在任务创建阶段的二次验证的过程，本公开的实施例能够提高任务创建的可靠性。65.在一些实施例中，生产者模块例如还可以执行任务的完备性校验。66.具体地，生产者模块可以获取与历史时间窗相关联的一组历史任务的消费状态，其中该历史时间窗的长度大于正常生成任务的目标时间窗。例如，生产者模块可以校验过去48校内的任务序列，并确定是否有任务尚未被消费(或缺失)。67.示例性地，生成者模块可以根据任务的标识连续性，或者任务所对应的时间窗的连续性来校验任务序列是否完备，从而确定未被消费的目标历史任务。68.进一步地，生产者模块可以利用与任务创建类的过程(例如，参考图4中的440)来确定与该任务对应的历史事件窗内的订单是否被完成。在存在未完成订单的情况下，生产者模块可以创建于未完成的该组订单对应的新的任务，并提供至消费者模块以用于执行。69.基于这样的方式，本公开的实施例可以进一步提高任务列表的完备性，避免遗漏任务的发生。70.示例消费者模块71.以下将参考图5来描述消费者模块的示例处理过程。图5示出了根据本公开的一些实施例的消费者模块的处理过程500的示意图。72.如图5所示，消费者模块可以包括如上文介绍的任务服务410和任务数据库415等。此外，与生产者模块不同的是，消费者模块利用的是业务方提供的执行服务510，而非查询服务420。73.具体地，如图5所示，在512，触发器505(也称为执行触发器505，其可以与任务触发器405相同或不同)可以触发任务服务410。在514，任务服务410可以查询任务数据库415，以记载一定时间段内尚未执行成功的一个或多个任务。74.为了方便描述，下文将以单个任务为例来介绍消费者模块的执行。进一步地，在516，任务服务410可以调用由业务方提供的执行服务510，以推进与该任务对应的一组尚未完成订单的执行。75.在518，执行服务510可以获取该组订单的详细信息。具体地，任务服务可以在518a从本地数据备份425获取订单详细信息。或者，执行服务510还可以从源数据库430获取订单详细信息。76.进一步地，在520，执行服务510可以调用业务方提供的下游接口并根据订单详细信息来推进订单被执行。在522，如果订单状态存在更新，则执行服务522可以更新源数据库430。备选地，这样的更新信息还可以根据预设的同步逻辑而被同步至本地数据备份425。77.在524，执行服务510可以向任务服务410返回任务执行结果。在526，任务服务410可以根据执行结果，并参考如图3所示的状态机来执行对应的动作。78.示例性地，如果执行结果指示该任务对应的订单尚未全部推进到终态，则任务服务410例如可以根据图3所示的状态机来控制任务的重新执行，直至该任务进行到成功态350、失败态360或过期态370。79.在一些实施例中，如果该指示结果指示该任务对应的该组订单全部推进到终态，则在528，任务服务410可以调用执行服务510，以执行二次验证。80.在530，执行服务510可以查询源数据库430，以验证与该任务对应的全部订单是否均已经执行完成。在532，源数据库430可以向执行服务510返回验证结果。81.进一步地，执行服务510可以向任务服务410发送该验证结果。在536，任务服务410可以根据验证结果来执行对应的动作。具体地，如果该验证结果指示全部订单已经完成执行，则任务服务410可以将该任务标记为成功态350。82.相反，如果该验证结果指示存在尚未完成执行的订单，则任务服务410可以将任务重新置为初始态310，从而重新执行该任务。附加地，该任务服务410例如还可以生成告警信息，以指示业务方的源数据库430与执行服务510所返回的状态不匹配。83.基于以上所讨论的任务消费过程，本公开的实施例能够通过消费者模块有效地控制订单补单的过程，提高订单补单的效率和可靠性。84.示例补单系统85.图6进一步示出了根据本公开的一些实施例的示例补单系统600的框图。如图6所示，补单系统600可以包括与补单方和业务方对应的不同模块或组件。86.在一些实施例中，对于补单方而言，补单系统600例如可以包括多个触发器，例如，任务触发器405、执行触发器505和检查触发器605等。任务触发器405可以被配置为定期地触发任务的生成，执行触发器505可以被配置为定期地触发任务的消费，检查触发器605可以被配置为定期地触发任务完备性的检查。87.在一些实施例中，这样的触发器可以被设计为仅处理任务触发的逻辑，本身不做额外的任务逻辑。附加地，这样的触发器内可以不使用任何的缓存。由此，可以实现触发器的轻量化设计，从而保证触发器的稳定性和执行效率。88.在一些实施例中，可以使用优选faas(事件即服务)来实施触发器。备选地，还可以cronjob作为灾备触发器，从而进一步提高系统的稳定性。89.进一步地，如图6所示，任务服务410可以根据任务触发器405的触发来执行任务创建，根据检查触发器605的触发来执行任务完备性检查，根据执行触发器505的触发来执行任务消费。相应地，这样的任务服务410例如可以仅依赖于本地的任务数据库415。90.附加地，对于任务创建和任务完备性检查，任务服务410还可以调用由业务方提供的查询服务420，以根据本地数据库425或源数据库430来确定尚未完成的订单。91.对于任务消费来说，任务服务410可以调用由业务方提供的执行服务510，以利用本地数据库425或源数据库430查询订单信息、调用下游接口610促进订单的执行，和/或更新源数据库430中的订单状态。92.基于这样的方式，本公开的实施例能够降低补单过程对于业务方的依赖性，其例如可以仅提供两个接口：即查询接口和执行接口。由此，可以提高补单系统的灵活性，为不同业务方的介入提供支持。93.示例过程94.图7示出了根据本公开的一些实施例的用于处理订单的示例过程700的流程图。过程700可以由图1所示的补单设备210来执行，以下参考图1来描述过程700。95.如图7所示，在框710，补单设备210确定与目标时间窗相关联的一组订单，一组订单尚未完成。96.在框720，补单设备210向与一组订单相关联的业务方请求一组订单被执行。97.在框730，补单设备210响应于从业务方接收到指示一组订单完成的消息，查询由业务方维护的订单数据库，以验证一组订单是否完成。98.在框740，补单设备210响应于一组订单被验证为完成，更新一组订单的状态以指示订单完成。99.在一些实施例中，确定与目标时间窗相关联的一组订单包括：基于预设的时间周期，确定目标时间窗；以及获取与目标时间窗相关联的一组订单。100.在一些实施例中，确定与目标时间窗相关联的一组订单：查询业务方维护的订单数据，以确定指示一组订单是否完成的第一查询结果；以及基于第一查询结果，从一组订单中确定尚未完成的一组订单。101.在一些实施例中，确定与目标时间窗相关联的一组订单包括：查询部署在补单方本地的、与订单数据库对应的订单数据副本，以确定指示一组订单是否完成的第二查询结果；以及基于第二查询结果，确定尚未完成的一组订单。102.在一些实施例中，基于第二查询结果从一组订单中确定尚未完成的一组订单包括：响应于第二查询结果指示与目标时间窗相关联的全部订单都已完成，查询业务方维护的订单数据，以确定指示全部订单是否完成的第三查询结果；以及基于第三查询结果，确定尚未完成的一组订单。103.在一些实施例中，向与一组订单相关联的业务方请求一组订单被执行包括：由生产者模块生成与一组相关联的第一任务；以及由消费者模块根据第一任务，向业务方请求一组订单被执行。104.在一些实施例中，一组订单为第一组订单，过程700还包括：由生产者模块获取与历史时间窗相关联的一组历史任务的消费状态，历史时间窗的长度大于目标时间窗；由生产者模块从一组历史任务中确定未被消费的目标历史任务；由生产者模块确定与目标历史任务相关联的第二组订单，第二组订单尚未完成；以及由生产者模块生成与第二组订单相关联的第二任务，以使得消费者模块根据第二任务，向业务方请求第二组订单被执行。105.在一些实施例中，过程700还包括：生成与一组订单相关联的任务；迭代地执行以下至少一次：响应于确定任务执行失败或执行超时，重新执行任务，以向业务方重新请求一组订单被执行；以及响应于任务重新执行的次数超过阈值数目或与任务已经过期，将任务标记为未成功。106.在一些实施例中，重新执行任务包括：确定用于重新执行的时间间隔；响应于任务非首次重新请求执行，根据上次重新执行的历史时刻和时间间隔，确定目标时刻；以及在目标时刻，重新执行任务。107.在一些实施例中，确定用于重新请求的时间间隔包括：确定任务已经被重新执行的次数；以及基于次数，确定时间间隔，使得时间间隔正相关于次数。108.在一些实施例中，过程700还包括：维护与任务的重新执行相关联的执行信息，执行信息指示以下至少一项：一组订单的订单信息，关于重新执行的执行描述信息，关于任务执行失败或执行超时的原因描述信息。109.在一些实施例中，过程700还包括：提供执行信息，以用于分析任务。110.在一些实施例中，过程700还包括：响应于一组订单被验证为未完成，向业务方重新请求一组订单被执行。111.在一些实施例中，业务方提供用于查询订单数据库的查询接口，以及用于请求订单被执行的执行接口。112.示例装置和设备113.本公开的实施例还提供了用于实现上述方法或过程的相应装置。图8示出了根据本公开的一些实施例的用于处理订单的装置800的示意性结构框图。114.如图8所示，装置800包括确定模块810，被配置为确定与目标时间窗相关联的一组订单，一组订单尚未完成。115.装置800还包括请求模块820，被配置为向与一组订单相关联的业务方请求一组订单被执行。116.装置800还包括验证模块830，被配置为响应于从业务方接收到指示一组订单完成的消息，查询由业务方维护的订单数据库，以验证一组订单是否完成。117.此外，装置800还包括更新模块840，被配置为响应于一组订单被验证为完成，更新一组订单的状态以指示订单完成。118.在一些实施例中，确定模块810还被配置为：基于预设的时间周期，确定目标时间窗；以及获取与目标时间窗相关联的一组订单。119.在一些实施例中，确定模块810还被配置为：查询业务方维护的订单数据，以确定指示一组订单是否完成的第一查询结果；以及基于第一查询结果，从一组订单中确定尚未完成的一组订单。120.在一些实施例中，确定模块810还被配置为：查询部署在补单方本地的、与订单数据库对应的订单数据副本，以确定指示一组订单是否完成的第二查询结果；以及基于第二查询结果，确定尚未完成的一组订单。121.在一些实施例中，确定模块810还被配置为：响应于第二查询结果指示与目标时间窗相关联的全部订单都已完成，查询业务方维护的订单数据，以确定指示全部订单是否完成的第三查询结果；以及基于第三查询结果，确定尚未完成的一组订单。122.在一些实施例中，请求模块820还被配置为：由生产者模块生成与一组相关联的第一任务；以及由消费者模块根据第一任务，向业务方请求一组订单被执行。123.在一些实施例中，一组订单为第一组订单，请求模块820还被配置为：由生产者模块获取与历史时间窗相关联的一组历史任务的消费状态，历史时间窗的长度大于目标时间窗；由生产者模块从一组历史任务中确定未被消费的目标历史任务；由生产者模块确定与目标历史任务相关联的第二组订单，第二组订单尚未完成；以及由生产者模块生成与第二组订单相关联的第二任务，以使得消费者模块根据第二任务，向业务方请求第二组订单被执行。124.在一些实施例中，请求模块820还被配置为：生成与一组订单相关联的任务；迭代地执行以下至少一次：响应于确定任务执行失败或执行超时，重新执行任务，以向业务方重新请求一组订单被执行；以及响应于任务重新执行的次数超过阈值数目或与任务已经过期，将任务标记为未成功。125.在一些实施例中，请求模块820还被配置为：确定用于重新执行的时间间隔；响应于任务非首次重新请求执行，根据上次重新执行的历史时刻和时间间隔，确定目标时刻；以及在目标时刻，重新执行任务。126.在一些实施例中，请求模块820还被配置为：确定任务已经被重新执行的次数；以及基于次数，确定时间间隔，使得时间间隔正相关于次数。127.在一些实施例中，装置800还被配置为：维护与任务的重新执行相关联的执行信息，执行信息指示以下至少一项：一组订单的订单信息，关于重新执行的执行描述信息，关于任务执行失败或执行超时的原因描述信息。128.在一些实施例中，装置800还被配置为：提供执行信息，以用于分析任务。129.在一些实施例中，请求模块820还被配置为：响应于一组订单被验证为未完成，向业务方重新请求一组订单被执行。130.在一些实施例中，业务方提供用于查询订单数据库的查询接口，以及用于请求订单被执行的执行接口。131.装置800中所包括的单元可以利用各种方式来实现，包括软件、硬件、固件或其任意组合。在一些实施例中，一个或多个单元可以使用软件和/或固件来实现，例如存储在存储介质上的机器可执行指令。除了机器可执行指令之外或者作为替代，装置800中的部分或者全部单元可以至少部分地由一个或多个硬件逻辑组件来实现。作为示例而非限制，可以使用的示范类型的硬件逻辑组件包括现场可编程门阵列(fpga)、专用集成电路(asic)、专用标准品(assp)、片上系统(soc)、复杂可编程逻辑器件(cpld)，等等。132.图9示出了其中可以实施本公开的一个或多个实施例的计算设备/服务器900的框图。应当理解，图9所示出的计算设备/服务器900仅仅是示例性的，而不应当构成对本文所描述的实施例的功能和范围的任何限制。133.如图9所示，计算设备/服务器900是通用计算设备的形式。计算设备/服务器900的组件可以包括但不限于一个或多个处理器或处理单元910、存储器920、存储设备930、一个或多个通信单元940、一个或多个输入设备960以及一个或多个输出设备960。处理单元910可以是实际或虚拟处理器并且能够根据存储器920中存储的程序来执行各种处理。在多处理器系统中，多个处理单元并行执行计算机可执行指令，以提高计算设备/服务器900的并行处理能力。134.计算设备/服务器900通常包括多个计算机存储介质。这样的介质可以是计算设备/服务器900可访问的任何可以获得的介质，包括但不限于易失性和非易失性介质、可拆卸和不可拆卸介质。存储器920可以是易失性存储器(例如寄存器、高速缓存、随机访问存储器(ram))、非易失性存储器(例如，只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、闪存)或它们的某种组合。存储设备930可以是可拆卸或不可拆卸的介质，并且可以包括机器可读介质，诸如闪存驱动、磁盘或者任何其他介质，其可以能够用于存储信息和/或数据(例如用于训练的训练数据)并且可以在计算设备/服务器900内被访问。135.计算设备/服务器900可以进一步包括另外的可拆卸/不可拆卸、易失性/非易失性存储介质。尽管未在图9中示出，可以提供用于从可拆卸、非易失性磁盘(例如“软盘”)进行读取或写入的磁盘驱动和用于从可拆卸、非易失性光盘进行读取或写入的光盘驱动。在这些情况中，每个驱动可以由一个或多个数据介质接口被连接至总线(未示出)。存储器920可以包括计算机程序产品925，其具有一个或多个程序模块，这些程序模块被配置为执行本公开的各种实施例的各种方法或动作。136.通信单元940实现通过通信介质与其他计算设备进行通信。附加地，计算设备/服务器900的组件的功能可以以单个计算集群或多个计算机器来实现，这些计算机器能够通过通信连接进行通信。因此，计算设备/服务器900可以使用与一个或多个其他服务器、网络个人计算机(pc)或者另一个网络节点的逻辑连接来在联网环境中进行操作。137.输入设备950可以是一个或多个输入设备，例如鼠标、键盘、追踪球等。输出设备960可以是一个或多个输出设备，例如显示器、扬声器、打印机等。计算设备/服务器900还可以根据需要通过通信单元940与一个或多个外部设备(未示出)进行通信，外部设备诸如存储设备、显示设备等，与一个或多个使得用户与计算设备/服务器900交互的设备进行通信，或者与使得计算设备/服务器900与一个或多个其他计算设备通信的任何设备(例如，网卡、调制解调器等)进行通信。这样的通信可以经由输入/输出(i/o)接口(未示出)来执行。138.根据本公开的示例性实现方式，提供了一种计算机可读存储介质，其上存储有一条或多条计算机指令，其中一条或多条计算机指令被处理器执行以实现上文描述的方法。139.这里参照根据本公开实现的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本公开的各个方面。应当理解，流程图和/或框图的每个方框以及流程图和/或框图中各方框的组合，都可以由计算机可读程序指令实现。140.这些计算机可读程序指令可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理单元，从而生产出一种机器，使得这些指令在通过计算机或其他可编程数据处理装置的处理单元执行时，产生了实现流程图和/或框图中的一个或多个方框中规定的功能/动作的装置。也可以把这些计算机可读程序指令存储在计算机可读存储介质中，这些指令使得计算机、可编程数据处理装置和/或其他设备以特定方式工作，从而，存储有指令的计算机可读介质则包括一个制造品，其包括实现流程图和/或框图中的一个或多个方框中规定的功能/动作的各个方面的指令。141.也可以把计算机可读程序指令加载到计算机、其他可编程数据处理装置、或其他设备上，使得在计算机、其他可编程数据处理装置或其他设备上执行一系列操作步骤，以产生计算机实现的过程，从而使得在计算机、其他可编程数据处理装置、或其他设备上执行的指令实现流程图和/或框图中的一个或多个方框中规定的功能/动作。142.附图中的流程图和框图显示了根据本公开的多个实现的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或指令的一部分，模块、程序段或指令的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。143.以上已经描述了本公开的各实现，上述说明是示例性的，并非穷尽性的，并且也不限于所公开的各实现。在不偏离所说明的各实现的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择，旨在最好地解释各实现的原理、实际应用或对市场中的技术的改进，或者使本技术领域的其他普通技术人员能理解本文公开的各实现。









图片声明：本站部分配图来自人工智能系统AI生成,觅知网授权图片,PxHere摄影无版权图库。本站只作为美观性配图使用,无任何非法侵犯第三方意图,一切解释权归图片著作权方,本站不承担任何责任。如有恶意碰瓷者,必当奉陪到底严惩不贷!




内容声明：本文中引用的各种信息及资料（包括但不限于文字、数据、图表及超链接等）均来源于该信息及资料的相关主体（包括但不限于公司、媒体、协会等机构）的官方网站或公开发表的信息。部分内容参考包括:(百度百科,百度知道,头条百科,中国民法典,刑法,牛津词典,新华词典,汉语词典,国家院校,科普平台)等数据,内容仅供参考使用,不准确地方联系删除处理！本站为非盈利性质站点,发布内容不收取任何费用也不接任何广告!




免责声明：我们致力于保护作者版权，注重分享，被刊用文章因无法核实真实出处，未能及时与作者取得联系，或有版权异议的，请联系管理员，我们会立即处理，本文部分文字与图片资源来自于网络，部分文章是来自自研大数据AI进行生成,内容摘自(百度百科,百度知道,头条百科,中国民法典,刑法,牛津词典,新华词典,汉语词典,国家院校,科普平台)等数据,内容仅供学习参考,不准确地方联系删除处理!的,若有来源标注错误或侵犯了您的合法权益，请立即通知我们，情况属实，我们会第一时间予以删除，并同时向您表示歉意,谢谢!