CN105631621A - 分布式***中物流订单状态的控制方法及其*** - Google Patents

Abstract

本发明涉及分布式***应用领域，公开了一种分布式***中物流订单状态的控制方法及其***。本发明中，预先配置有物流订单状态流转表用于描述物流订单从不同的当前状态跳转到下一状态需要满足的条件，该方法包括步骤：当收到需要修改物流订单状态的消息时，根据当前状态查询物流订单状态流转表，判断接收的消息是否满足跳转到下一状态的条件；如果满足则从当前状态跳转到下一状态；如果不满足，则进行消息重试，使得该消息能够多次被接收，直到再次接收到该消息时，物流订单的当前状态已经能够使该消息满足使该物流订单跳转到下一状态的条件。本发明对物流订单的状态流转顺序进行有效控制，能够防止消息接收顺序错乱而导致的业务错误问题。

Description

分布式***中物流订单状态的控制方法及其***

技术领域

本发明涉及分布式***应用技术领域，特别涉及物流订单状态的控制技术。

背景技术

背景一、物流订单本身从被创建之后到完结，中间会经历若干种状态，这些状态可以是物流订单被下发到仓库，仓库处理打包，分发出仓，正式打包发货，以及订单被取消等等。但是对于已经分发出仓的订单，其状态只能是被拒单或者被签收，而不能取消；而流转到仓库且未出仓的订单可以被取消。总之对于这些订单状态流转可以看作是订单的生命周期，只能往前进，不能往后退。

背景二、大型电子商务***普遍建立在分布式***基础之上，每个业务都会有自己的独立的业务***。每个业务***一般通过消息中间件来实现业务数据最终一致性，而使用消息中间件就难免产生消息延迟，消息乱序问题。

例如，当物流公司先向物流中心***发出仓库打包处理的消息，再发出分发出仓的消息，但是因为各种网络原因或***原因，导致分发出仓的消息先于打包处理的消息到达物流中心***。若物流中心***无法判断分发出仓之前必须有仓内处理打包的过程，而先处理了分发出仓消息，再处理仓库打包处理，则会导致物流订单状态乱序。

背景三、大型电子商务***中物流***和商品交易***是非常独立的业务***。不同的物流运送方式，线上和线下的运送方式各不相同，但对于商品交易***只需了解物流订单是否已经创建、是否已经发货，是否已经签收等，不需关心具体仓内作业的过程，但必须要有一个明确统一的状态来告知。

发明内容

本发明的目的在于提供一种分布式***中物流订单状态的控制方法及其***，使得在分布式***架构下保证物流订单状态有序流转，防止消息接收顺序错乱而导致的业务错误问题。

为解决上述技术问题，本发明的实施方式公开了一种分布式***中物流订单状态的控制方法，分布式***的服务器中预先配置有物流订单状态流转表，该方法包括以下步骤：

当接收到需要修改物流订单状态的消息时，根据该物流订单的当前状态查询物流订单状态流转表，判断接收到的消息是否满足使物流订单从当前状态跳转到下一状态的条件；

如果满足条件，则将该物流订单从当前状态跳转到对应的下一状态；

如果不满足条件，则对消息进行消息重试，使得该消息能够多次被接收，直到再次接收到该消息时，物流订单的当前状态已经能够使该消息满足使该物流订单从当前状态跳转到下一状态的条件。

本发明的实施方式还公开了一种分布式***中物流订单状态的控制***，分布式***的服务器中预先配置有物流订单状态流转表，该***包括状态控制器，消息接收模块和消息重试模块：

状态控制器，用于当消息接收模块接收到需要修改物流订单状态的消息时，根据该物流订单的当前状态查询物流订单状态流转表，判断接收到的消息是否满足使物流订单从当前状态跳转到下一状态的条件；

如果满足条件，则将该物流订单从当前状态跳转到对应的下一状态；

如果不满足条件，则消息重试模块对消息进行消息重试，使得该消息能够多次被接收，直到消息接收模块再次接收到该消息时，物流订单的当前状态已经能够使该消息满足使该物流订单从当前状态跳转到下一状态的条件。

本发明实施方式与现有技术相比，主要区别及其效果在于：

本发明中对物流订单的状态流转顺序进行有效控制，在分布式***的多个业务***实现业务数据最终一致性时，能够防止消息接收顺序错乱而导致的业务错误问题。

进一步地，双物流状态的订单控制使得对物流中心***以外的***可以统一地表达物流状态。

进一步地，消息中间件将不能够推动物流订单进行状态跳转的消息进行缓存，并对缓存的消息进行重试，减轻了服务器的运行压力，避免了服务器资源浪费。

进一步地，通过外部辅助服务器来实现消息重试，即使没有可以利用的消息中间件，也可以实现消息存储和重试的功能，且避免了物流中心服务器实现消息重试所带来的***耦合性太高，高***复杂度的问题。

进一步地，物流订单状态流转表位于服务器缓存中，能够减轻数据库的压力，也可提高响应速度。

附图说明

图1是本发明第一实施方式中一种分布式***中物流订单状态的控制方法的流程示意图；

图2是本发明第二实施方式中一种分布式***中物流订单状态的控制方法的流程示意图；

图3是本发明第二实施方式中标准订单状态的生命周期图；

图4是本发明第二实施方式中业务订单状态，标准订单状态以及商品交易发货状态三者的关系图；

图5是本发明第二实施方式中双物流状态驱动的方案流程图；

图6是本发明第二实施方式中双物流状态驱动控制架构图；

图7是本发明第五实施方式中一种分布式***中物流订单状态的控制***的结构示意图。

具体实施方式

在以下的叙述中，为了使读者更好地理解本申请而提出了许多技术细节。但是，本领域的普通技术人员可以理解，即使没有这些技术细节和基于以下各实施方式的种种变化和修改，也可以实现本申请各权利要求所要求保护的技术方案。

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明的实施方式作进一步地详细描述。

本发明第一实施方式涉及一种分布式***中物流订单状态的控制方法，图1是该分布式***中物流订单状态的控制方法的流程示意图。

具体地说，该分布式***的服务器中预先配置有物流订单状态流转表，如图1所示，该方法包括以下步骤：

在步骤101中，当接收到需要修改物流订单状态的消息时，根据该物流订单的当前状态查询物流订单状态流转表，判断接收到的消息是否满足使物流订单从当前状态跳转到下一状态的条件。其中，物流订单状态流转表用于描述物流订单从不同的当前状态跳转到对应的下一状态需要满足的条件。

如果满足条件，则进入步骤102，将该物流订单从当前状态跳转到对应的下一状态。

如果不满足条件，则进入步骤103，对消息进行消息重试，使得该消息能够多次被接收，直到再次接收到该消息时，物流订单的当前状态已经能够使该消息满足使该物流订单从当前状态跳转到下一状态的条件。

此外，对消息进行消息重试，使得该消息能够多次被接收，需要注意的是，当该消息被再次接收时，物流订单的当前状态可能已经由于接收到其它消息而改变过了，使得最新的当前状态已经能够使该重试的消息满足使该物流订单从当前状态跳转到下一状态的条件。

大型电子商务***普遍建立在分布式***的基础之上，每个业务都会有自己的独立的业务***。比如物流中心***，商品交易***，发货***和仓库流转***，每个业务***一般通过一定方式来实现业务数据最终一致性，而在这其中就难免产生消息延迟，消息乱序问题。

本实施方式则通过对物流订单的状态流转顺序进行有效控制，在分布式***的多个业务***实现业务数据最终一致性时，能够防止消息接收顺序错乱而导致的业务错误问题。

本发明第二实施方式涉及一种分布式***中物流订单状态的控制方法，图2是该分布式***中物流订单状态的控制方法的流程示意图。

第二实施方式在第一实施方式的基础上进行了改进，主要改进之处在于：双物流状态的订单控制使得对物流中心***以外的***可以统一地表达物流状态；物流订单状态流转表位于服务器缓存中，能够减轻数据库的压力，也可提高响应速度。

具体地说，在一个优选例中，物流订单状态包括业务订单状态和标准订单状态，且预先配置的物流订单状态流转表还包括业务订单状态与标准订单状态之间的对应驱动关系。

在步骤102之后或者步骤103经过消息重试使得物流订单从当前状态跳转到对应的下一状态之后，还包括步骤104：根据业务订单状态与标准订单状态的对应驱动关系，驱动标准订单状态的更新。

可以理解，业务订单状态和标准订单状态构成了双物流状态。

其中，本发明所称的“业务订单状态”是指各种垂直业务自己的订单状态，每种不同的业务线都有不同的订单业务状态，如国内一般的快递发货只有一般的国内揽收和签收等状态，而海外物流则会有更复杂的业务订单状态，订单状态流转的步骤也会相应地更多。

大型电子商务***中物流***和商品交易***是非常独立的业务***。不同的物流运送方式，线上和线下运送方式各不相同，但对于商品交易***只需物流订单是否已经创建、是否已经发货，是否已经签收等，它不关心具体仓内作业的过程。

而本发明所称的“标准订单状态”则是针对上述商品交易***的需求从物流订单中抽象出来的一种表达方式，包括新建状态、发货中状态、已发货状态和已完结状态。其用于对物流***以外的***，例如商品交易***，统一地表达物流状态。

如图3所示为标准订单状态的生命周期图，在物流***中每个物流订单都有自己的生命周期，如图3所示为订单从新建到发货，到完结。而且非物流***相关的用户和***只关心这几个状态。

新建状态：当在用户没有任何发货行为之前，订单为新建状态；

发货中：当在用户有了发货行为，且物流公司没有确认揽收之前，订单属于发货中状态；

已发货状态：当物流公司揽收之后开始派送，订单处于已发货状态；

已完结状态：当物流订单被签收、被关闭、被取消，订单即属于已完结状态。

当物流订单从当前状态跳转到对应的下一状态之后，则可以根据业务订单状态与标准订单状态的对应驱动关系，驱动标准订单状态的更新。从而可以对外告知商品交易发货状态。业务订单状态，标准订单状态以及商品交易发货状态这三者的关系如图4所示，可以形象地表达为三个咬合的齿轮，业务订单状态的跳转能够驱动标准订单状态的改变，从而最终更新商品交易发货状态。

下面以物流行业中最简单的发货过程为例来对双物流状态控制进行进一步的详细说明。如图5所示为双物流状态驱动的方案流程图。

在没有自建物流体系的电子商务***中，商品交易***中卖家选择发货后，将步骤501中新建的物流订单下发到第三方物流公司，完成步骤502，此时物流订单的业务状态(即业务订单状态)应该是下发状态。但对于物流***以外的人或者***则只需认为此单正处于发货中，尚未完成发货。因此，当业务状态跳转为下发状态时，此状态驱动控制方案会将标准状态驱动为发货中的状态；

如果第三方物流公司接单(步骤503)，此时物流订单的业务状态跳转为接单状态，但是因为还未把包裹提交给第三方物流公司，所以此时的标准状态仍然是发货中的状态；

如果第三方物流公司拒单(步骤504)，则需要重新创建物流订单，此时物流订单的业务状态是重新创建状态，而物流***以外的人或者***都不需要了解重新创建的过程，因此仅需将物流订单的标准状态驱动为订单新建的状态即可(无论是否经过重新创建的状态)。

物流订单继续往前流转，等到第三方物流公司确认已经揽收到本包裹(步骤505)，此时物流订单的业务状态就是揽收状态，由此驱动控制方案就会将物流订单的标准状态驱动为已发货的状态。

物流订单此后分两种情况：

如果被签收(步骤506)，则物流订单的业务状态是签收状态；如果被拒签(步骤507)，则物流订单的业务状态是拒签状态。无论是签收还是拒签，物流***以外的人或者***只需认为此订单已完结，此状态驱动控制方案会将标准状态驱动为订单已完结的状态。

此外，物流订单状态流转表的数据读写比例非常高，一次统一的配置完成之后，除非业务发货流程变更，否则不会对状态流转表的配置进行变更。发货业务流程变更的机会相对很小，而这线上的每一笔订单的每次状态流转都需要根据这份配置判断当前流转是否合法，从而读取次数极其频繁。

针对上述问题，在另一优选例中，物流订单状态流转表位于服务器缓存中，如图6所示的双物流状态驱动控制架构图中，数据库中的订单流转配置(即物流订单状态流转表)位于服务器缓存中。物流订单状态流转表的数据读写次数极其频繁时，能够明显减轻数据库的压力，也可提高响应速度。

此外，分布式集群中每个服务器可以单独对外提供服务，状态控制器是这些服务器上的某一个功能，每次业务状态流转的调用都会通过状态控制器实现。通过选择使用服务器本地缓存，在服务启动时一次加载完成，就可以永久使用。

在本发明的其它实施方式中，物流订单状态流转表并不局限于位于服务器缓存中，也可以记录在数据库中。

此外考虑到物流发货类型不同时，订单状态流转也可能是不同的，如在线支付和货到付款的物流发货类型是不同的，国外订单和国内订单的物流发货类型也是不同的。

针对上述问题，在另一优选例中，物流订单状态流转表是根据物流发货类型进行预先配置的，不同物流发货类型对应不同的物流订单状态流转表。

相应地，在步骤101中，“当接收到物流订单的消息”之后，还包括步骤：

根据物流订单的消息，解析出物流订单的物流发货类型。

相应地，在步骤101中，“根据物流订单的当前状态查询物流订单状态流转表，判断接收到的消息是否满足使物流订单从当前状态跳转到下一状态的条件”中：

根据所解析出的物流发货类型查询相应的物流订单状态流转表，并根据该物流订单状态流转表判断物流订单的当前状态是否可以跳转到下一状态。

作为本实施方式的优选例，所有发货业务在使用状态控制器之前需要将对应的物流发货类型的状态流转情况(即物流订单状态流转表)配置到状态控制器中，详细描述其从某个状态可以跳转到可达状态的情况全部表达在状态控制器中。

当一个订单消息流转进入此状态控制器后，状态控制器会根据订单上不同的订单标记判断出对应的物流发货类型，然后***会根据不同的发货类型判断当前状态是否可以更新到目标状态，从而控制了消息乱序带来的问题。此外，在整个方案中主要包含两种物流订单状态，一个表示业务订单状态，另一个表示标准物流订单状态。若业务订单状态可以更新到目标状态，状态控制器会驱动标准物流订单状态的更新。

第一为了对物流订单状态流转进行有效控制，防止消息接收顺序错乱导致的业务错误问题；第二为了对物流***以外的***进行统一的表达物流状态，而引出了双物流状态下的订单驱动控制方案。应用此方案后第一可以保证物流订单状态在既定的状态间流转，从而保证订单状态总是向前进，而不会回退，不会因为消息乱序而导致后置的业务先执行；第二是使用双物流订单状态，对外部***进行统一的物流状态表达。

本发明第三实施方式涉及一种分布式***中物流订单状态的控制方法，第三实施方式在第一实施方式的基础上进行了改进，主要改进之处在于：通过消息中间件来实现消息重试的功能，消息中间件将不能够推动物流订单进行状态跳转的消息进行缓存，并对缓存的消息进行重试，减轻了服务器的运行压力，避免了服务器资源浪费。

具体地说，步骤103是通过消息中间件来实现的，该步骤包括以下子步骤：

消息发送方将物流订单的该消息发送至消息中间件；

消息中间件缓存该消息并对该消息进行重试，使得该消息能够多次被接收，直到该消息满足使该物流订单从当前状态跳转到下一状态的条件。

此外，可以理解，本发明所称的“消息中间件”利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式***的集成，可实现分布式***中可靠、高效、实时的数据传输。

在本发明中，消息中间件能够被多个业务***共用，比如发货***，仓库流转的***。多个业务***向物流中心***回传的消息都可以由消息中间件进行缓存和重试。

消息发送方在接收超时或者接收方返回异常，或者返回的错误码不是预期的错误码时，将不满足条件的消息发送至消息中间件，通过消息中间件即可实现消息的缓存和重试，减轻了服务器的运行压力，避免了服务器资源浪费。

本发明第四实施方式涉及一种分布式***中物流订单状态的控制方法，第四实施方式在第一实施方式的基础上进行了改进，主要改进之处在于：通过外部辅助服务器来实现消息重试的功能，即使没有可以利用的消息中间件，也可以实现消息存储和重试的功能，且避免了物流中心服务器实现消息重试所带来的***耦合性太高，高***复杂度的问题。

具体地说，步骤103包括以下子步骤：

将不满足使物流订单进行状态跳转的条件的消息存储在外部辅助服务器中；

当与该消息对应的物流订单的状态发生跳转时，则判断该消息是否满足使该物流订单从当前状态跳转到下一状态的条件，如果满足，则调用该消息并进行状态跳转。如果不满足则继续存储该消息，直到该消息满足状态跳转的条件。

在本实施方式中，消息重试是在一个外部辅助服务器中实现的，即使没有可以利用的消息中间件，可以开发一个超时任务调度中心来替代，且避免了物流中心服务器实现消息重试所带来的***耦合性太高，高***复杂度的问题。

本发明的各方法实施方式均可以以软件、硬件、固件等方式实现。不管本发明是以软件、硬件、还是固件方式实现，指令代码都可以存储在任何类型的计算机可访问的存储器中(例如永久的或者可修改的，易失性的或者非易失性的，固态的或者非固态的，固定的或者可更换的介质等等)。同样，存储器可以例如是可编程阵列逻辑(ProgrammableArrayLogic，简称“PAL”)、随机存取存储器(RandomAccessMemory，简称“RAM”)、可编程只读存储器(ProgrammableReadOnlyMemory，简称“PROM”)、只读存储器(Read-OnlyMemory，简称“ROM”)、电可擦除可编程只读存储器(ElectricallyErasableProgrammableROM，简称“EEPROM”)、磁盘、光盘、数字通用光盘(DigitalVersatileDisc，简称“DVD”)等等。

本发明第五实施方式涉及一种分布式***中物流订单状态的控制***，图7是该分布式***中物流订单状态的控制***的结构示意图。

具体地说，该分布式***的服务器中预先配置有物流订单状态流转表，如图7所示，该***包括状态控制器，消息接收模块和消息重试模块：

状态控制器，用于当消息接收模块接收到需要修改物流订单状态的消息时，根据该物流订单的当前状态查询物流订单状态流转表，判断接收到的消息是否满足使物流订单从当前状态跳转到下一状态的条件；如果满足条件，则将该物流订单从当前状态跳转到对应的下一状态；如果不满足条件，则消息重试模块对消息进行消息重试，使得该消息能够多次被接收，直到消息接收模块再次接收到该消息时，物流订单的当前状态已经能够使该消息满足使该物流订单从当前状态跳转到下一状态的条件。其中，物流订单状态流转用于描述物流订单从不同的当前状态跳转到对应的下一状态需要满足的条件。

此外，可以理解，对消息进行消息重试，使得该消息能够多次被接收，而当该消息被再次接收时，物流订单的当前状态可能已经由于接收到其它消息而改变过了，使得最新的当前状态已经能够使该重试的消息满足使该物流订单从当前状态跳转到下一状态的条件。

大型电子商务***普遍建立分布式***基础之上，每个业务都会有自己的独立的业务***。比如物流***，商品交易***，发货***和仓库流转***，每个业务***一般通过消息中间件来实现业务数据最终一致性，而使用消息中间件就难免产生消息延迟，消息乱序问题。

本实施方式针对上述问题对物流订单的状态流转顺序进行有效控制，在分布式***的多个业务***实现业务数据最终一致性时，能够防止消息接收顺序错乱而导致的业务错误问题。

第一实施方式是与本实施方式相对应的方法实施方式，本实施方式可与第一实施方式互相配合实施。第一实施方式中提到的相关技术细节在本实施方式中依然有效，为了减少重复，这里不再赘述。相应地，本实施方式中提到的相关技术细节也可应用在第一实施方式中。

本发明第六实施方式涉及一种分布式***中物流订单状态的控制***，第六实施方式在第五实施方式的基础上进行了改进，主要改进之处在于：双物流状态的订单控制使得对物流中心***以外的***可以统一地表达物流状态；物流订单状态流转表位于服务器缓存中，能够减轻数据库的压力，也可提高响应速度。

具体地说，在一个优选例中，物流订单状态包括业务订单状态和标准订单状态。预先配置的物流订单状态流转表还包括业务订单状态与标准订单状态之间的对应驱动关系。

状态控制器将该物流订单从当前状态跳转到下一状态后，还用于根据业务订单状态与标准订单状态的对应驱动关系，驱动标准订单状态的更新。

可以理解，业务订单状态和标准订单状态构成了双物流状态。

此外，物流订单状态流转表的数据读写比例非常高，一次统一的配置完成之后，除非业务发货流程变更，否则不会对状态流转表的配置进行变更。发货业务流程变更的机会相对很小，而这线上的每一笔订单的每次状态流转都需要根据这份配置判断当前流转是否合法，从而读取次数极其频繁。

针对上述问题，在另一优选例中，物流订单状态流转表位于服务器缓存中，能够明显减轻数据库的压力，也可提高响应速度。

在本发明的其它实施方式中，物流订单状态流转表并不局限于位于服务器缓存中，也可以记录在数据库中。

此外考虑到物流发货类型不同时，订单状态流转也可能是不同的，如在线支付和货到付款的物流发货类型是不同的，国外订单和国内订单的物流发货类型也是不同的。

针对上述问题，在另一优选例中，物流订单状态流转表是根据物流发货类型进行预先配置的，不同物流发货类型对应不同的物流订单状态流转表。

相应地，还包括解析模块，用于根据物流订单的消息，解析出物流订单的物流发货类型。在状态控制器中，根据解析模块所解析出的物流发货类型查询相应的物流订单状态流转表，并根据该物流订单状态流转表判断物流订单的当前状态是否可以跳转到下一状态。

第二实施方式是与本实施方式相对应的方法实施方式，本实施方式可与第二实施方式互相配合实施。第二实施方式中提到的相关技术细节在本实施方式中依然有效，为了减少重复，这里不再赘述。相应地，本实施方式中提到的相关技术细节也可应用在第二实施方式中。

本发明第七实施方式涉及一种分布式***中物流订单状态的控制***，第七实施方式在第五实施方式的基础上进行了改进，主要改进之处在于：通过消息中间件来实现消息重试的功能，消息中间件将不能够推动物流订单进行状态跳转的消息进行缓存，并对缓存的消息进行重试，减轻了服务器的运行压力，避免了服务器资源浪费。

具体地说，消息重试模块是通过外部的消息中间件来实现的，消息中间件包括以下子模块：

消息接收子模块，用于接收消息发送方发送的物流订单的消息。

缓存和重试子模块，用于缓存该消息并对该消息进行重试，使得该消息能够多次被接收，直到该消息满足使该物流订单从当前状态跳转到下一状态的条件。

此外，可以理解，本发明所称的“消息中间件”利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式***的集成，可实现分布式***中可靠、高效、实时的数据传输。

在本发明中，消息中间件能够被多个业务***共用，比如发货***，仓库流转的***。多个业务***向物流中心***回传的消息都可以由消息中间件进行缓存和重试。

消息发送方在接收超时或者接收方返回异常，或者返回的错误码不是预期的错误码时，将不满足条件的消息发送至消息中间件，通过消息中间件即可实现消息的缓存和重试。减轻了服务器的运行压力，避免了服务器资源浪费。

第三实施方式是与本实施方式相对应的方法实施方式，本实施方式可与第三实施方式互相配合实施。第三实施方式中提到的相关技术细节在本实施方式中依然有效，为了减少重复，这里不再赘述。相应地，本实施方式中提到的相关技术细节也可应用在第三实施方式中。

本发明第八实施方式涉及一种分布式***中物流订单状态的控制***，第八实施方式在第五实施方式的基础上进行了改进，主要改进之处在于：通过将消息存储在外部辅助服务器中来实现消息重试的功能。

具体地说，消息重试模块是在外部辅助服务器实现的，包括以下子模块：

存储子模块，用于将不满足使物流订单进行状态跳转的条件的消息存储在外部辅助服务器中；

判断与调用子模块，用于当与该消息对应的物流订单的状态发生跳转时，则判断该消息是否满足使该物流订单从当前状态跳转到下一状态的条件，如果满足，则调用该消息并进行状态跳转。如果不满足则继续存储该消息，直到该消息满足状态跳转的条件。

第四实施方式是与本实施方式相对应的方法实施方式，本实施方式可与第四实施方式互相配合实施。第四实施方式中提到的相关技术细节在本实施方式中依然有效，为了减少重复，这里不再赘述。相应地，本实施方式中提到的相关技术细节也可应用在第四实施方式中。

需要说明的是，本发明各设备实施方式中提到的各模块都是逻辑模块，在物理上，一个逻辑模块可以是一个物理模块，也可以是一个物理模块的一部分，还可以以多个物理模块的组合实现，这些逻辑模块本身的物理实现方式并不是最重要的，这些逻辑模块所实现的功能的组合才是解决本发明所提出的技术问题的关键。此外，为了突出本发明的创新部分，本发明上述各设备实施方式并没有将与解决本发明所提出的技术问题关系不太密切的模块引入，这并不表明上述设备实施方式并不存在其它的模块。

需要说明的是，在本专利的权利要求和说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

虽然通过参照本发明的某些优选实施方式，已经对本发明进行了图示和描述，但本领域的普通技术人员应该明白，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。

Claims (11)

1.一种分布式***中物流订单状态的控制方法，其特征在于，所述分布式***的服务器中预先配置有物流订单状态流转表，所述方法包括以下步骤：

当接收到需要修改物流订单状态的消息时，根据物流订单的当前状态查询所述物流订单状态流转表，判断所述接收到的消息是否满足使物流订单从当前状态跳转到下一状态的条件；

如果满足所述条件，则将物流订单从当前状态跳转到对应的下一状态；

如果不满足所述条件，则对所述消息进行消息重试，使得所述消息能够多次被接收，直到再次接收到所述消息时，物流订单的当前状态已经能够使所述消息满足使物流订单从当前状态跳转到下一状态的条件。

2.根据权利要求1所述的分布式***中物流订单状态的控制方法，其特征在于，所述物流订单状态包括业务订单状态和标准订单状态；所述预先配置的物流订单状态流转表还包括所述业务订单状态与所述标准订单状态之间的对应驱动关系；

在所述将所述物流订单从当前状态跳转到下一状态的步骤之后，还包括步骤：根据所述业务订单状态与所述标准订单状态的对应驱动关系，驱动所述标准订单状态的更新。

3.根据权利要求1所述的分布式***中物流订单状态的控制方法，其特征在于，所述“如果不满足所述条件，则对所述消息进行消息重试，使得所述消息能够多次被接收，直到再次接收到所述消息时，物流订单的当前状态已经能够使所述消息满足使物流订单从当前状态跳转到下一状态的条件”的步骤是通过消息中间件来实现的，所述步骤包括以下子步骤：

所述消息发送方将物流订单的所述消息发送至消息中间件；

消息中间件缓存所述消息并对消息进行重试，使得所述消息能够多次被接收，直到所述消息满足使物流订单从当前状态跳转到下一状态的条件。

4.根据权利要求1所述的分布式***中物流订单状态的控制方法，其特征在于，所述“如果不满足所述条件，则对所述消息进行消息重试，使得所述消息能够多次被接收，直到再次接收到所述消息时，物流订单的当前状态已经能够使所述消息满足使物流订单从当前状态跳转到下一状态的条件”的步骤是通过外部辅助服务器来实现的，所述步骤包括以下子步骤：

将所述不满足使物流订单进行状态跳转的条件的消息存储在所述外部辅助服务器中；

当与所述消息对应的物流订单的状态发生跳转时，则判断所述消息是否满足使物流订单从当前状态跳转到下一状态的条件，如果满足，则调用所述消息并进行状态跳转；如果不满足则继续存储消息，直到所述消息满足状态跳转的条件。

5.根据权利要求1所述的分布式***中物流订单状态的控制方法，其特征在于，所述物流订单状态流转表位于服务器缓存中。

6.根据权利要求1至5中任一项所述的分布式***中物流订单状态的控制方法，其特征在于，所述物流订单状态流转表是根据物流发货类型进行预先配置的，不同物流发货类型对应不同的物流订单状态流转表；

在所述“当接收到物流订单的消息”的步骤之后，还包括步骤：

根据所述物流订单的消息，解析出物流订单的物流发货类型；

在所述“根据物流订单的当前状态查询所述物流订单状态流转表，判断所述接收到的消息是否满足使物流订单从当前状态跳转到下一状态的条件”的步骤中：

根据所解析出的物流发货类型查询相应的物流订单状态流转表，并根据所述物流订单状态流转表判断所述物流订单的当前状态是否可以跳转到下一状态。

7.一种分布式***中物流订单状态的控制***，其特征在于，所述分布式***的服务器中预先配置有物流订单状态流转表，所述***包括状态控制器，消息接收模块和消息重试模块：

状态控制器，用于当所述消息接收模块接收到需要修改物流订单状态的消息时，根据物流订单的当前状态查询所述物流订单状态流转表，判断所述接收到的消息是否满足使物流订单从当前状态跳转到下一状态的条件；

如果满足所述条件，则将物流订单从当前状态跳转到对应的下一状态；

如果不满足所述条件，则所述消息重试模块对所述消息进行消息重试，使得所述消息能够多次被接收，直到所述消息接收模块再次接收到所述消息时，物流订单的当前状态已经能够使所述消息满足使物流订单从当前状态跳转到下一状态的条件。

8.根据权利要求7所述的分布式***中物流订单状态的控制***，其特征在于，所述物流订单状态包括业务订单状态和标准订单状态；所述预先配置的物流订单状态流转表还包括所述业务订单状态与所述标准订单状态之间的对应驱动关系；

所述状态控制器将所述物流订单从当前状态跳转到下一状态后，还用于根据所述业务订单状态与所述标准订单状态的对应驱动关系，驱动所述标准订单状态的更新。

9.根据权利要求7所述的分布式***中物流订单状态的控制***，其特征在于，所述消息重试模块是通过外部的消息中间件来实现的，所述消息中间件包括以下子模块：

消息接收子模块，用于接收所述消息发送方发送的物流订单的消息；

缓存和重试子模块，用于缓存所述消息并对所述消息进行重试，使得所述消息能够多次被接收，直到所述消息满足使物流订单从当前状态跳转到下一状态的条件。

10.根据权利要求7所述的分布式***中物流订单状态的控制***，其特征在于，所述消息重试模块是通过外部辅助服务器实现的，包括以下子模块：

存储子模块，用于将所述不满足使物流订单进行状态跳转的条件的消息存储在所述外部辅助服务器中；

判断与调用子模块，用于当与所述消息对应的物流订单的状态发生跳转时，判断所述消息是否满足使物流订单从当前状态跳转到下一状态的条件，如果满足，则调用所述消息并进行状态跳转；如果不满足则继续存储消息，直到所述消息满足状态跳转的条件。

11.根据权利要求7至10中任一项所所述的分布式***中物流订单状态的控制***，其特征在于，所述物流订单状态流转表是根据物流发货类型进行预先配置的，不同物流发货类型对应不同的物流订单状态流转表；

还包括解析模块，用于根据所述物流订单的消息，解析出物流订单的物流发货类型；

在所述状态控制器中，根据所述解析模块所解析出的物流发货类型查询相应的物流订单状态流转表，并根据所述物流订单状态流转表判断所述物流订单的当前状态是否可以跳转到下一状态。