CN111488236B - 一种订单异常处理方法、服务器、存储介质及处理装置 - Google Patents

Abstract

本发明公开了一种订单异常处理方法，包括接收来自前端的订单处理请求；对所述订单进行第一环节处理；判断所述第一环节的消息队列中是否有异常事件；若是，验证导致所述异常事件产生的问题是否存在；若是，按预设规则重复验证过程，当达到人工处理条件时，经人工处理后，对所述订单进行第二环节处理；若否，重复前述过程，直到所述第一环节的消息队列中没有异常事件，对所述订单进行第二环节处理。本发明进一步提供了一种服务器、存储介质及处理装置。本发明通过标准化、通用化的异常处理机制，不仅提升了程序开发效率，而且提升了系统的可靠性。

Description

一种订单异常处理方法、服务器、存储介质及处理装置

技术领域

本发明涉及电子商务领域，尤其涉及一种订单异常处理方法、存储介质及处理装置。

背景技术

电子商务领域的订单处理一般都是通过订单处理系统接收来自前端的订单请求，通过自动化的订单分发过程，选择合适的业务系统或者人进行订单下发和订单处理工作。

为了提升性能，订单处理一般采取异步消息的模式。这种处理模式的优点是订单吞吐量大，缺点是一个流程分解成多个环节后，从短流程变成了长流程，从而导致多个环节中可能存在的多种异常处理问题，及订单数据在经过不同环节异常处理后存在的不一致问题。

针对订单处理在订异步消息模式下存在的上述缺点，业界急需一种能够对不同环节异常问题进行标准化、通用化的处理方法。

发明内容

针对现有技术的不足，本发明所要解决的技术问题是提供一种订单异常处理方法，通过标准化的异常处理流程使多环节中可能存在的多种异常采用同一种异常处理方式解决，从而提升整个流程中异常处理的整体效率，并有效改进不同环节异常处理的一致性问题。本发明进一步提供了一种服务器、存储介质及处理装置，均用于对上述方法在实际场景下的实现。

本发明解决上述技术问题的技术方案如下：

根据本发明实施例的一个方面，一种订单异常处理方法，包括：

S10：接收来自前端的订单处理请求；

S11：对所述订单进行第一环节处理；

S12：判断所述第一环节的消息队列中是否有异常事件；

S13：若是，验证导致所述异常事件产生的问题是否存在；

S14：若是，按预设规则重复步骤S13的验证过程，当达到人工处理条件时，经人工处理后，对所述订单进行第二环节处理；

S15：若否，重复步骤S11-S13的过程，直到所述第一环节的消息队列中没有异常事件，对所述订单进行第二环节处理。

进一步的，所述异常事件包括数据库DB异常事件和数据库管理系统MQ异常事件，所述DB异常事件由DB异常产生，所述MQ异常事件由MQ异常产生，所述DB异常事件或MQ异常事件发生后生成相应的异常事件消息，并进入到当前环节的消息队列中。

进一步的，所述步骤S13包括：根据所述异常事件发生后生成的异常事件消息的编码查找导致该异常事件的问题，并进一步判断该问题是否已经消除。

进一步的，所述步骤S14中所述预设规则包括：按预设时间间隔，如每次间隔1分钟、5分钟、1小时或1天，重复步骤S13的验证过程，所述时间间隔可根据实际需要进行组合。

进一步的，所述对所述订单进行第二环节处理的过程包括：

将所述第二环节作为新的第一环节，将所述第二环节的一下环节作为新的第二环节，并重复步骤S11-S15。

进一步的，所述各环节处理中的异常事件处理均支持幂等。

根据本发明实施例的另一方面，一种服务器，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行订单异常处理程序，所述订单异常处理程序被所述处理器执行时实现上述任一项所述的订单异常处理方法的步骤。

根据本发明实施例的另一方面，一种存储介质，所述存储介质上存储有订单异常处理程序，所述订单异常处理程序被处理器执行时实现上述任一项所述的订单异常处理方法的步骤。

根据本发明实施例的另一方面，一种订单异常处理装置，包括：

接收模块，用于接收来自前端的订单处理请求；

第一环节处理模块，用于对所述订单进行第一环节处理，并从所述第一环节的消息队列中获取异常事件；

异常判断模块，用于判断所述第一环节处理的消息队列中是否有异常事件；

异常处理模块，用于验证所述第一环节处理中导致所述异常事件产生的问题是否存在，若存在，按预设规则重复验证，当达到人工处理条件时，触发人工处理请求；若不存在，重复所述第一环节处理过程，直到所述第一环节的消息队列中没有异常事件；

人工处理模块，用于响应所述异常处理模块中的人工处理请求，进行所述异常事件的人工处理。

本发明的有益效果在于：通过标准化、通用化的异常处理机制，不仅提升了程序开发效率，而且提升了系统的可靠性。有效避免了传统分布式系统异常处理方法，交互复杂、种类繁多，每个环节处理都要有定制化的异常处理程序，不仅耗时耗力，而且非常容易出错的问题。

本发明附加的方面的优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明实践了解到。

附图说明

图1为本发明实施例涉及的硬件运行环境的服务器结构示意图；

图2为本发明方法实施例的流程示意图；

图3为本发明方法实施例的工作框图；

图4为本发明产品实施例的结构框图。

具体实施方式

以下结合附图对本发明的原理和特征进行描述，所举实施例只用于解释本发明，并非用于限定本发明的范围。

参照图1，图1为本发明实施例涉及的硬件运行环境的服务器结构示意图。

如图1所示，该服务器可以包括：处理器1001，例如CPU，通信总线1002、用户接口1003，网络接口1004，存储器1005。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)，可选用户接口1003还可以包括标准的有线接口、无线接口，对于用户接口1003的有线接口在本发明中可为USB接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1005可以是高速RAM存储器，也可以是稳定的ROM存储器，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。

本领域技术人员可以理解，图1中示出的结构并不构成对服务器的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图1所示，作为一种计算机存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及订单异常处理程序。

在图1所示的服务器中，网络接口1004主要用于连接后台服务器，与所述后台服务器进行数据通信；用户接口1003主要用于连接前端设备；所述服务器通过处理器1001调用存储器1005中存储的订单异常处理程序，并执行本发明实施例提供的订单异常处理方法。

基于上述硬件结构，提出本发明订单异常处理方法的实施例。

参照图2，图2为本发明订单异常处理方法实施例的流程示意图。

如图2所示，所述订单异常处理方法包括以下步骤：

S10：接收来自前端的订单处理请求；

可以理解的是，所述前端为生成订单的客户端，所述订单处理请求经由客户端用户接口1003、通信总线1002、网络接口1004，最后到达后台服务器。

S11：对所述订单进行第一环节处理；

可以理解的是，此处的第一环节并非专指整个订单处理的头一个环节，而是相对下一个环节而言，称为第一环节处理，同时相应的，后续步骤中所述的第二环节处理，即是此处所述第一环节的下一个环节。

S12：判断所述第一环节的消息队列中是否有异常事件；

可以理解的是，本步骤的判断主体为订单接入的处理系统或由系统提供的异常事件判断程序来完成。

参照图3，图3为本发明方法实施例的工作框图；

进一步的，所述异常事件包括数据库DB异常事件和数据库管理系统MQ异常事件，所述DB异常事件由DB异常产生，所述MQ异常事件由MQ异常产生，所述DB异常事件或MQ异常事件发生后生成相应的异常事件消息，并进入到当前环节的消息队列中。

可以理解的是，此处异常事件的各类只是例举而非穷举，但常见的异常事件多属于由数据库DB异常导致的异常事件和数据库管理系统MQ异常导致的异常事件，另外，也有链路中断导致的异常等。

S13：若是，验证导致所述异常事件产生的问题是否存在；

进一步的，根据所述异常事件发生后生成的异常事件消息的编码查找导致该异常事件的问题，并进一步判断该问题是否已经消除。

可以理解的是，订单处理的不同环节可能会出现不同的异常事件，但每一种异常事件能产生异常消息的异常事件都会在消息队列中带有该异常事件的编码，以指示导致该异常事件的相应问题，以方便系统或异常处理程序进一步判断该问题是否已经消除。

S14：若是，按预设规则重复步骤S13的验证过程，当达到人工处理条件时，经人工处理后，对所述订单进行第二环节处理；

进一步的，所述预设规则包括：按预设时间间隔，如每次间隔1分钟、5分钟、1小时或1天，重复步骤S13的验证过程，所述时间间隔可根据实际需要进行组合。

可以理解的是，该步骤是指经系统或异常处理程序根据异常事件的编码验证导致异常事件的问题后，确定问题已然存在，然后就按照预设规则，比如每隔1分钟、5分钟、1小时或1天重复验证一次，而且该验证策略还可以根据实际需要以不同时间间隔的组合进行。当达到人工处理条件，经由人工处理后就结束了该环节的订单处理，而进入到了一个环节中。

S15：若否，重复步骤S11-S13的过程，直到所述第一环节的消息队列中没有异常事件，对所述订单进行第二环节处理。

可以理解的是，重复步骤S11-S13的过程中每次验证时都会有两种情况，第一种是问题还存在，第二种是问题不存在了。如果多次验证都是第一种情况，则进行人工处理；如果在没达到人工处理条件前的某次验证结果为第二种情况，则说明第一环节处理中的问题已不存在，也即第一环节进行了正常处理，即可自动进入到一环节的处理了。该步骤的结果就是指经系统或异常处理程序根据异常事件的编码验证导致异常事件的问题后确定问题已经消失，因为相应的问题已经消失，所以在执行完所述第一环节的处理后，就自动进入到了对所述订单的第二环节处理。

进一步的，所述对所述订单进行第二环节处理的过程包括：

将所述第二环节作为新的第一环节，将所述第二环节的一下环节作为新的第二环节，并重复步骤S11-S15。

可以理解的是，本实施例所述的订单异常处理方法是一种标准化、通用化的异常处理方法，所以实际上，该订单异常处理方法在订单处理的每个环节处理上采用的异常处理的方法和流程都是一样的。也即如果将某个环节处理作为第一环节处理，那么它的下一个环节处理就是第二环节处理。如果将该第二环节处理作为新的第一环节处理，那么它的下一个环节处理就是新的第二环节处理。亦即在所述订单处理过程的每个环节处理上所采用的异常处理方法都是一致的。

进一步的，所述各环节处理中的异常事件处理均支持幂等。

所谓幂等性是指，一次和多次请求某一个资源对于资源本身应该具有同样的结果。也就是说，任意多次执行对资源本身所产生的影响均与一次执行的影响相同。在分布式环境下，系统之间不同服务的相互调用，需要满足幂等性要求，幂等性是系统服务对外一种承诺(而不是实现)，承诺只要调用接口成功，外部多次调用对系统的影响是一致的，声明为幂等的服务会认为外部调用失败是常态，并且失败之后必然会有重试。

可以理解的是，在本实施例中所谓的支持幂等是指在进行反复验证和异常处理时，如果出现连续多次的信号请求，则只接收并执行其中某一次的请求。

现有技术中当出现订单异常时，由于导致订单异常的原因多种多样，为了防止操作失误，可先对该异常订单进行挂起不继续执行，再诉诸于人工处理该异常，订单异常的处理方式较为低效。本实施例是通过标准化订单异常处理方法，即每个环节处理的异常处理方法都是通用化、标准化的，改进现有技术的订单异常处理方式，从而提高订单异常的处理效率。

实施例2

参照图4，图4为本发明产品实施例的结构框图。

如图4所示，一种订单异常处理装置，包括：

接收模块401，用于接收来自前端的订单处理请求；

可以理解的是，接收模块401的功能对应的是方法实施例中的步骤10，订单处理系统通过该功能模块实现对订单处理请求的接收和响应。

第一环节处理模块402，用于对所述订单进行第一环节处理，并从所述第一环节的消息队列中获取异常事件；

可以理解的是，第一环节处理模块402的功能对应的是方法实施例中的步骤11，即通过该模块完成对订单第一环节的处理。

异常判断模块403，用于判断所述第一环节处理的消息队列中是否有异常事件；

可以理解的是，异常判断模块403的功能对应的是方法实施例中的步骤12，该模块功能具体可由订单处理系统中的异常处理程序来执行。

异常处理模块404，用于验证所述第一环节处理中导致所述异常事件产生的问题是否存在，若存在，按预设规则重复验证，当达到人工处理条件时，触发人工处理请求；若不存在，重复所述第一环节处理过程，直到所述第一环节的消息队列中没有异常事件；

可以理解的是，异常处理模块404的功能对应的是方法实施例中的步骤13至步骤15，该模块功能也是由订单处理系统中的异常处理程序来执行。

人工处理模块405，用于响应所述异常处理模块中的人工处理请求，进行所述异常事件的人工处理。

可以理解的是，人工处理模块405，实际上是基于人工处理的一个工作模块，该模块功能对应的是方法实施例中步骤S14中，当达到人工处理条件时，经人工处理的部分。

本产品实施例实际上是通过功能模块对方法实施例进一步具体化的表述，其技术构思和实施方式与方法实施例中描述的方法流程可互为参照。

读者应理解，在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的方法实施例仅仅是示意性的，例如，步骤的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个步骤可以结合或者可以集成到另一个步骤，或一些特征可以忽略，或不执行。

上述方法如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分，或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，RandomAccessMemory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims (8)

1.一种订单异常处理方法，其特征在于，包括：

S10：接收来自前端的订单处理请求；

S11：对所述订单进行第一环节处理；

S12：判断所述第一环节的消息队列中是否有异常事件；

S13：若是，验证导致所述异常事件产生的问题是否存在；

S14：若是，按预设规则重复步骤S13的验证过程，当达到人工处理条件时，经人工处理后，对所述订单进行第二环节处理；

S15：若否，重复步骤S11-S13的过程，直到所述第一环节的消息队列中没有异常事件，对所述订单进行第二环节处理；

所述对所述订单进行第二环节处理的过程包括：

将所述第二环节作为新的第一环节，将所述第二环节的下一环节作为新的第二环节，并重复步骤S11-S15。

2.根据权利要求1所述的方法，其特征在于，所述异常事件包括数据库DB异常事件和数据库管理系统MQ异常事件，所述DB异常事件由DB异常产生，所述MQ异常事件由MQ异常产生，所述DB异常事件或MQ异常事件发生后生成相应的异常事件消息，并进入到当前环节的消息队列中。

3.根据权利要求1或2所述的方法，其特征在于，所述步骤S13包括：根据所述异常事件发生后生成的异常事件消息的编码查找导致该异常事件的问题，并进一步判断该问题是否存在。

4.根据权利要求1或2所述的方法，其特征在于，所述步骤S14中所述预设规则包括：按以下预设时间间隔，至少包括以下之一：每次间隔1分钟、5分钟、1小时或1天，重复步骤S13的验证过程。

5.根据权利要求4所述的方法，其特征在于，所述各环节处理中的异常事件处理均支持幂等。

6.一种服务器，其特征在于，包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行订单异常处理程序，所述订单异常处理程序被所述处理器执行时实现如权利要求1至5中任一项所述的订单异常处理方法的步骤。

7.一种存储介质，其特征在于，所述存储介质上存储有订单异常处理程序，所述订单异常处理程序被处理器执行时实现如权利要求1至5中任一项所述的订单异常处理方法的步骤。

8.一种订单异常处理装置，其特征在于，包括：

接收模块，用于接收来自前端的订单处理请求；

第一环节处理模块，用于对所述订单进行第一环节处理，并从所述第一环节的消息队列中获取异常事件；

异常判断模块，用于判断所述第一环节处理的消息队列中是否有异常事件；

异常处理模块，用于验证所述第一环节处理中导致所述异常事件产生的问题是否存在，若存在，按预设规则重复验证，当达到人工处理条件时，触发人工处理请求；若不存在，重复所述第一环节处理过程，直到所述第一环节的消息队列中没有异常事件；

人工处理模块，用于响应所述异常处理模块中的人工处理请求，进行所述异常事件的人工处理；

第二环节处理模块，用于经人工处理后，对所述订单进行第二环节处理，将所述第二环节作为新的第一环节，将所述第二环节的下一环节作为新的第二环节。