订单状态的维护系统的制作方法

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.和/或，所述超时事件记录有相应用户订单待切换的指定订单状态。
30.可选的，还包括：
31.响应于所述应用服务端发送的针对超时事件的失效指令，删除相应的超时事件；
32.其中，所述失效指令由所述应用服务端在响应于所述应用客户端针对用户订单的订单操作以将所述用户订单切换至与所述订单操作对应的订单状态，且所切换的订单状态
为指定订单状态的情况下发送；或者，所述失效指令由所述应用服务端在用户订单对应的超时事件触发，且确定出所述用户订单的当前订单状态已切换至指定订单状态的情况下发送。
33.可选的，所述方法应用于超时调度服务端，所述超时调度服务端包括超时中心、数据库服务器和调度器；
34.其中，超时中心用于接收并注册所述应用服务端发送的超时事件，并将所述超时事件存储至数据库服务器，以及，在接收到调度器发送的超时触发消息的情况下，向所述数据库服务器读取相应的超时事件；数据库服务器用于存储所述超时中心注册的超时事件；调度器用于读取所述数据库服务器存储的超时事件，并确定读取到的超时事件是否触发，以在读取到的超时事件触发的情况下向所述超时中心发送针对超时事件的超时触发消息。
35.可选的，所述超时事件记录有超时触发条件，所述超时触发条件用于判断所述超时事件是否触发；
36.和/或，所述超时事件记录有相应用户订单待切换的指定订单状态。
37.可选的，还包括：
38.响应于所述应用服务端发送的针对超时事件的失效指令，删除相应的超时事件；
39.其中，所述失效指令由所述应用服务端在响应于所述应用客户端针对用户订单的订单操作以将所述用户订单切换至与所述订单操作对应的订单状态，且所切换的订单状态为指定订单状态的情况下发送；或者，所述失效指令由所述应用服务端在用户订单对应的超时事件触发，且确定出所述用户订单的当前订单状态已切换至指定订单状态的情况下发送。
40.可选的，所述方法应用于超时调度服务端，所述超时调度服务端包括超时中心、数据库服务器和调度器；
41.其中，超时中心用于接收并注册所述应用服务端发送的超时事件，并将所述超时事件存储至数据库服务器，以及，在接收到调度器发送的超时触发消息的情况下，向所述数据库服务器读取相应的超时事件；数据库服务器用于存储所述超时中心注册的超时事件；调度器用于读取所述数据库服务器存储的超时事件，并确定读取到的超时事件是否触发，以在读取到的超时事件触发的情况下向所述超时中心发送针对超时事件的超时触发消息。
42.根据本说明书一个或多个实施例的第四方面，提出了一种订单状态的维护装置，包括：
43.创建单元，响应于应用客户端发起的订单请求，创建相应的用户订单，并生成与所述用户订单对应的超时事件，向超时调度服务端发送所述超时事件，以由所述超时调度服务端保存所述超时事件，并确定所述超时事件是否触发；
44.接收单元，接收所述超时调度服务端在所述超时事件触发的情况下返回的所述超时事件定义的回调信息；
45.回调单元，若确定出所述用户订单的当前订单状态未切换至指定订单状态，则根据所述超时事件定义的回调信息对所述用户订单的当前订单状态执行回调操作。
46.可选的，所述创建单元具体用于：向所述订单请求指示的订单相关方发送获取请求，以指示所述订单相关方返回相应的订单参数，并基于所述订单参数创建相应的用户订单；
47.所述创建单元具体用于：接收所述订单相关方返回的事件配置信息，基于所述事件配置信息生成与所述用户订单对应的超时事件。
48.可选的，所述超时事件记录有超时触发条件，所述超时触发条件用于判断所述超时事件是否触发；
49.和/或，所述超时事件记录有相应用户订单待切换的指定订单状态。
50.可选的，所述回调单元还用于：响应于所述应用客户端针对所述用户订单的订单操作，将所述用户订单切换至与所述订单操作对应的订单状态，若所切换的订单状态为指定订单状态，则向所述超时调度服务端发送事件失效指令，以指示所述超时调度服务端删除所述用户订单对应的超时事件；
51.或者，在用户订单对应的超时事件触发的情况下，若确定出所述用户订单的当前订单状态已切换至指定订单状态，则向所述超时调度服务端发送事件失效指令，以指示所述超时调度服务端删除所述用户订单对应的超时事件。
52.可选的，用户订单包括以下至少之一：
53.支付订单、交易订单、配送订单、预约订单。
54.根据本说明书一个或多个实施例的第五方面，提出了一种订单状态的维护装置，包括：
55.接收单元，接收应用服务端发送的与用户订单对应的超时事件，所述超时事件由所述应用服务端响应于应用客户端发起的订单请求而创建得到；
56.保存单元，保存所述超时事件，并确定所述超时事件是否触发，并在所述超时事件触发的情况下返回所述超时事件定义的回调信息，所述回调信息用于指示所述应用服务端在确定出所述用户订单的当前订单状态未切换至指定订单状态的情况下，根据所述超时事件定义的回调信息对所述用户订单的当前订单状态执行回调操作。
57.可选的，所述超时事件记录有超时触发条件，所述超时触发条件用于判断所述超时事件是否触发；
58.和/或，所述超时事件记录有相应用户订单待切换的指定订单状态。
59.可选的，所述保存单元具体用于：
60.响应于所述应用服务端发送的针对超时事件的失效指令，删除相应的超时事件；
61.其中，所述失效指令由所述应用服务端在响应于所述应用客户端针对用户订单的订单操作以将所述用户订单切换至与所述订单操作对应的订单状态，且所切换的订单状态为指定订单状态的情况下发送；或者，所述失效指令由所述应用服务端在用户订单对应的超时事件触发，且确定出所述用户订单的当前订单状态已切换至指定订单状态的情况下发送。
62.可选的，所述方法应用于超时调度服务端，所述超时调度服务端包括超时中心、数据库服务器和调度器；
63.其中，超时中心用于接收并注册所述应用服务端发送的超时事件，并将所述超时事件存储至数据库服务器，以及，在接收到调度器发送的超时触发消息的情况下，向所述数据库服务器读取相应的超时事件；数据库服务器用于存储所述超时中心注册的超时事件；调度器用于读取所述数据库服务器存储的超时事件，并确定读取到的超时事件是否触发，以在读取到的超时事件触发的情况下向所述超时中心发送针对超时事件的超时触发消息。
64.根据本说明书一个或多个实施例的第六方面，提出了一种电子设备，包括：
65.处理器；
66.用于存储处理器可执行指令的存储器；
67.其中，所述处理器通过运行所述可执行指令以实现如上述任一实施例中所述的方法。
68.根据本说明书一个或多个实施例的第七方面，提供一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现如上述实施例中任一所述方法的步骤。
69.本说明书提供一种订单状态的维护系统，其中的应用服务端针对用户订单创建生成对应的超时事件，并且将超时事件交由超时调度服务端进行管理。超时调度服务端在超时事件触发的情况下返回超时事件定义的回调信息至应用服务端，使其根据回调信息对订单状态进行回调。由本说明书的技术方案可见，本说明书针对各个订单分别生成对应的超时事件并且提供超时调度服务端用于专门管理超时事件，方便针对各个用户订单状态进行分别管理，相比于统一管理多个订单的做法，可以更加及时的监控订单状态的变化并在需要时及时推动用户订单走向终态。并且，超时事件定义的回调信息指示应用服务端对订单状态进行回调，也使得应用服务端可以不依赖于外部的操作，仅根据回调信息的指示对用户订单进行回调，在订单状态管理过程中提升灵活性以及自主性，达到对订单状态的动态管理。
附图说明
70.图1是是一示例性实施例提供的一种订单状态的维护系统的系统架构示意图。
71.图2是一示例性实施例提供的一种订单状态的维护方法的流程图。
72.图3是一示例性实施例提供的另一种订单状态的维护方法的流程图。
73.图4是一示例性实施例提供的一种订单状态的维护方法的多方交互图。
74.图5是一示例性实施例提供的一种设备的示意结构图。
75.图6是一示例性实施例提供的一种订单状态维护装置的框图。
76.图7是一示例性实施例提供的另一种订单状态维护装置的框图。
具体实施方式
77.这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。
78.需要说明的是：在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中，其方法所包括的步骤可以比本说明书所描述的更多或更少。此外，本说明书中所描述的单个步骤，在其他实施例中可能被分解为多个步骤进行描述；而本说明书中所描述的多个步骤，在其他实施例中也可能被合并为单个步骤进行描述。
79.本说明书提供的订单状态维护方案对相关技术中的订单状态维护方法予以了改
进，以解决相关技术中存在的上述技术问题。下面结合图1-图7对本说明书的订单状态维护方案进行详细说明。
80.如上所述，线上交易中，对订单生命周期的管理，尤其是保证不同类型的订单均能到达终态，对用户和系统来说都极其重要。举例而言，用户下单后，订单的状态可以由交易管理方通过状态机维护，例如订单的付款状态、配货状态、物流状态、售后状态等等。订单状态需要及时更新，尤其针对非正常结束的订单，更需要及时对订单的状态加以更新。
81.以用户未支付而导致订单关闭为例，如果用户超出付款时间仍未付款，即超出了支付工具的支付有效期仍未完成付款操作，那么交易管理方需要及时关闭订单，使得订单状态走向终态。一方面，如果并未及时更新订单状态，对于用户而言，经过一段时间后再重新进行支付，可能会出现满减券过期(满减券过期也可以概括为优惠资格过期；在具体实现时，券的类型可以包括：商家券、平台券、全场满减券、限品类券等，均有时效性要求；以银行类补贴的活动为例，此类活动的名额通常有限，如果用户不及时支付，那么交易管理方也应该关闭相应的订单以释放其所占用的银行补贴资格，及时给其他用户使用)、资产变化等情况而导致订单无法继续进行；或者，如果不做针对订单状态的超时管理，对于用户当前所购的商品，在后续支付的时候，还可能会出现商品已下架或无库存的情况，影响用户正常的下单过程。另一方面，对于交易管理方而言，对于未能正常走向终态的订单，无法正常进行归档，为管理、统计等工作增加难度。具体而言，一般为了性能考虑，从交易管理方的角度出发，会使服务端缓存一定时间段内的用户热点数据，如果用户下单完及时支付，所有的数据都在缓存时效内，这时候可以直接从缓存获取数据，提高系统响应性能；如果用户经过较长的时间间隔后再支付，所有缓存的热点数据可能都已过期，需要再次从数据库中查询，增加对传输资源的消耗、影响系统响应性能。当然，上述订单的终态可以包含订单完成、订单关闭、订单删除等订单状态。在本说明书中，将使用户订单走向终态的操作称为订单回调操作。
82.在各种线上交易中，所有的交易信息、支付信息、履约信息等都需要订单来承载，而不同的订单类型，均有其各自的生命周期。在传统的订单生命周期管理中，对于非正常结束的订单，推进到终态常见的方式是依赖外部业务系统(也称订单相关方)来推进订单状态。举例而言，在线上交易中，用户通过应用客户端进行下单操作，应用服务端创建相应的订单，并且由应用客户端将订单信息发送至其他外部业务系统(例如支付系统、物流系统、配货系统等)进行相应的后续操作。以支付步骤为例，如果用户超时未支付，订单本应该结束，但是在此种方式中，需要由支付系统主动推进应用服务端结束此订单，应用客户端无法自主对订单进行回调操作。并且，由于应用服务端可以对接多个外部业务系统，在实际应用中，难以约束各个外部业务系统均主动推进订单进行回调，换言之，此种方式下，应用服务端无法对所有的外部业务系统做出强制要求，无法与各个外部业务系统做到解耦，导致部分订单难以及时走向终态，不利于及时管理订单状态。另外，即使外部业务系统能够及时主动推进回调订单状态，此种方式也会增加外部业务系统和应用服务端的交互次数，占用两者之间的传输资源。
83.另外，相关技术中，应用服务端还可以依赖于定时调度系统来推进订单状态。具体而言，定时调度系统设置有其固定的调度周期，此调度周期对于全部订单均适用。定时调度系统每间隔上述统一的固定周期对全部订单的状态进行管理，并将需要回调的订单调整至
相应的终态。在此种方式下，定时调度系统处理的任务都是静态任务，上述调度周期需要手动提前注册，不支持在系统运行过程中动态产生的订单任务，无法做到对各种订单灵活处理。并且，由于周期的固定性较强，导致在管理过程中的灵活性较差。
84.有鉴于此，本技术提供一种订单状态的维护系统，用以通过在超时中心动态注册超时事件来定制化完结任意一个订单的生命周期。
85.请参见图1，图1是一示例性实施例提供的一种订单状态的维护系统的系统架构示意图。如图1所示，该系统可以包括应用服务端11、超时调度服务端12、至少一个应用客户端(比如手机13-15等)和网络16。
86.其中，应用客户端，响应于用户的下单操作，向应用服务端发起相应的订单请求。手机13-15表示用户可以使用的一种类型的电子设备。实际上，用户显然还可以使用诸如下述类型的电子设备：平板设备、笔记本电脑、掌上电脑(pdas，personal digital assistants)、可穿戴设备(如智能眼镜、智能手表等)等，本说明书一个或多个实施例并不对此进行限制。在运行过程中，该电子设备可以运行某一应用的客户端侧的程序，以实现该应用的相关业务功能。比如，手机13-15可运行交易业务平台的用户侧程序，以实现为交易业务平台的用户方。
87.所述应用服务端，响应于所述应用客户端发起的订单请求，创建相应的用户订单，生成与所述用户订单对应的超时事件，并向超时调度服务端发送所述超时事件；在所述超时事件触发的情况下，若确定出所述用户订单的当前订单状态未切换至指定订单状态，则根据所述超时事件定义的回调信息对所述用户订单的当前订单状态执行回调操作。
88.所述超时调度服务端，接收并保存所述应用服务端发送的超时事件，并确定所述超时事件是否触发，以在所述超时事件触发的情况下向所述应用服务端返回所述超时事件定义的回调信息。
89.可选的，所述超时调度服务端包括：超时中心，接收并注册所述应用服务端发送的超时事件，并将所述超时事件存储至数据库服务器，以及，在接收到调度器发送的超时触发消息的情况下，向所述数据库服务器读取相应的超时事件；数据库服务器，存储所述超时中心注册的超时事件；调度器，读取所述数据库服务器存储的超时事件，并确定读取到的超时事件是否触发，以在读取到的超时事件触发的情况下向所述超时中心发送针对超时事件的超时触发消息。在具体实现时，超时中心、数据服务器、调度器三者之间可以分别独立维护，分散管理，以降低各个部分之间的耦合度，明确三者的分工，同时也可以避免任一部分出现故障时影响到超时调度服务端的整体运行，为后期运维提供便利。
90.其中，应用服务端11以及超时调度服务端12可以为包含一独立主机的物理服务器，或者应用服务端11以及超时调度服务端12可以为主机集群承载的虚拟服务器。在运行过程中，应用服务端11以及超时调度服务端12可以运行某一应用的服务器侧的程序，以作为相应的服务端实现该应用的相关业务功能。比如，应用服务端11以及超时调度服务端12可运行交易业务平台的服务器侧程序，以实现为交易业务平台的服务端。
91.而对于手机13-15与应用服务端11以及超时调度服务端12之间进行交互的网络16，可以包括多种类型的有线或无线网络。比如，网络16可以包括公共交换电话网络(public switched telephone network，pstn)和因特网。其中，手机13-15与应用服务端11以及超时调度服务端12之间可以通过网络16建立长连接，使得应用服务端11以及超时调度
服务端12与手机13-15之间通过该长连接来传输数据。
92.为了描述的方便，下面本说明书将从各个执行主体侧的角度对订单状态的维护方法进行描述。
93.请参见图2，图2是一示例性实施例提供的一种订单状态的维护方法的流程图。如图2所示，该订单状态维护方法应用于应用服务端，可以包括以下步骤：
94.步骤202，响应于应用客户端发起的订单请求，创建相应的用户订单，并生成与所述用户订单对应的超时事件，向超时调度服务端发送所述超时事件，以由所述超时调度服务端保存所述超时事件，并确定所述超时事件是否触发。
95.在一实施例中，应用服务端响应于应用客户端发起的订单请求，开始内部逻辑处理，创建相应的用户订单。上述用户订单包括但不限于支付订单、交易订单、配送订单、预约订单等。以用户在外卖平台进行下单操作为例，用户在通过外卖平台的客户端发起订单，应用服务端接收到上述外卖订单，并可以为此位下单的用户创建相应的交易订单、支付订单、配送订单等。
96.在一实施例中，所述响应于所述应用客户端发起的订单请求，创建相应的用户订单，包括：向所述订单请求指示的订单相关方发送获取请求，以指示所述订单相关方返回相应的订单参数，并基于所述订单参数创建相应的用户订单。具体而言，对于交易订单，应用服务端可以根据用户的下单参数直接创建，但是对于支付订单、配送订单等类型的订单，应用服务端需要依赖于外部业务系统回传的相应参数进行创建。具体而言，应用服务端在创建支付订单时，可以将相应的订单信息发送至外部的支付系统，由支付系统提供相应的支付参数，再根据上述支付参数创建相应的支付订单。配送订单同理，应用服务端可以依赖于物流系统提供的物流参数创建，在此不再赘述。
97.并且，在本说明书中，应用服务端还将为各种类型的用户订单分别创建相应的超时事件，并向超时调度服务端发送所述超时事件，以由所述超时调度服务端保存所述超时事件，确定所述超时事件是否触发。
98.在一实施例中，每笔用户订单对应一个超时事件，所述超时事件记录有超时触发条件，所述超时触发条件用于判断所述超时事件是否触发。举例而言，上述超时触发条件可以为订单对应的超时时间阈值，当达到此超时时间阈值时，超时事件被触发。以支付场景为例，上述超时时间阈值可以表现为支付时间，如果用户未在支付时间内完成支付操作，那么超时事件将会被触发。和/或，所述超时事件还可以记录有相应用户订单待切换的指定订单状态，上述指定订单状态即回调操作所指向的订单终态。举例而言，订单回调操作的目的是推向订单走向终态，而订单终态可以包含订单结束、订单关闭、订单删除等多个订单状态，上述指定订单状态表达了回调操作将订单更改为的最终状态，并且，上述指定订单状态可以记录于超时事件中。
99.在具体实现时，超时事件还可以包含订单单据id、超时后需要执行的回调操作类型、回调服务的入口(回调服务的ip地址、回调服务的版本号、回调服务的服务名称等)、此订单对应的超时时间阈值(触发条件)、此订单的来源(即此订单对应的应用服务端的id、应用服务端对应的平台名称等)。本说明书对超时事件包含的内容参数仅做示意性举例，在实际应用中，超时事件的内容参数可以根据需要进行灵活调整。
100.在一实施例中，所述生成与所述用户订单对应的超时事件，包括：接收所述订单相
关方返回的事件配置信息，基于所述事件配置信息生成与所述用户订单对应的超时事件。如上所述，超时事件可以包含多种类的内容参数，那么，从超时事件配置的角度，本说明书也提供多种配置的方式。具体而言，外部业务系统(即订单相关方)除了返回订单相关参数，还可以返回其个性化定制的事件配置信息，以供应用服务端基于事件配置信息生成与用户订单对应的超时事件。本说明书对外部业务系统返回事件配置信息的时机不进行限制，外部业务系统既可以在返回订单相关参数的同时返回事件配置信息至应用服务端，以节省传输次数，也可以在返回订单相关参数之前或者之后返回事件配置信息。
101.进一步的，针对用户订单，应用服务端也可以维护有默认的事件配置信息，应用服务端维护的默认事件配置信息可以根据订单的类型存在差异。当外部业务系统并未返回其定制的事件配置信息或者返回的事件配置信息不可用的情况下，应用服务端可以采用默认的事件配置信息作为此订单的事件配置信息以生成超时事件。如果外部业务系统已经返回了可用的事件配置信息，那么外部业务系统返回的事件配置信息的优先级可以高于应用服务端维护的默认事件配置信息，以保证超时事件按照外部业务系统个性化需求而生成。
102.步骤204，接收所述超时调度服务端在所述超时事件触发的情况下返回的所述超时事件定义的回调信息。
103.步骤206，若确定出所述用户订单的当前订单状态未切换至指定订单状态，则根据所述超时事件定义的回调信息对所述用户订单的当前订单状态执行回调操作。
104.在一实施例中，超时调度服务端在超时事件触发时，将相应订单的回调信息返回至应用服务端，应用服务端确定当前订单是否被切换至指定订单状态，如果没有，那么说明此订单尚未正常走向终态，那么，应用服务端则需要根据上述回调信息中记录的指定订单状态针对此订单执行回调操作。
105.在一实施例中，应用服务端还可以响应于所述应用客户端针对所述用户订单的订单操作，将所述用户订单切换至与所述订单操作对应的订单状态，若所切换的订单状态为指定订单状态，则向所述超时调度服务端发送事件失效指令，以指示所述超时调度服务端删除所述用户订单对应的超时事件。具体而言，如果用户在超时事件被触发之前就通过应用客户端的订单操作将用户订单切换至指定订单状态，即，上述订单操作在超时事件触发之前就将订单推向了指定的订单终态，那么此订单就不必依赖于超时事件的触发再被回调至指定订单状态。在此种情况下，不再需要触发超时事件，应用服务端可以向超时调度服务端发送事件失效指令，使得超时调度服务端删除上述用户订单对应的超时事件。一方面可以释放超时调度服务端的存储资源，另一方面也可以减轻超时调度服务端的管理压力。
106.在另一实施例中，应用服务端也可以不进行删除超时事件的操作。在此种情况下，无论用户是否通过订单操作将相应订单切换至指定订单状态，超时事件均会被触发。在用户订单对应的超时事件触发的情况下，应用服务端若确定出所述用户订单的当前订单状态已切换至指定订单状态，则向超时调度服务端发送事件失效指令，以指示所述超时调度服务端删除所述用户订单对应的超时事件。在此种方式中，应用服务端无需对订单状态进行实时监控，只需要在超时事件触发后判断订单状态是否被切换至指定订单状态即可，减轻了应用服务端的管理压力。
107.在具体实现时，可以根据实际情况切换上述两种方式，本技术对此不进行限制。
108.由上述技术方案可知，本说明书中的应用服务端针对用户订单创建生成对应的超
时事件，并且将超时事件交由超时调度服务端进行管理。超时调度服务端在超时事件触发的情况下返回超时事件定义的回调信息至应用服务端，使其根据回调信息对订单状态进行回调。本说明书针对各个订单分别生成对应的超时事件并且提供超时调度服务端用于专门管理超时事件，方便针对各个用户订单状态进行分别管理，相比于统一管理多个订单的做法，可以更加及时的监控订单状态的变化并在需要时及时推动用户订单走向终态。并且，超时事件定义的回调信息指示应用服务端对订单状态进行回调，也使得应用服务端可以不依赖于外部的操作，仅根据回调信息的指示对用户订单进行回调，在订单状态管理过程中提升灵活性以及自主性，达到对订单状态的动态管理。此外，本技术中的回调信息可以由外部业务系统个性化配置，提升了对配置超时事件的灵活性，相比于静态配置的方式，本说明书的技术方案实现了对订单状态的动态、个性化管理。
109.请参见图3，图3是一示例性实施例提供的另一种订单状态的维护方法的流程图。如图3所示，该订单状态维护方法应用于超时调度服务端，可以包括以下步骤：
110.步骤302，接收应用服务端发送的与用户订单对应的超时事件，所述超时事件由所述应用服务端响应于应用客户端发起的订单请求而创建得到。
111.步骤304，保存所述超时事件，并确定所述超时事件是否触发，并在所述超时事件触发的情况下返回所述超时事件定义的回调信息，所述回调信息用于指示所述应用服务端在确定出所述用户订单的当前订单状态未切换至指定订单状态的情况下，根据所述超时事件定义的回调信息对所述用户订单的当前订单状态执行回调操作。
112.可选的，所述超时事件记录有超时触发条件，所述超时触发条件用于判断所述超时事件是否触发；
113.和/或，所述超时事件记录有相应用户订单待切换的指定订单状态。
114.可选的，上述方法还包括：
115.响应于所述应用服务端发送的针对超时事件的失效指令，删除相应的超时事件；
116.其中，所述失效指令由所述应用服务端在响应于所述应用客户端针对用户订单的订单操作以将所述用户订单切换至与所述订单操作对应的订单状态，且所切换的订单状态为指定订单状态的情况下发送；或者，所述失效指令由所述应用服务端在用户订单对应的超时事件触发，且确定出所述用户订单的当前订单状态已切换至指定订单状态的情况下发送。
117.可选的，所述方法应用于超时调度服务端，所述超时调度服务端包括超时中心、数据库服务器和调度器；
118.其中，超时中心用于接收并注册所述应用服务端发送的超时事件，并将所述超时事件存储至数据库服务器，以及，在接收到调度器发送的超时触发消息的情况下，向所述数据库服务器读取相应的超时事件；数据库服务器用于存储所述超时中心注册的超时事件；调度器用于读取所述数据库服务器存储的超时事件，并确定读取到的超时事件是否触发，以在读取到的超时事件触发的情况下向所述超时中心发送针对超时事件的超时触发消息。
119.需要说明的是，有关于图3中上述步骤的具体实施过程，可以参考上述图2所示实施例中的相关描述，本说明书在此不再赘述。
120.请参见图4，图4是一示例性实施例提供的一种订单状态的维护方法的多方交互图。如图4所示，该订单状态维护方法可以包括以下步骤：
121.步骤402，应用服务端41创建用户订单。
122.在此步骤中，应用服务端41响应于用户通过应用客户端发起的订单请求，开始内部逻辑处理，创建相应的用户订单。上述用户订单包括但不限于支付订单、交易订单、配送订单、预约订单等。以用户在外卖平台进行下单操作为例，用户在通过外卖平台的客户端发起订单，应用服务端接收到上述外卖订单，并可以为此位下单的用户创建相应的交易订单、支付订单、配送订单等。下文中以支付订单为例进行详细描述。
123.步骤404，应用服务端41生成超时事件。
124.在本步骤中，应用服务端41还将为各种类型的用户订单分别创建相应的超时事件。每笔用户订单对应一个超时事件，所述超时事件记录有超时触发条件，所述超时触发条件用于判断所述超时事件是否触发。举例而言，上述超时触发条件可以为订单对应的超时时间阈值，当达到此超时时间阈值时，超时事件被触发。以支付场景为例，上述超时时间阈值可以表现为支付时间，如果用户未在支付时间内完成支付操作，那么超时事件将会被触发。和/或，所述超时事件还可以记录有相应用户订单待切换的指定订单状态，上述指定订单状态即回调操作所指向的订单终态。举例而言，订单回调操作的目的是推向订单走向终态，而订单终态可以包含订单结束、订单关闭、订单删除等多个订单状态，上述指定订单状态表达了回调操作将订单更改为的最终状态，并且，上述指定订单状态可以记录于超时事件中。
125.进一步的，在生成超时事件的过程中，其中的相应设置可以由外部业务系统通过发送事件配置信息的方式自行配置。如果订单为支付订单，那么可以由支付系统自行配置超时时间、超时事件被触发后回调到的指定订单状态等各种类型的个性化事件配置信息，并将上述事件配置信息发送至应用服务端41以生成相应的超时事件。当然，上述事件配置信息也可以采用应用服务端41的默认设置，如果外部业务系统发送的个性化配置信息和默认设置同时存在，也可以在生成超时事件时优先采用个性化配置信息，具体如何选择本说明书不进行限制。
126.步骤406，应用服务端41注册超时事件至超时调度服务端40中的超时中心42。
127.在本步骤中，超时调度服务端40包括：超时中心42，被具体配置为接收并注册所述应用服务端41发送的超时事件，并将所述超时事件存储至数据库服务器43。数据库服务器43被配置为存储超时中心42注册的超时事件。
128.步骤408，数据服务器43持久化超时事件。即数据服务器43存储超时中心42发送的超时事件。
129.步骤410，调度器44确定超时事件是否触发。
130.调度器44读取数据库服务器43存储的超时事件，并确定读取到的超时事件是否触发，以支付订单为例，如果用户超出了超时事件中定义的超时时间仍未完成支付，那么超时事件被触发。
131.步骤412，调度器44向超时中心42发送超时触发消息。
132.调度器44确定超时事件触发的情况下向所述超时中心42发送针对超时事件的超时触发消息。
133.步骤414，超时中心42在接收到调度器44发送的超时触发消息的情况下，向数据库服务器43读取相应的超时事件。
134.步骤416，超时中心42从读取的超时事件中确定回调信息，回调信息指示了回调操作应将订单回调的指定订单状态。那么，在本步骤中，超时中心42便可以将回调信息发送至应用服务端41，以指示应用服务端41按照回调信息执行步骤418中的回调操作，即，将相应的订单状态回调至指定订单状态，以将此订单推向终态，完成对订单生命周期的管理过程。
135.与上述方法实施例相对应，本说明书还提供了相应的装置实施例。
136.图5是一示例性实施例提供的一种设备的示意结构图。请参考图5，在硬件层面，该设备包括处理器502、内部总线504、网络接口506、内存508以及非易失性存储器510，当然还可能包括其他业务所需要的硬件。本说明书一个或多个实施例可以基于软件方式来实现，比如由处理器502从非易失性存储器510中读取对应的计算机程序到内存508中然后运行。当然，除了软件实现方式之外，本说明书一个或多个实施例并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。
137.请参考图6，图6是一示例性实施例提供的一种订单状态维护装置的框图。该装置可以应用于如图5所示的设备中，以实现本说明书的技术方案。其中，该装置可以包括：创建单元602、接收单元604和回调单元606；其中：
138.创建单元602，响应于应用客户端发起的订单请求，创建相应的用户订单，并生成与所述用户订单对应的超时事件，向超时调度服务端发送所述超时事件，以由所述超时调度服务端保存所述超时事件，并确定所述超时事件是否触发；
139.接收单元604，接收所述超时调度服务端在所述超时事件触发的情况下返回的所述超时事件定义的回调信息；
140.回调单元606，若确定出所述用户订单的当前订单状态未切换至指定订单状态，则根据所述超时事件定义的回调信息对所述用户订单的当前订单状态执行回调操作。
141.可选的，所述创建单元602具体用于：向所述订单请求指示的订单相关方发送获取请求，以指示所述订单相关方返回相应的订单参数，并基于所述订单参数创建相应的用户订单；
142.所述创建单元602具体用于：接收所述订单相关方返回的事件配置信息，基于所述事件配置信息生成与所述用户订单对应的超时事件。
143.可选的，所述超时事件记录有超时触发条件，所述超时触发条件用于判断所述超时事件是否触发；
144.和/或，所述超时事件记录有相应用户订单待切换的指定订单状态。
145.可选的，所述回调单元606具体用于：响应于所述应用客户端针对所述用户订单的订单操作，将所述用户订单切换至与所述订单操作对应的订单状态，若所切换的订单状态为指定订单状态，则向所述超时调度服务端发送事件失效指令，以指示所述超时调度服务端删除所述用户订单对应的超时事件；
146.或者，在用户订单对应的超时事件触发的情况下，若确定出所述用户订单的当前订单状态已切换至指定订单状态，则向所述超时调度服务端发送事件失效指令，以指示所述超时调度服务端删除所述用户订单对应的超时事件。
147.可选的，用户订单包括以下至少之一：
148.支付订单、交易订单、配送订单、预约订单。
149.请参考图7，图7是一示例性实施例提供的另一种订单状态维护装置的框图。该装置可以应用于如图5所示的设备中，以实现本说明书的技术方案。其中，该装置可以包括：接收单元702和保存单元704；其中：
150.接收单元702，接收应用服务端发送的与用户订单对应的超时事件，所述超时事件由所述应用服务端响应于应用客户端发起的订单请求而创建得到；
151.保存单元704，保存所述超时事件，并确定所述超时事件是否触发，并在所述超时事件触发的情况下返回所述超时事件定义的回调信息，所述回调信息用于指示所述应用服务端在确定出所述用户订单的当前订单状态未切换至指定订单状态的情况下，根据所述超时事件定义的回调信息对所述用户订单的当前订单状态执行回调操作。
152.可选的，所述超时事件记录有超时触发条件，所述超时触发条件用于判断所述超时事件是否触发；
153.和/或，所述超时事件记录有相应用户订单待切换的指定订单状态。
154.可选的，所述保存单元704具体用于：
155.响应于所述应用服务端发送的针对超时事件的失效指令，删除相应的超时事件；
156.其中，所述失效指令由所述应用服务端在响应于所述应用客户端针对用户订单的订单操作以将所述用户订单切换至与所述订单操作对应的订单状态，且所切换的订单状态为指定订单状态的情况下发送；或者，所述失效指令由所述应用服务端在用户订单对应的超时事件触发，且确定出所述用户订单的当前订单状态已切换至指定订单状态的情况下发送。
157.可选的，所述方法应用于超时调度服务端，所述超时调度服务端包括超时中心、数据库服务器和调度器；
158.其中，超时中心用于接收并注册所述应用服务端发送的超时事件，并将所述超时事件存储至数据库服务器，以及，在接收到调度器发送的超时触发消息的情况下，向所述数据库服务器读取相应的超时事件；数据库服务器用于存储所述超时中心注册的超时事件；调度器用于读取所述数据库服务器存储的超时事件，并确定读取到的超时事件是否触发，以在读取到的超时事件触发的情况下向所述超时中心发送针对超时事件的超时触发消息。
159.上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
160.在一个典型的配置中，计算机包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
161.内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)。内存是计算机可读介质的示例。
162.计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动
态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
163.还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
164.上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。
165.在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
166.应当理解，尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在
……
时”或“当
……
时”或“响应于确定”。
167.以上所述仅为本说明书一个或多个实施例的较佳实施例而已，并不用以限制本说明书一个或多个实施例，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例保护的范围之内。