一种订单管理方法及装置

技术领域

本申请涉及计算机技术领域，尤其涉及一种订单管理方法、装置、电子设备及机器可读存储介质。

背景技术

在业务处理场景中，通常会存在订单超时未支付的情况，针对这种情况，业务系统通常会向用户重新发起支付提醒，并等待一段时间后再进行处理，而大量此类超时订单，容易导致大量计算资源在某时间段内被锁定，从而降低了业务处理的效率。

发明内容

本申请提供一种订单管理方法，所述方法包括：

将已创建的至少一个业务订单的订单信息在搭载的缓存数据库中进行存储；

周期性地基于所述缓存数据库中存储的所述至少一个业务订单的订单信息，确定所述至少一个业务订单中的各个业务订单的订单状态是否为超时状态；

对确定出的超时状态的业务订单进行终止处理。

可选的，所述缓存数据库包括key-value缓存数据库；

将已创建的至少一个业务订单的订单信息在搭载的缓存数据库中进行存储，包括：

将已创建的至少一个业务订单的订单信息处理成key-value键值对；

将所述key-value键值对在搭载的所述缓存数据库中进行存储。

可选的，所述订单信息包括订单属性和订单状态；所述key-value键值对中的key为所述订单属性，所述key-value键值对中的value为所述订单状态。

可选的，所述缓存数据库包括基于redis的缓存数据库；

可选的，对确定出的超时状态的业务订单进行终止处理，包括：

创建与确定出的超时状态的业务订单对应的数据库事务；其中，所述数据库事务为针对所述超时状态的业务订单进行终止处理的事务；

执行所述数据库事务，以对确定出的超时状态的业务订单进行终止处理。

可选的，将已创建的至少一个业务订单的订单信息在搭载的缓存数据库中进行存储，包括：

在创建所述至少一个业务订单的过程中，将所述至少一个业务订单的订单信息同步存储至搭载的缓存数据库中。

可选的，基于所述缓存数据库中存储的所述至少一个业务订单的订单信息，确定所述至少一个业务订单中的各个业务订单的订单状态是否为超时状态，包括：

基于所述缓存数据库中存储的所述至少一个业务订单的订单信息包含的订单状态，确定所述至少一个业务订单中的各个业务订单的订单状态是否为超时状态。

可选的，所述订单信息包括订单创建时刻和预设的订单超时时长；

在基于所述缓存数据库中存储的所述至少一个业务订单的订单信息包含的订单状态，确定所述至少一个业务订单中的各个业务订单的订单状态是否为超时状态之前，所述方法还包括：

计算所述缓存数据库中存储的所述至少一个业务订单中的各个业务订单的订单创建时刻和当前时刻之间的时长，并确定计算出的所述时长是否达到所述订单超时时长；

如果所述缓存数据库中存储的所述至少一个业务订单中的任一业务订单的订单创建时刻和当前时刻之间的时长，达到所述订单超时时长，将所述任一业务订单的订单状态更新为超时状态。

可选的，所述终止处理包括取消处理；所述订单信息还包括订单状态；

所述方法还包括：

响应于对所述确定出的超时状态的业务订单进行取消处理完成，将搭载的所述缓存数据库中存储的所述超时状态的业务订单的订单状态更新为已取消状态。

可选的，所述终止处理包括归档处理；所述订单信息还包括订单状态；

所述方法还包括：

响应于对所述确定出的超时状态的业务订单进行归档处理完成，将搭载的所述缓存数据库中存储的所述超时状态的业务订单的订单状态更新为已归档状态。

可选的，所述方法还包括：

响应于所述缓存数据库中存储的所述任一业务订单在预设的订单超时时长内执行完成，将所述缓存数据库中存储的所述任一业务订单的订单信息删除。

可选的，所述方法还包括：

响应于所述缓存数据库中存储的所述任一业务订单的订单状态发生更新，实时向订阅所述任一业务订单的订单状态的用户和/或业务方推送所述业务订单更新后的订单状态。

本申请还提供一种订单管理装置，所述装置包括：

存储单元，用于将已创建的至少一个业务订单的订单信息在搭载的缓存数据库中进行存储；

确定单元，用于周期性地基于所述缓存数据库中存储的所述至少一个业务订单的订单信息，确定所述至少一个业务订单中的各个业务订单的订单状态是否为超时状态；

处理单元，用于对确定出的超时状态的业务订单进行终止处理。

本申请还提供一种电子设备，包括通信接口、处理器、存储器和总线，所述通信接口、所述处理器和所述存储器之间通过总线相互连接；

所述存储器中存储机器可读指令，所述处理器通过调用所述机器可读指令，执行所述订单管理方法。

本申请还提供一种机器可读存储介质，所述机器可读存储介质存储有机器可读指令，所述机器可读指令在被处理器调用和执行时，实现所述订单管理方法。

本申请提供的技术方案至少可以包括以下有益效果：

通过以上实施例，可以将已创建的至少一个业务订单的订单信息在搭载的缓存数据库中进行存储；通过周期性地基于所述缓存数据库中存储的所述至少一个业务订单的订单信息，可以确定所述至少一个业务订单中的各个业务订单的订单状态是否为超时状态，并对确定出的超时状态的业务订单及时进行终处理。通过及时对超时未支付的订单进行终止处理，及时释放计算资源，从而提高业务处理的效率。

附图说明

图1是一示例性的实施例示出的一种订单管理方法的流程图。

图2是一示例性的实施例示出的另一种订单管理方法的流程图。

图3是一示例性的实施例示出的一种成订单管理装置所在电子设备的硬件结构图。

图4是一示例性的实施例示出的一种订单管理装置的框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

需要说明的是：在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中，其方法所包括的步骤可以比本说明书所描述的更多或更少。此外，本说明书中所描述的单个步骤，在其他实施例中可能被分解为多个步骤进行描述；而本说明书中所描述的多个步骤，在其他实施例中也可能被合并为单个步骤进行描述。

在业务处理场景中，通常会存在订单超时未支付的情况，针对这种情况，在实际应用中，业务系统通常会向用户重新发起与该订单对应的支付提醒，再等待一段时间，如果用户在这段时间内还没有支付，则取消该订单，并释放计算资源。

由此可见，如果在某时间段内，存在大量此类超时订单，容易导致大量计算资源在该时间段内被锁定，从而降低了业务处理的效率。

有鉴于此，本申请旨在提出一种订单管理方法。该方法通过及时针对超时订单进行终止处理，以及时释放计算资源。

在实现时，可以将已创建的至少一个业务订单的订单信息在搭载的缓存数据库中进行存储；

进一步地，可以周期性地基于所述缓存数据库中存储的所述至少一个业务订单的订单信息，确定所述至少一个业务订单中的各个业务订单的订单状态是否为超时状态；

进一步地，可以对确定出的超时状态的业务订单进行终止处理。

通过以上实施例，可以将已创建的至少一个业务订单的订单信息在搭载的缓存数据库中进行存储；通过周期性地基于所述缓存数据库中存储的所述至少一个业务订单的订单信息，可以确定所述至少一个业务订单中的各个业务订单的订单状态是否为超时状态，并对确定出的超时状态的业务订单及时进行终处理。通过及时对超时未支付的订单进行终止处理，及时释放计算资源，从而提高业务处理的效率。

下面通过具体实施例，并结合具体的应用场景对本申请进行描述。

请参见图1，图1是一示例性的实施例示出的一种订单管理方法的流程图。

本方案可以应用于业务管理系统，本说明书对此不做限定。

如图1所示，基于本方案应用于业务管理系统，该业务管理系统可以执行以下步骤：

步骤102，将已创建的至少一个业务订单的订单信息在搭载的缓存数据库中进行存储。

为了便于对已创建的业务订单进行管理，可以将已创建的业务订单的订单信息在搭载的缓存数据库中进行存储，后续可以基于该缓存数据库中存储的各个业务订单的订单信息，对各个业务订单进行管理。

例如，上述已创建的至少一个业务订单可以包括业务订单_1以及业务订单_2，上述业务管理系统可以将该业务订单_1以及业务订单_2的订单信息存储在搭载的缓存数据库中。

关于存储的具体方式，可以将业务订单在创建时将订单信息同步存储至缓存数据库，本说明书对此不做限定。

在示出的一种实施方式中，在创建上述至少一个业务订单的过程中，可以将上述至少一个业务订单的订单信息同步存储至搭载的缓存数据库中。

例如，上述至少一个业务订单可以包括业务订单_1以及业务订单_2，可以在创建业务订单_1时，将业务订单_1的订单信息_1同步存储至搭载的缓存数据库中；在创建业务订单_2时，也可以将业务订单_2的订单信息_2同步存储至该缓存数据库中。

通过这种同步存储的方式，能够提高订单信息存储的准确性。

在示出的一种实施方式中，上述缓存数据库可以包括key-value缓存数据。上述业务管理系统可以将已创建的至少一个业务订单的订单信息处理成key-value键值对，并可以将上述key-value键值对在搭载的上述缓存数据库中进行存储。

上述至少一个业务订单的订单信息可以以key-value键值对的形式存储在上述缓存数据库中，便于后续快速查询该至少一个业务订单的订单信息，以确定该缓存数据库中的超时业务订单。

例如，上述至少一个业务订单可以包括业务订单_1以及业务订单_2，上述业务管理系统可以将该业务订单_1的订单信息_1处理成key-value键值对_1以及业务订单_2的订单信息_2处理成key-value键值对_2，并可以将该key-value键值对_1以及该key-value键值对_2在搭载的缓存数据库中进行存储。

通过这种方式，便于后续快速查询该至少一个业务订单的订单信息，提高订单管理的效率。

关于该key-value键值对中的key以及value的具体内容，可以为订单信息中包含的任一信息，本说明书对此不做限定。

在示出的一种实施方式中，上述订单信息可以包括订单属性和订单状态；上述key-value键值对中的key可以为上述订单属性，上述key-value键值对中的value可以为上述订单状态。

关于上述订单属性的具体内容，本说明书对此不做限定。例如，业务订单的订单标识、订单创建时刻以及订单的超时时长。

上述订单信息可以包括订单属性和订单状态，在这种情况下，可以将订单属性订单状态存储在上述key-value键值对中的key中，将上述订单状态存储在上述key-value键值对中的value中。

通过这种方式，便于后续通过查询该各个业务订单对应的key-value键值对中的value的值，快速确定该缓存数据库中存储的超时订单，从而提高查询的效率。

在示出的一种实施方式中，上述缓存数据库包括基于Redis的缓存数据库。

Redis(Remote Dictionary Server，远程字典服务器)是一个开源的高性能键值存储数据库，通常以内存数据结构存储数据，并通过简单的键值对来提供对数据的访问，支持多种数据结构，包括字符串、哈希、列表、集合和有序集合等。

步骤104，周期性地基于上述缓存数据库中存储的上述至少一个业务订单的订单信息，确定上述至少一个业务订单中的各个业务订单的订单状态是否为超时状态。

上述业务管理系统可以周期性地确定各个业务订单的订单状态是否为超时状态，具体而言，业务管理系统可以基于缓存数据库中存储的业务订单的订单信息，确定各个业务订单的订单状态是否为超时状态。

在示出的一种实施方式中，上述订单信息中可以包含有订单状态，上诉业务管理系统可以基于上述缓存数据库中存储的上述至少一个业务订单的订单信息包含的订单状态，来确定上述至少一个业务订单中的各个业务订单的订单状态是否为超时状态。

例如，上述至少一个业务订单可以包括业务订单_1以及业务订单_2，上述缓存数据库中可以存储有业务订单_1的订单信息_1以及业务订单_2的订单信息_2，该订单信息_1包括订单状态_1，该订单信息_2可以包括订单状态_2，上诉业务管理系统可以基于该缓存数据库中存储的业务订单_1以及业务订单_2的订单状态，来确定业务订单_1以及业务订单_2的订单状态是否为超时状态。

在示出的一种实施方式中，上述订单信息可以包括订单创建时刻和预设的订单超时时长；上述业务管理系统在基于上述缓存数据库中存储的上述至少一个业务订单的订单信息包含的订单状态，确定上述至少一个业务订单中的各个业务订单的订单状态是否为超时状态之前，还可以计算上述缓存数据库中存储的上述至少一个业务订单中的各个业务订单的订单创建时刻和当前时刻之间的时长，并确定计算出的上述时长是否达到上述订单超时时长，如果上述缓存数据库中存储的上述至少一个业务订单中的任一业务订单的订单创建时刻和当前时刻之间的时长，达到上述订单超时时长，可以将上述任一业务订单的订单状态更新为超时状态。

上述业务管理系统可以计算任一业务订单的订单创建时刻和当前时刻之间的时长，以通过该时长是否达到预设的订单超时时长来确定该任一业务订单是否超时，如果该任一业务订单超时，则可以将该任一业务订单的订单状态更新为超时状态，以便于后续基于该任一业务订单的订单状态为超时状态，及时对该任一业务订单进行终止处理。

例如，上述至少一个业务订单可以包括业务订单_1，该业务订单_1的订单信息可以包括订单创建时刻以及预设的订单超时时长，上述业务管理系统可以计算该业务订单的订单创建时刻和当前时刻之间的时长，并确定该时长是否达到预设的订单超时时长，如果该时长达到预设的订单超时时长，可以将该业务订单的订单状态更新为超时状态。

通过这种方式，周期性地更新业务订单的订单状态，便于后续及时对超时的业务订单进行处理。

步骤106，对确定出的超时状态的业务订单进行终止处理。

为了避免大量的超时订单占用计算资源，可以及时对确定出的超时状态的业务订单进行终止处理。

例如，上述至少一个业务订单可以包括业务订单_1以及业务订单_2，如果确定出该业务订单_1或者业务订单_2的订单状态为超时状态，可以对该业务订单_1或者业务订单_2进行终止处理。

关于如何对超时状态的业务订单进行终止处理，可以通过创建并执行数据库事务对该业务订单进行终止处理，本说明书对此不做限定。

在示出的一种实施方式中，上述业务管理系统可以创建与确定出的超时状态的业务订单对应的数据库事务；其中，上述数据库事务为针对上述超时状态的业务订单进行终止处理的事务；上述业务管理系统可以通过执行上述数据库事务，来对确定出的超时状态的业务订单进行终止处理。

例如，上述业务管理系统可以通过数据库事务创建指令，创建用于对上述超时状态的业务订单进行终止处理的事务，其中，该超时状态的业务订单可以包括业务订单_1以及业务订单_2，上述业务管理系统可以通过数据库事务执行指令，执行对上述业务订单_1以及业务订单_2进行终止处理的数据库事务。

关于上述数据库事务创建指令，在不同的数据库中采用对应的创建指令，其中，在Redis数据库中，可以是MULTI指令，本说明书对此不做限定。

关于上述数据库事务执行指令，在不同的数据库中采用对应的执行指令，其中，在Redis数据库中，可以是EXEC指令，本说明书对此不做限定。

通过这种方式，能够通过创建并执行数据库事务对预设周期内的所有超时状态的业务订单进行终止处理，提高业务管理的效率。

关于上述终止处理的具体方式，本说明书对此不做限定。例如，上述终止处理可以是取消处理，还可以是归档处理。

在示出的一种实施方式中，上述终止处理可以包括取消处理，上述订单信息可以包括订单状态；上述业务管理系统可以响应于对上述确定出的超时状态的业务订单进行取消处理完成，将搭载的上述缓存数据库中存储的上述超时状态的业务订单的订单状态更新为已取消状态。

上述业务管理系统可以在对上述超时状态的业务订单进行终止处理后，对该业务订单的订单状态进行更新，以避免对超时状态的业务订单进行重复处理。

例如，上述超时状态的业务订单可以包括业务订单_1以及业务订单_2，上述业务管理系统可以对业务订单_1进行取消处理，并可以响应于对上述业务订单_1进行取消处理完成，将搭载的上述缓存数据库中存储的上述业务订单_1的订单状态更新为已取消状态。

在示出的一种实施方式中，上述终止处理可以包括归档处理，上述订单信息可以包括订单状态；上述业务管理系统可以响应于对上述确定出的超时状态的业务订单进行归档处理完成，将搭载的上述缓存数据库中存储的上述超时状态的业务订单的订单状态更新为已归档状态。

例如，上述超时状态的业务订单可以包括业务订单_1以及业务订单_2，上述业务管理系统可以对业务订单_2进行归档处理，并可以响应于对上述业务订单_2进行归档处理完成，将搭载的上述缓存数据库中存储的上述业务订单_2的订单状态更新为已归档状态。

在示出的一种实施方式中，上述业务管理系统可以响应于上述缓存数据库中存储的上述任一业务订单在预设的订单超时时长内执行完成，将上述缓存数据库中存储的上述任一业务订单的订单信息删除。

为了避免大量的订单信息占据缓存数据库，可以及时对已经执行完成的业务订单的订单信息进行删除。

例如，上述缓存数据库中存储的上述至少一个业务订单还可以包括业务订单_5，上述业务管理系统可以响应于该业务订单_5在预设的订单超时时长内执行完成，将该业务订单_5的订单信息删除。

通过这种方式，能够及时删除无需进行终止处理的业务订单，及时释放缓存数据库的存储，从而提高业务处理的效率。

在示出的一种实施方式中，上述业务管理系统可以响应于上述缓存数据库中存储的上述任一业务订单的订单状态发生更新，实时向订阅上述任一业务订单的订单状态的用户和/或业务方推送上述业务订单更新后的订单状态。

上述业务管理系统可以将业务订单的订单状态变化及时推送给订阅业务订单的用户和/或业务方，以便于用户及时获知该业务订单的订单进展，以及便于业务方基于该业务订单的订单进展进行后续处理。

例如，上述业务管理系统可以响应于上述缓存数据库中存储的上述任一业务订单的订单状态更新至超时状态，实时向订阅上述任一业务订单的订单状态的用户推送业务订单的订单状态为超时状态，以提醒用户获知该业务订单超时未支付，以及，可以向业务方推送该业务订单的订单状态为超时状态，以便于业务方进行后续处理。

通过这种方式，能够及时将业务订单的订单状态推送给相关用户以及业务方，以便于用户或者业务方进行后续处理，提高了订单处理的完整性。

为了使本技术领域的人员更好地理解本说明书实施例中的技术方案，下面以至少一个业务订单可以包括三个业务订单为例，结合如图2所示的订单管理方法的流程图对本说明书中的实施例进行说明。

请参见图2，图2是一示例性的实施例示出的另一种订单管理方法的流程图。

步骤202，在创建业务订单时，将业务订单的订单信息处理成key-value键值对，并同步存储至缓存数据库中。

上述至少一个业务订单可以包括业务订单_1、业务订单_2以及业务订单_3，上述业务管理系统可以在将该业务订单_1创建时，将业务订单_1的订单信息_1处理成key-value键值对_1，并将该key-value键值对_1同步存储至缓存数据库中；可以在将该业务订单_2创建时，将业务订单_2的订单信息_2处理成key-value键值对_2，并将该key-value键值对_2同步存储至缓存数据库中；可以在将该业务订单_3创建时，将业务订单_3的订单信息_3处理成key-value键值对_3，并将该key-value键值对_3同步存储至缓存数据库中。

步骤204，计算业务订单的订单创建时刻和当前时刻之间的时长，通过该时长是否达到预设的订单超时时长来确定该任一业务订单是否超时。

上述各个订单信息中可以包含有订单创建时刻和预设的订单超时时长，上述业务管理系统可以通过计算业务订单_1的订单创建时刻和当前时刻之间的时长，通过该时长是否达到预设的订单超时时长来确定该业务订单_1是否超时；针对上述业务订单_2以及业务订单_3，也执行上述针对业务订单_1执行的步骤，本说明书对此不过多赘述。

步骤206，如果上述任一业务订单超时，则将该任一业务订单的订单状态更新为超时状态。

如果上述业务订单_1超时，则可以将该业务订单_1的订单状态更新为超时状态；如果上述业务订单_3超时，则可以将该业务订单_3的订单状态更新为超时状态。

步骤208，对确定出的超时状态的业务订单进行终止处理；其中，上述终止处理包括取消处理或归档处理。

上述业务管理系统可以对业务订单_1进行取消处理，并可以响应于对上述业务订单_1进行取消处理完成，将搭载的上述缓存数据库中存储的上述业务订单_1的订单状态更新为已取消状态；上述业务管理系统可以对业务订单_3进行归档处理，并可以响应于对上述业务订单_3进行归档处理完成，将搭载的上述缓存数据库中存储的上述业务订单_3的订单状态更新为已归档状态。

步骤210，对未超时的业务订单的订单信息进行删除处理。

上述业务管理系统可以响应于上述业务订单_2在预设的订单超时时长内执行完成，将该业务订单_2的订单信息删除。

与所述订单管理方法的实施例对应的，本说明书还提供了一种订单管理装置的实施例。

请参见图3，图3是一示例性的实施例示出的一种订单管理装置所在电子设备的硬件结构图。在硬件层面，该设备包括处理器302、内部总线304、网络接口306、内存308以及非易失性存储器310，当然还可能包括其他业务所需要的硬件。本说明书一个或多个实施例可以基于软件方式来实现，比如由处理器302从非易失性存储器310中读取对应的计算机程序到内存308中然后运行。当然，除了软件实现方式之外，本说明书一个或多个实施例并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参见图4，图4是一示例性的实施例示出的一种订单管理装置的框图。该订单管理装置可以应用于图3所示的电子设备中，以实现本说明书的技术方案。其中，所述装置可以包括：

存储单元402，用于将已创建的至少一个业务订单的订单信息在搭载的缓存数据库中进行存储；

确定单元404，用于周期性地基于上述缓存数据库中存储的上述至少一个业务订单的订单信息，确定上述至少一个业务订单中的各个业务订单的订单状态是否为超时状态；

处理单元406，用于对确定出的超时状态的业务订单进行终止处理。在本实施例中，上述缓存数据库可以包括key-value缓存数据库；

上述存储单元402，具体可以用于：

将已创建的至少一个业务订单的订单信息处理成key-value键值对；

将上述key-value键值对在搭载的上述缓存数据库中进行存储。

在本实施例中，上述订单信息可以包括订单属性和订单状态；上述key-value键值对中的key可以为上述订单属性，上述key-value键值对中的value可以为上述订单状态。

在本实施例中，上述缓存数据库可以包括基于Redis的缓存数据库；

在本实施例中，上述处理单元406，具体可以用于：

创建与确定出的超时状态的业务订单对应的数据库事务；其中，上述数据库事务为针对上述超时状态的业务订单进行终止处理的事务；

执行上述数据库事务，以对确定出的超时状态的业务订单进行终止处理。

在本实施例中，上述存储单元402，具体可以用于：

在创建上述至少一个业务订单的过程中，将上述至少一个业务订单的订单信息同步存储至搭载的缓存数据库中。

在本实施例中，上述确定单元404，具体可以用于：

基于上述缓存数据库中存储的上述至少一个业务订单的订单信息包含的订单状态，确定上述至少一个业务订单中的各个业务订单的订单状态是否为超时状态。

在本实施例中，上述订单信息可以包括订单创建时刻和预设的订单超时时长；

上述装置还可以包括计算单元，用于：

计算上述缓存数据库中存储的上述至少一个业务订单中的各个业务订单的订单创建时刻和当前时刻之间的时长，并确定计算出的上述时长是否达到上述订单超时时长；

如果上述缓存数据库中存储的上述至少一个业务订单中的任一业务订单的订单创建时刻和当前时刻之间的时长，达到上述订单超时时长，将上述任一业务订单的订单状态更新为超时状态。

在本实施例中，上述终止处理可以包括取消处理；上述订单信息可以还包括订单状态；

上述装置还可以包括响应单元，用于：

响应于对上述确定出的超时状态的业务订单进行取消处理完成，将搭载的上述缓存数据库中存储的上述超时状态的业务订单的订单状态更新为已取消状态。

在本实施例中，上述终止处理可以包括归档处理；上述订单信息还可以包括订单状态；

上述响应单元，还可以用于：

响应于对上述确定出的超时状态的业务订单进行归档处理完成，将搭载的上述缓存数据库中存储的上述超时状态的业务订单的订单状态更新为已归档状态。

在本实施例中，上述响应单元，还可以用于：

响应于上述缓存数据库中存储的上述任一业务订单在预设的订单超时时长内执行完成，将上述缓存数据库中存储的上述任一业务订单的订单信息删除。

在本实施例中，上述响应单元，还可以用于：

响应于上述缓存数据库中存储的上述任一业务订单的订单状态发生更新，实时向订阅上述任一业务订单的订单状态的用户和/或业务方推送上述业务订单更新后的订单状态。

所述装置中各个单元的功能和作用的实现过程具体详见所述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例只是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本说明书方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

所述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

在一个典型的配置中，计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

所述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

在本说明书一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

以上所述仅为本说明书一个或多个实施例的较佳实施例而已，并不用以限制本说明书一个或多个实施例，凡在本说明书一个或多个实施例的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书一个或多个实施例保护的范围之内。

本申请所涉及的用户信息(包括但不限于用户设备信息、用户个人信息等)和数据(包括但不限于用于分析的数据、存储的数据、展示的数据等)，均为经用户授权或者经过各方充分授权的信息和数据，并且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准，并提供有相应的操作入口，供用户选择授权或者拒绝。