订单处理方法及装置、计算机可读存储介质、电子设备与流程

本公开涉及通信技术领域，尤其涉及一种订单处理方法与订单处理装置、计算机可读存储介质及电子设备。

背景技术：

业务方调用扣费接口时，若接口返回正常，业务方会根据接口的返回值判断此次扣费成功或是失败，并继续进行相应的业务逻辑。但是，若接口异常返回时，业务方会将本次扣费当作失败处理，而扣费服务对于本次扣费调用的结果是不确定的。若本次扣费确实失败，业务方将本次调用异常当作失败处理是正确的，业务表现也正常；若本次扣费实际上是成功的，会造成业务表现不正常，容易引发用户投诉。

因此，接口异常返回时，也可能存在扣费成功的情况，但业务方此时认为扣费异常会导致业务逻辑不正常，容易引发用户投诉。更进一步的，用户投诉后需要业务方查证扣费时间点的错误日志，需要在拿到扣费订单号后查询订单扣费状态，并确认实际扣费成功后再给用户补发奖励。整个过程需要的人力成本和时间成本过高。

鉴于此，本领域亟需开发一种新的订单处理方法及装置。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

技术实现要素：

本公开的目的在于提供一种订单处理方法、订单处理装置、计算机可读存储介质及电子设备，进而至少在一定程度上克服由于相关技术的限制而导致的业务逻辑异常和成本过高问题。

本公开的其他特性和优点将通过下面的详细描述变得显然，或部分地通过本公开的实践而习得。

根据本发明实施例的第一个方面，提供一种订单处理方法，所述方法包括：响应业务服务器发送的针对订单扣费的查询信息，对所述订单的扣费状态进行查询处理；

若所述查询处理得到的结果为订单扣费成功，向所述业务服务器发送异常信息，所述异常信息用于指示业务服务器对所述订单进行业务逻辑处理。

在本发明的一种示例性实施例中，在所述响应业务服务器发送的针对订单扣费的查询信息之前，所述方法还包括：

在扣费服务器的扣费接口异常时，业务服务器发送针对订单扣费的查询信息。

在本发明的一种示例性实施例中，所述对所述订单的扣费状态进行查询处理，包括：

针对所述订单的扣费状态向扣费服务器发起轮询。

在本发明的一种示例性实施例中，所述针对所述订单的扣费状态向扣费服务器发起轮询，包括：

生成与所述订单对应的轮询记录；

将所述轮询记录存储至与所述订单对应的数据库中；

若所述轮询记录中的轮询状态为待轮询，从扣费服务器对所述订单进行查询处理得到结果为订单扣费成功、订单扣费失败或轮询失败的扣费状态。

在本发明的一种示例性实施例中，所述方法还包括：

若所述查询处理得到的结果为订单扣费失败，停止所述轮询。

在本发明的一种示例性实施例中，所述方法还包括：

若所述查询处理得到的结果为轮询失败，则继续进行所述轮询。

在本发明的一种示例性实施例中，所述方法还包括：

统计所述轮询的次数，并在所述次数大于轮询阈值时，发送报警消息。

在本发明的一种示例性实施例中，所述查询信息包括与所述订单对应的回调接口；

所述向所述业务服务器发送异常信息，包括：

调用所述回调接口向所述业务服务器发送异常信息。

根据本发明实施例的第二个方面，提供一种订单处理装置，所述装置包括：状态查询模块，被配置为响应业务服务器发送的针对订单扣费的查询信息，对所述订单的扣费状态进行查询处理；

信息发送模块，被配置为若所述查询处理得到的结果为订单扣费成功，向所述业务服务器发送异常信息，所述异常信息用于指示业务服务器对所述订单进行业务逻辑处理。

根据本发明实施例的第三个方面，提供一种电子设备，包括：处理器和存储器；其中，存储器上存储有计算机可读指令，所述计算机可读指令被所述处理器执行时实现上述任意示例性实施例中的订单处理方法。

根据本发明实施例的第四个方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意示例性实施例中的订单处理方法。

由上述技术方案可知，本公开示例性实施例中的订单处理方法、订单处理装置、计算机存储介质及电子设备至少具备以下优点和积极效果：

在本公开的示例性实施例提供的方法及装置中，通过对订单的扣费状态的查询处理可以向业务服务器发送异常信息，保证订单的业务逻辑处理。一方面，对业务服务器发送的查询信息进行自动检测和恢复，避免了繁琐的人工处理，提高了异常处理效率；另一方面，在对业务服务器更加友好的情况下解决了订单扣费异常问题，减轻了业务服务器对异常情况的复杂处理的负担。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示意性示出本公开示例性实施例中一种订单处理方法的流程示意图；

图2示意性示出本公开示例性实施例中向扣费服务器发起轮询的方法的流程示意图；

图3示意性示出本公开示例性实施例中应用场景下订单处理方法的整体架构图；

图4示意性示出本公开示例性实施例中应用场景下订单处理方法的时序图；

图5示意性示出本公开示例性实施例中应用场景下不同结果的处理方法的流程示意图；

图6示意性示出本公开示例性实施例中一种订单处理装置的结构示意图；

图7示意性示出本公开示例性实施例中一种用于实现订单处理方法的电子设备；

图8示意性示出本公开示例性实施例中一种用于实现订单处理方法的计算机可读存储介质。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。

本说明书中使用用语“一个”、“一”、“该”和“所述”用以表示存在一个或多个要素/组成部分/等；用语“包括”和“具有”用以表示开放式的包括在内的意思并且是指除了列出的要素/组成部分/等之外还可存在另外的要素/组成部分/等；用语“第一”和“第二”等仅作为标记使用，不是对其对象的数量限制。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。

针对相关技术中存在的问题，本公开提出了一种订单处理方法，通过第一终端设备提供图形用户界面，图形用户界面显示至少部分的游戏场景。图1示出了订单处理方法的流程图，如图1所示，订单处理方法至少包括以下步骤：

步骤s110.响应业务服务器发送的针对订单扣费的查询信息，对订单的扣费状态进行查询处理。

步骤s120.若查询处理得到的结果为订单扣费成功，向业务服务器发送异常信息，异常信息用于指示业务服务器对订单进行业务逻辑处理。

在本公开的示例性实施例中，通过对订单的扣费状态的查询处理可以向业务服务器发送异常信息，保证订单的业务逻辑处理。一方面，对业务服务器发送的查询信息进行自动检测和恢复，避免了繁琐的人工处理，提高了异常处理效率；另一方面，在整个异常处理的过程中，业务服务器在发送查询信息后，只需根据异常检测服务器反馈的异常信息对该订单进行业务逻辑处理，如异常检测服务器没有反馈异常信息则业务服务器只需正常工作即可，这样，可以在对业务服务器更加友好的情况下解决了订单扣费异常问题，减轻了业务服务器对异常情况的复杂处理的负担。

下面对订单处理方法的各个步骤进行详细说明。

在步骤s110中，响应业务服务器发送的针对订单扣费的查询信息，对订单的扣费状态进行查询处理。

在本公开的示例性实施例中，业务服务器可以调用扣费服务器的订单扣费接口，在订单扣费接口返回结果异常时向异常检测服务器发送一条查询信息。

其中，扣费服务器可以提供扣费接口和订单状态查询接口实现扣费和订单状态查询的功能。

在可选的实施例中，在扣费服务器的扣费接口异常时，业务服务器发送针对订单扣费的查询信息。

该查询信息用于通知异常检测服务器扣费接口异常的。

举例而言，该查询信息包括该订单的标识信息、回调接口，还可以包括其他信息，本示例性实施例对此不做特殊限定。其中，回调接口是由业务服务器提供的，并用来处理扣费成功后的业务逻辑的。

进一步的，当异常检测服务器接收到查询信息时，可以对订单的扣费状态进行查询处理。

在可选的实施例中，针对订单的扣费状态向扣费服务器发起轮询。

进一步的，在可选的实施例中，图2示出了向扣费服务器发起轮询的方法的流程示意图，如图2所示，该方法至少包括以下步骤：在步骤s210中，生成与订单对应的轮询记录。

该轮询记录可以是初始化得到的。初始化的轮询记录包括订单的标识信息、回调接口、轮询状态和轮询次数，还可以包括其他信息，本示例性实施例对此不做特殊限定。其中，初始化的轮询记录的轮询状态为待轮询，轮询次数为0。

并且，由于轮询是在轮询周期内不断进行操作的，该轮询记录还可以是在一次或多次轮询后得到的。此时，轮询状态和轮询次数也同步进行更新。

举例而言，更新方式可以是将轮询状态从待轮询更新为已轮询，对轮询次数的更新可以是将现有的轮询次数进行+1处理。除此之外，也可以根据实际情况设置其他更新方式，本示例性实施例对此不做特殊限定。

在步骤s220中，将轮询记录存储至与订单对应的数据库中。

当生成轮询记录之后，可以将该轮询记录写入对应的数据库中，以便于存储和更新。

在步骤s230中，若轮询记录中的轮询状态为待轮询，向扣费服务器对订单进行查询处理得到的结果为订单扣费成功、订单扣费失败或轮询失败的扣费状态。

当生成轮询记录中的轮询状态为待轮询时，表明该订单的扣费状态是待查询的，因此可以向扣费服务器发起查询处理。

并且，该订单的查询处理可以由扣费服务器中的订单状态查询接口实现。

通过订单状态查询接口可以查询到订单的处理结果为订单扣费成功、订单扣费失败或轮询失败三种情况。

值得说明的是，查询处理可以是向一个订单发起的，也可以是在预设的轮询周期内得到的多个订单同时发起的。

在轮询周期内的所有订单只要轮询状态为待轮询，均可向扣费服务器发起查询处理。举例而言，该预设的轮询周期可以为5秒，也可以为其他时长，本示例性实施例对此不做特殊限定。

在本示例性实施例中，通过向扣费服务器发起轮询，可以实现查询订单的扣费状态的功能，对于业务服务器发送的查询信息进行自动检测和处理，避免了繁琐的人工处理，提供了异常处理效率。

在步骤s120中，若查询处理得到的结果为订单扣费成功，向业务服务器发送异常信息，异常信息用于指示业务服务器对订单进行业务逻辑处理。

在本公开的示例性实施例中，当查询处理得到的结果为订单扣费成功时，可以向业务服务器发送一条异常信息。该异常信息用于指示业务服务器进行扣费成功后的业务逻辑。

值得说明的是，指示业务服务器对订单进行业务逻辑处理只有在发送异常信息的情况下才执行，其他情形执行正常的业务处理即可。

举例而言，该业务逻辑可以是向用户补发虚拟货币，或者是其他任意方式的业务逻辑，本示例性实施例对此不做特殊限定。

在可选的实施例中，查询信息包括与订单对应的回调接口，因此，调用回调接口向业务服务器发送异常信息。

该回调接口与步骤s110中的回调接口相同，在此不再赘述。

除此之外，当订单扣费成功时，与订单对应的轮询记录中的轮询状态更新为已轮询，之后的轮询周期内不会再轮询该轮询记录。

在可选的实施例中，若查询处理得到的结果为订单扣费失败，停止轮询。

当对订单的扣费状态进行查询处理得到的结果是订单扣费失败时，同样设置订单的轮询记录中的轮询状态更新为已轮询，之后的轮询周期内也不会再轮询该轮询记录。

在可选的实施例中，若查询处理得到的结果为轮询失败，则继续进行轮询。

当轮询失败时，表明该订单的扣费状态不确定，需要在下一次的轮询周期继续轮询。并且，将订单的轮询记录中的轮询次数进行+1处理。

进一步的，在可选的实施例中，统计轮询的次数，并在次数大于轮询阈值时，发送报警信息。

该实施例适用于轮询失败时，对轮询次数进行更新的情况下。由于不断的轮询失败，可能导致轮询次数超过预设的轮询阈值。此时，可以发送一报警信息通过人工处理。处理后可以手动设置轮询记录的轮询状态，避免无效的订单长期占用轮询资源。

举例而言，该轮询阈值可以为20，也可以设置为其他数值，本示例性实施例对此不做特殊限定。

下面结合一应用场景对本公开实施例中订单处理方法做出详细说明。

图3示出了应用场景下订单处理方法的整体架构图，如图3所示，订单处理方法的整体架构包括扣费服务器310、业务服务器320和异常检测服务器330。其中，扣费服务器310可以提供扣费接口和订单状态查询接口。

进一步的，图4示出了应用场景下订单处理方法的时序图，如图4所示，在步骤s410中，业务服务器320调用扣费服务器310的扣费接口。

在步骤s420中，若扣费接口异常，业务服务器320向异常检测服务器330发送查询信息。

该查询信息包括该订单的标识信息和回调接口。其中，回调接口是由业务服务器提供的，用于处理扣费成功后的业务逻辑。

在步骤s430中，异常检测服务器330生成与订单对应的轮询记录，并且将轮询记录写入数据库中。

在步骤s440中，异常检测服务器330调用扣费服务器310的订单状态查询接口查询扣费状态。

在步骤s450中，若扣费状态为订单扣费成功时，异常检测服务器330向业务服务器320发送异常信息。

其中，该异常信息用于指示业务服务器对订单进行业务逻辑处理。

图5示出了应用场景下不同结果的处理方法的流程示意图，如图5所示，在步骤s510中，扣费异常检测服务器330从数据库中取出轮询状态为待轮询的订单。

在步骤s520，扣费异常检测服务器330调用扣费服务器310的订单状态查询接口。

在步骤s531中，若查询处理得到的结果为订单扣费成功，设置订单的轮询记录中的轮询状态为已轮询。

在步骤s532中，调用回调接口通知业务服务器320进行业务逻辑处理。

在步骤s541中，若查询处理得到的结果为订单扣费失败，设置订单的轮询记录中的轮询状态为已轮询。

在步骤s551中，若查询处理得到的结果为轮询失败，更新订单的轮询记录中的轮询次数+1。

在步骤s552中，当轮询的次数大于轮询阈值时，可以发送报警信息通知人工处理。

在该应用场景下的订单处理方法，通过对订单的扣费状态的查询处理可以向业务服务器发送异常信息，保证订单的业务逻辑处理。一方面，对业务服务器发送的查询信息进行自动检测和恢复，避免了繁琐的人工处理，提高了异常处理效率；另一方面，在对业务服务器更加友好的情况下解决了订单扣费异常问题，减轻了业务服务器对异常情况的复杂处理的负担。

此外，在本公开的示例性实施例中，还提供一种订单处理装置。图6示出了订单处理装置的结构示意图，如图6所示，订单处理装置600可以包括：状态查询模块610和信息发送模块620。其中：

状态查询模块610，被配置为响应业务服务器发送的针对订单扣费的查询信息，对订单的扣费状态进行查询处理；信息发送模块620，被配置为若查询处理得到的结果为订单扣费成功，向业务服务器发送异常信息，异常信息用于指示业务服务器对所述订单进行业务逻辑处理。

上述订单处理装置600的具体细节已经在对应的订单处理方法中进行了详细的描述，因此此处不再赘述。

应当注意，尽管在上文详细描述中提及了订单处理装置600的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

此外，在本公开的示例性实施例中，还提供了一种能够实现上述方法的电子设备。

下面参照图7来描述根据本发明的这种实施例的电子设备700。图7显示的电子设备700仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图7所示，电子设备700以通用计算设备的形式表现。电子设备700的组件可以包括但不限于：上述至少一个处理单元710、上述至少一个存储单元720、连接不同系统组件(包括存储单元720和处理单元710)的总线730、显示单元740。

其中，所述存储单元存储有程序代码，所述程序代码可以被所述处理单元710执行，使得所述处理单元710执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施例的步骤。

存储单元720可以包括易失性存储单元形式的可读介质，例如随机存取存储单元(ram)721和/或高速缓存存储单元722，还可以进一步包括只读存储单元(rom)723。

存储单元720还可以包括具有一组(至少一个)程序模块725的程序/实用工具724，这样的程序模块725包括但不限于：操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

总线730可以为表示几类总线结构中的一种或多种，包括存储单元总线或者存储单元控制器、外围总线、图形加速端口、处理单元或者使用多种总线结构中的任意总线结构的局域总线。

电子设备700也可以与一个或多个外部设备900(例如键盘、指向设备、蓝牙设备等)通信，还可与一个或者多个使得用户能与该电子设备700交互的设备通信，和/或与使得该电子设备700能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(i/o)接口750进行。并且，电子设备700还可以通过网络适配器760与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。如图所示，网络适配器740通过总线730与电子设备700的其它模块通信。应当明白，尽管图中未示出，可以结合电子设备700使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、raid系统、磁带驱动器以及数据备份存储系统等。

通过以上的实施例的描述，本领域的技术人员易于理解，这里描述的示例实施例可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施例的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是cd-rom，u盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、终端装置、或者网络设备等)执行根据本公开实施例的方法。

在本公开的示例性实施例中，还提供了一种计算机可读存储介质，其上存储有能够实现本说明书上述方法的程序产品。在一些可能的实施例中，本发明的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在终端设备上运行时，所述程序代码用于使所述终端设备执行本说明书上述“示例性方法”部分中描述的根据本发明各种示例性实施例的步骤。

参考图8所示，描述了根据本发明的实施例的用于实现上述方法的程序产品800，其可以采用便携式紧凑盘只读存储器(cd-rom)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、有线、光缆、rf等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如java、c++等，还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(lan)或广域网(wan)，连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其他实施例。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由权利要求指出。