[发明专利]一种保证司机状态和订单状态变化一致性的方法和系统

说明书

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

技术领域

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

背景技术

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

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

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

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

发明内容

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

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

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

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

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

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

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

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

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

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

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

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