一种保证司机状态和订单状态变化一致性的方法和系统

摘要

本发明公开了一种保证司机状态和订单状态变化一致性的方法，包括：S1.监听订单状态变化事件；S2.对比判断接收到的订单的状态和对应的司机，以及当前司机服务中的订单；S3.根据订单类型和状态以及司机当前状态以及服务中的订单，判断是否变更司机状态，以及变更后的司机状态；S4.判断司机状态是否有变化，若有变化则改派订单并更新服务中的订单，再更新数据库和缓存，若无变化则直接更新数据库和缓存；S5.向其他关联模块发送司机状态变更的消息通知；S6.司机在停止听单的时候，操作开始听单，在开始听单，没有派单的时候，操作停止听单。本发明保证用户行为或系统自动触发订单状态流转成功时，司机状态也流转到正确状态，使司机状态和订单状态变化一致。

说明书

技术领域

本发明属于数据处理技术领域，具体涉及一种保证司机状态和订单状态变化一致性的方法和系统。

背景技术

随着城市的飞速发展，城市交通的短板日益浮现，尤其是城市交通中公路客运对于乘客来说没有足够的自主性以及个性化。虽然城市交通作为一种方式已经很完善了，但是对于提倡绿色出行的当下，已有的城市交通已经无法很好的满足人们的需求，一板一眼的城市交通无法满足当前追求定制化、个性化出行方面的需求。

网约车平台将人、出租车和私家车连接起来，形成一个“人-车”自主连接的服务网，满足了人们的需求并且极大的填补了城市交通的短板，随着网约车逐渐被广大群众认可，打车的市民越来越多。

网约车的订单状态和司机状态的变化，一般是乘客或者司机在客户端进行某种行为性触发的时候(比如乘客下单，系统派单成功，司机出发接乘客，司机结束服务)，通过RPC依次调用各个服务(比如风控、派单、订单、司机服务)各个服务进行各自业务操作，更新数据(比如订单状态，司机状态)，期间系统调用复杂，各个环节都可能存在上一个环节成功，下一个操作失败的情况。这样就会导致订单状态和司机状态变化的不一致，数据错误补偿困难。

比如派单系统在成功后调用司机服务改变司机状态，但是在调用订单服务改变订单状态的时候由于订单服务的逻辑，或者是网络问题导致订单服务状态变化失败，乘客没有派到单，但是司机处于服务中。就算是先调用订单服务改变订单状态再去调用司机服务改变司机状态也会存在类似的问题导致司机状态流转成功，但是订单状态流转失败。上述原因就会导致出现司机状态和订单状态变化不一致的情形，导致系统的可靠性降低，影响司机和乘客使用网约车平台的体验。

发明内容

本发明的目的是要解决司机状态和订单状态变化不一致的技术问题，提供一种保证司机状态和订单状态变化一致性的方法，包括以下步骤：

一种保证司机状态和订单状态变化一致性的方法，其特征是：

如果是订单变更触发的司机状态变化，则执行以下步骤：

S1.监听订单状态变化事件；

S2.对比判断接收到的订单的状态和对应的司机，以及当前司机服务中的订单；

S3.根据订单类型和状态以及司机当前状态以及服务中的订单，判断是否变更司机状态，以及变更后的司机状态；

S4.若司机状态有变化则判断该订单当前对应的司机和之前服务的司机是否一致，如果不一致则表示是改派订单，需要改变订单当前对应司机状态以及之前对应的司机状态；

S5.如果司机状态有变化，则更新数据库和缓存；

如果是司机直接操作开始听单和结束听单时触发的司机状态变化，则执行以下步骤：

SS1.司机在停止听单状态的时候，操作开始听单，则司机状态变为开始听单；

SS2.司机在开始听单状态的时候，操作停止听单，则司机状态变为停止听单。

作为优选方案，S2步骤中对比判断处于司机服务中的订单的步骤为：

(a)、从状态变化的订单中获取对应的订单号和司机号；

(b)、从司机数据库获取处于司机服务中的订单；

(c)、通过比对判断订单数据库中状态发生变化的订单是否是(b)步骤中获取的处于司机服务中的订单；

(d)、若判断为“是”，则确认更改司机状态，若判断为“否”，则不更改当前司机状态。

作为优选方案：S3步骤中对于预约订单当司机出发后将司机状态变更为服务中，对于取消的订单，若司机已出发，则将司机状态变更为停止听单，对于结束的订单，将司机的状态变更为停止听单；对于实时订单，当派单结束或司机出发后，将司机的状态变更为服务中，对于取消对订单，将司机状态变更为停止听单，订单结束后，将司机状态变更为停止听单。

作为优选方案，S4步骤中对于改派订单：根据订单ID查询司机接单配置表；判断订单ID是否有对应的司机，若为“是”，则解除之前订单对应的司机和该订单的对应关系，并更新服务中的订单为0，同时更新数据库和缓存；若为“否”，则直接更新服务中的订单。

作为优选方案：在司机没有订单的时候，直接有司机行为触发司机状态变化。

作为优选方案：司机和订单有关联以及解除关联的时候，由订单服务在订单状态变更成功的时候发送订单状态变更事件消息，司机服务监听该事件，改变司机状态。

一种保证司机状态和订单状态变化一致性的系统，包括：

订单数据库，用于存储订单数据；

司机数据库，用于存储司机数据；

监听模块，用于监听订单数据库内的订单状态的变化以及监听司机数据库内的和司机状态的变化；

比对模块，用于将订单数据库内的处于司机服务的订单与司机数据库内司机服务中的订单进行比对。

与现有技术相比，本发明的有益效果是：通过本方法，当司机和订单有关联以及解除关联的时候将司机状态变化和订单状态相关联，来避免整体的流程在多次系统交互中间出问题，而导致司机状态与订单状态流转不一致的问题；利用事件消息的最少一次投放的特性，通过发送事件消息来避免短暂的网络和系统无法快速响应导致的调用失败的问题；保证用户行为或者系统自动触发订单状态流转成功的时候，司机状态也能流转到正确的状态，降低司机状态流转错误概率，提升司机收益；乘客下实时单之后，派单给司机，派单成功之后，订单状态流转为派单成功，司机状态流转为服务中；派单成功后，如果乘客取消实时单，订单状态流转为订单取消，司机状态流转为停止听单；如果司机结束服务，订单状态流转为服务结束，司机状态流转为停止听单；即实现了订单状态流转成功之后，对应的司机状态一定能够流转成功。使得订单和司机状态变化的一致性提升：订单状态流转成功之后，对应的司机状态一定能够流转成功。此外，取消订单状态流转和司机状态的RPC触发，通过消息通知，提升系统性能。

附图说明

下面结合附图对本发明的具体实施方式作进一步详细的说明，其中：

图1至图4为本发明的步骤流程图。

具体实施方式

以下结合附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明。

实施例一：

一种保证司机状态和订单状态变化一致性的方法，其特征是：

如果是订单变更触发的司机状态变化，则执行以下步骤：

S1.监听订单状态变化事件；

S2.对比判断接收到的订单的状态和对应的司机，以及当前司机服务中的订单；

S3.根据订单类型和状态以及司机当前状态以及服务中的订单，判断是否变更司机状态，以及变更后的司机状态；

S4.若司机状态有变化则判断该订单当前对应的司机和之前服务的司机是否一致，如果不一致则表示是改派订单，需要改变订单当前对应司机状态以及之前对应的司机状态；

S5.如果司机状态有变化，则更新数据库和缓存；

如果是司机直接操作开始听单和结束听单时触发的司机状态变化，则执行以下步骤：

SS1.司机在停止听单状态的时候，操作开始听单，则司机状态变为开始听单；

SS2.司机在开始听单状态的时候，操作停止听单，则司机状态变为停止听单。

本实施例中，S2步骤中对比判断处于司机服务中的订单的步骤为：

(a)、从状态变化的订单中获取对应的订单号和司机号；

(b)、从司机数据库获取处于司机服务中的订单；

(c)、通过比对判断订单数据库中状态发生变化的订单是否是(b)步骤中获取的处于司机服务中的订单；

(d)、若判断为“是”，则确认更改司机状态，若判断为“否”，则不更改当前司机状态。

本实施例中：S3步骤中对于预约订单当司机出发后将司机状态变更为服务中，对于取消的订单，若司机已出发，则将司机状态变更为停止听单，对于结束的订单，将司机的状态变更为停止听单；对于实时订单，当派单结束或司机出发后，将司机的状态变更为服务中，对于取消对订单，将司机状态变更为停止听单，订单结束后，将司机状态变更为停止听单。

本实施例中，S4步骤中对于改派订单：根据订单ID查询司机接单配置表；判断订单ID是否有对应的司机，若为“是”，则解除之前订单对应的司机和该订单的对应关系，并更新服务中的订单为0，同时更新数据库和缓存；若为“否”，则直接更新服务中的订单。

本实施例中，在司机没有订单的时候，直接有司机行为触发司机状态变化。

比如，司机滑动开始听单/继续听单的时候将司机状态改为听单中；司机滑动停止听单的时候将司机状态改为停止听单。

本实施例中：司机和订单有关联以及解除关联的时候，由订单服务在订单状态变更成功的时候发送订单状态变更事件消息，司机服务监听该事件，改变司机状态。

比如，司机被派单/抢单成功、订单改派、出发接乘客、结束服务、订单取消的时候，订单服务变更状态成功，发送订单状态变更事件消息；司机服务监听该事件，然后根据订单类型和对应规则来将司机的状态更改为相对应的状态。

实施例二：

一种保证司机状态和订单状态变化一致性的系统，包括：

订单数据库，用于存储订单数据；

司机数据库，用于存储司机数据；

监听模块，用于监听订单数据库内的订单状态的变化以及监听司机数据库内的和司机状态的变化；

比对模块，用于将订单数据库内的处于司机服务的订单与司机数据库内司机服务中的订单进行比对。

以上所述，仅是本发明的较佳实施例而已，并非对本发明作任何形式上的限制，故凡是未脱离本发明技术方案内容，依据本发明的技术实质对以上实施例所作的任何修改、等同变化与修饰,均仍属于本发明技术方案的范围内。