里程计算方法、装置以及存储介质与流程

本申请涉及信息处理技术领域，特别是涉及一种里程计算方法、装置以及存储介质。

背景技术：

随着社会的发展与进步，网约车出行已经成为了一种主流的出行方式。利用网约车出行不仅能够降低出行的成本，还能提高出行的效率。目前网约车的里程计算是由司机端软件根据定位间测距进行里程计算，在结束服务后上报到服务端完成里程的计算。但是，只通过司机端软件进行里程计算存在以下问题：当手机或软件出现异常时，里程容易丢失；在发现手机或软件有问题时不能及时修改，因为软件更新要重新发版，从而无法及时的向服务器上报里程信息；在发现里程结果有问题时，无法快速的确定出现问题的原因。

针对上述的现有技术中存在的由司机端进行里程计算时，容易造成里程信息丢失以及在里程信息出现问题时无法快速确定原因的技术问题，目前尚未提出有效的解决方案。

技术实现要素：

本公开的实施例提供了一种里程计算方法、装置以及存储介质，以至少解决现有技术中存在的由司机端进行里程计算时，容易造成里程信息丢失以及在里程信息出现问题时无法快速确定原因的技术问题。

根据本公开实施例的一个方面，提供了一种里程计算方法，包括：从多个消息队列中确定与指定车辆对应的指定消息队列，其中多个消息队列分别用于存储多个车辆的定位数据；从指定消息队列中获取与指定车辆对应的定位数据；以及根据定位数据，计算指定车辆的第一行驶里程。

根据本公开实施例的另一个方面，还提供了一种存储介质，存储介质包括存储的程序，其中，在程序运行时由处理器执行以上所述的方法。

根据本公开实施例的另一个方面，还提供了一种里程计算装置，包括：第一确定模块，用于从多个消息队列中确定与指定车辆对应的指定消息队列，其中多个消息队列分别用于存储多个车辆的定位数据；获取模块，用于从指定消息队列中获取与指定车辆对应的定位数据；以及计算模块，用于根据定位数据，计算指定车辆的第一行驶里程。

根据本公开实施例的另一个方面，还提供了一种里程计算装置，包括：处理器；以及存储器，与处理器连接，用于为处理器提供处理以下处理步骤的指令：从多个消息队列中确定与指定车辆对应的指定消息队列，其中多个消息队列分别用于存储多个车辆的定位数据；从指定消息队列中获取与指定车辆对应的定位数据；以及根据定位数据，计算指定车辆的第一行驶里程。

从而根据本实施例，使得在司机进行服务的过程中，不仅由司机的终端设备计算车辆的行驶里程，服务器也在进行车辆的行驶里程的计算，最后由服务器决定里程计算的结果。使得在司机的终端设备计算的里程丢失时，可以使用服务器计算的行驶里程。并在所计算的行驶里程的结果出现问题时，服务器可以对里程计算过程进行回放，进而定位出现问题的因素。达到了由服务器对车辆的行驶里程进行计算，不易造成里程信息丢失以及在里程信息出现问题时，可以快速的确定原因的技术效果。进而解决了现有技术中存在的由司机端进行里程计算时，容易造成里程信息丢失以及在里程信息出现问题时无法快速确定原因的技术问题。

附图说明

此处所说明的附图用来提供对本公开的进一步理解，构成本申请的一部分，本公开的示意性实施例及其说明用于解释本公开，并不构成对本公开的不当限定。在附图中：

图1是用于实现根据本公开实施例1所述的方法的计算机终端的硬件结构框图；

图2a是根据本公开实施例1所述的里程计算系统的示意图；

图2b是根据本公开实施例1所述的里程计算系统与其他系统进行交互的业务流程图；

图3是根据本公开实施例1的第一个方面所述的里程计算方法的流程示意图；

图4是根据本公开实施例2所述的里程计算装置的示意图；

图5是根据本公开实施例2所述的里程计算装置的又一个示意图；以及

图6是根据本公开实施例3所述的里程计算装置的示意图。

具体实施方式

为了使本技术领域的人员更好地理解本公开的技术方案，下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述。显然，所描述的实施例仅仅是本公开一部分的实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本公开保护的范围。

需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本公开的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

实施例1

根据本实施例，提供了一种里程计算方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本实施例所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。图1示出了一种用于实现里程计算方法的计算机终端(或移动设备)的硬件结构框图。如图1所示，计算机终端10(或移动设备10)可以包括一个或多个(图中采用102a、102b，……，102n来示出)处理器102(处理器102可以包括但不限于微处理器mcu或可编程逻辑器件fpga等的处理装置)、用于存储数据的存储器104、以及用于通信功能的传输模块106。除此以外，还可以包括：显示器、输入/输出接口(i/o接口)、通用串行总线(usb)端口(可以作为i/o接口的端口中的一个端口被包括)、网络接口、电源和/或相机。本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，计算机终端10还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。

应当注意到的是上述一个或多个处理器102和/或其他数据处理电路在本文中通常可以被称为“数据处理电路”。该数据处理电路可以全部或部分的体现为软件、硬件、固件或其他任意组合。此外，数据处理电路可为单个独立的处理模块，或全部或部分的结合到计算机终端10(或移动设备)中的其他元件中的任意一个内。如本公开实施例中所涉及到的，该数据处理电路作为一种处理器控制(例如与接口连接的可变电阻终端路径的选择)。

存储器104可用于存储应用软件的软件程序以及模块，如本公开实施例中的里程计算方法对应的程序指令/数据存储装置，处理器102通过运行存储在存储器104内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的应用程序的里程计算方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至计算机终端10。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输装置106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端10的通信供应商提供的无线网络。在一个实例中，传输装置106包括一个网络适配器(networkinterfacecontroller，nic)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置106可以为射频(radiofrequency，rf)模块，其用于通过无线方式与互联网进行通讯。

显示器可以例如触摸屏式的液晶显示器(lcd)，该液晶显示器可使得用户能够与计算机终端10(或移动设备)的用户界面进行交互。

此处需要说明的是，在一些可选实施例中，上述图1所示的计算机设备(或移动设备)可以包括硬件元件(包括电路)、软件元件(包括存储在计算机可读介质上的计算机代码)、或硬件元件和软件元件两者的结合。应当指出的是，

图1仅为特定具体实例的一个实例，并且旨在示出可存在于上述计算机设备(或移动设备)中的部件的类型。

图2a是根据本实施例所述的里程计算系统的示意图。参照图2a所示，该系统包括：服务器300。其中服务器300可以对网约车的里程进行计算。司机110接收到了一个服务订单a，其中服务订单a指示由司机110使用车辆210为乘客a进行服务。司机120接收到了一个服务订单b，其中服务订单b指示由司机120使用车辆220为乘客b进行服务。司机130接收到了一个服务订单c，其中服务订单c指示由司机130使用车辆230为乘客c进行服务。

进一步地，服务器300实时获取与车辆210、车辆220以及车辆230的运行轨迹相关的多个定位数据，然后将实时获取到的多个定位数据存储于多个消息队列中，并且保证一个订单的定位数据发送到同一个消息队列中。然后服务器300从存储有订单a的定位数据的消息队列中获取与车辆210对应的定位数据，并计算车辆210的行驶里程。与此同时，服务器300也可以从存储有订单b的定位数据的消息队列中获取与车辆220对应的定位数据，并计算车辆220的行驶里程。服务器300还可以从存储有订单c的定位数据的消息队列中获取与车辆230对应的定位数据，并计算车辆230的行驶里程。

进一步地，服务器300可以动态添加或减少里程服务。例如：服务器300可以同时获取车辆210、车辆220以及车辆230的定位数据，并在任意一个车辆(例如，车辆210)完成服务的情况下，服务器300仍可以继续获取未完成服务的车辆220以及车辆230的定位数据。同理的，服务器300也可以添加与其他车辆相关的里程服务(其中，里程服务的数量不能大于消息队列中的队列数量)。通过这种方式，使得在不需要修改任何程序代码的情况下，服务器300可以动态的添加或减少里程服务，实现里程的分布式计算。

此外，图2b是根据本实施例所述的里程计算系统与其他系统进行交互的业务流程图。参照图2b所示，里程计费系统向定位服务系统获取与服务订单中指示的车辆(例如，车辆210)的定位数据。其中定位服务系统可以以长连接的方式与车辆210的司机110的终端设备进行连接，并实时获取与车辆210对应的定位数据。另外，定位服务系统也可以调用网关服务与司机110的终端设备进行连接，并实时获取与车辆210定位数据，也可以获取与服务订单a相关的信息，例如：车辆210的起始地、目的地以及开始服务的时间。然后里程计费系统基于获取的定位数据计算车辆210的行驶里程。

进一步地，在司机110完成服务之后，可以通过计费系统对本次服务进行计费。然后计费系统向里程计算系统获取计算好的车辆210的行驶里程，并基于锁获取的行驶里程，进行计费操作。同时，里程计算系统提供给其他应用获取定位数据的接口，增加一个里程计算来源。例如第三方结算系统(例如百度鹰眼)通过该接口向里程计算系统获取与车辆210对应的定位数据，并计算车辆210的行驶里程。在计费系统向里程计算系统获取计算好的车辆210的行驶里程时，里程计算系统可以向第三方里程计算系统获取计算好的行驶里程。然后，里程计算系统可以根据配置的规则，选择合适的里程计算结果返回给计费系统。

在上述运行环境下，根据本实施例的第一个方面，提供了一种里程计算方法，该方法由图2中所示的服务器300实现。图3示出了该方法的流程示意图，参考图3所示，该方法包括：

s302：从多个消息队列中确定与指定车辆对应的指定消息队列，其中多个消息队列分别用于存储多个车辆的定位数据；

s304：从指定消息队列中获取与指定车辆对应的定位数据；以及

s306：根据定位数据，计算指定车辆的第一行驶里程。

正如前面背景技术中所述的，随着社会的发展与进步，网约车出行已经成为了一种主流的出行方式。利用网约车出行不仅能够降低出行的成本，还能提高出行的效率。目前网约车的里程计算是由司机端软件根据定位间测距进行里程计算，在结束服务后上报到服务端完成里程的计算。但是，只通过司机端软件进行里程计算存在以下问题：当手机或软件出现异常时，里程容易丢失；在发现手机或软件有问题时不能及时修改，因为软件更新要重新发版，从而无法及时的向服务器上报里程信息；在发现里程结果有问题时，无法快速的确定出现问题的原因。

针对上述背景技术中存在的问题，本实施例的技术方案通过服务器300实时获取所有服务中的车辆的定位数据，并基于获取的定位数据实时计算所有服务中的车辆行驶里程。具体地，参考图2a所示，在司机110接收了一个服务订单(例如，第一服务订单)的情况下，司机110使用车辆210为乘客进行服务。此时，车辆210的行驶里程可以由服务器300来进行计算。服务器300从多个消息队列中确定与指定车辆(即车辆210)对应的指定消息队列。其中，多个消息队列分别用于存储多个车辆的定位数据。例如：正在服务中的车辆有车辆210、车辆220以及车辆330，然后服务器300同时获取正在服务中的车辆的定位数据。由于服务器300同时获取到的定位数据为多个服务订单的定位数据，因此服务器300需要将同一个订单的定位数据存储至同一个消息队列中，进而保证了只有一个线程处理一个订单的定位数据，避免并发冲突。

进一步地，服务器300从指定消息队列中获取与指定车辆(即车辆210)对应的定位数据。其中，在获取定位数据的过程中，服务器300保证同一消息队列的定位数据在同一时刻只能由一个线程消费，确保定位数据的顺序。然后，服务器300根据所获取的与车辆210对应的定位数据，计算车辆210的第一行驶里程。例如：服务器300根据车辆210的定位数据，得知在服务开始时车辆210的定位数据以及服务结束时车辆210的定位数据，并根据预定时间内的定位数据，计算车辆210的行驶里程。

从而，通过这种方式，使得在司机110进行服务的过程中，不仅由司机110的终端设备计算车辆210的行驶里程，服务器300也在进行车辆2210的行驶里程的计算，最后由服务器300决定里程计算的结果。使得在司机110的终端设备计算的里程丢失时，可以使用服务器300计算的行驶里程。在所计算的行驶里程的结果出现问题时，服务器300可以对里程计算过程进行回放，进而定位出现问题的因素。达到了由服务器对车辆的行驶里程进行计算，不易造成里程信息丢失以及在里程信息出现问题时，可以快速的确定原因的技术效果。进而解决了现有技术中存在的由司机端进行里程计算时，容易造成里程信息丢失以及在里程信息出现问题时无法快速确定原因的技术问题。

进一步地，服务器300根据配置的时间间隔(例如，配置的时间间隔建议在一分钟左右)进行里程计算，并将计算结果同步到内存数据库集群中。此外，在服务器300进行里程计算时，可以同时将定位数据发送至第三方里程计算系统，而且同时要算很多服务订单的里程，如果太频繁，会使系统cpu占用率偏大；服务器获取服务中的里程数据时有一定的延迟，最大延迟时间是配置的时间间隔，所以配置的时间间隔不能太大。

可选地，还包括：接收多个车辆的定位数据；从多个消息队列中，确定与多个车辆分别对应的消息队列；以及将多个车辆的定位数据分别存储至对应的消息队列。

具体地，服务器300接收多个车辆的定位数据。例如：正在服务中的车辆有车辆210、车辆220以及车辆230。然后服务器300同时接收这三个车辆的定位数据。其中，如图2b所示，服务器300通过与定位服务系统连接，接收定位服务系统发送的这三个车辆的定位数据。然后服务器300从多个消息队列(可以为本地消息队列)中确定分别与多个车辆对应的消息队列。例如：服务器300确定与车辆210对应的消息队列为第一消息队列，与车辆220对应的消息队列为第二消息队列，以及与车辆230对应的消息队列为第三消息队列。然后，服务器300将多个车辆的定位数据分别存储至对应的消息队列。即，服务器300将车辆210的定位数据存储至第一消息队列中，将车辆220的定位数据存储至第二消息队列中，将车辆230的定位数据存储至第三消息队列中。

从而，通过这种方式，保证了一个服务订单的定位数据(即一个车辆的定位数据)只会存储至同一个消息队列中，避免并发冲突。进而保障了只有一个线程处理一个服务订单的定位数据，并计算行驶里程。

进一步地，服务器300根据配置的时间间隔(例如，配置的时间间隔建议在一分钟左右)接收多个车辆的定位数据，这时服务器300会接收到与多个车辆对应的多个定位数据。尤其是，会接收到与每个车辆对应的多个定位数据。从而通过以上服务器300的操作，可以将与不同车辆对应的定位数据分别配送至与不同车辆对应的消息队列中。从而避免了在调用定位数据进行里程计算时出现错误。

可选地，从多个消息队列中确定与指定车辆对应的指定消息队列的操作，包括：获取服务订单的订单号，其中服务订单指示由指定车辆进行服务；对订单号进行哈希运算，得到哈希值；将哈希值除以多个消息队列的队列数量，并获取余数；以及根据余数，确定指定消息队列。

具体地，服务器300从多个消息队列中确定与指定车辆(例如，车辆210)确定对应的指定消息队列的操作，包括：服务器300获取服务订单(即服务订单a)的订单号。由于每一个服务订单的订单号是唯一的，因此订单号可以用作该服务订单a的标识信息。然后服务器300对订单号进行哈希运算，得到该订单号的哈希值。

进一步地，服务器300将哈希值除以多个消息队列的队列数量，并获取余数。然后，根据余数，确定指定消息队列。例如：服务器300进行除法运算之后，得到的余数为m，此时，服务器300确定该指定消息队列为多个消息队列中的第m个队列。进而，通过这种方式，使得同一个服务订单的定位数据映射到了同一个消息队列中，并且各个消息队列中的数据是均匀的。

可选地，还包括：将与指定车辆对应的定位数据发送至第三方里程计算系统；以及从第三方里程计算系统接收指定车辆的第二行驶里程。

具体地，参照图2b所示，服务器300可以将与指定车辆(例如，车辆210)对应的定位数据发送至第三方里程计算系统(例如，百度鹰眼)。然后在第三方里程计算系统完成行驶里程计算之后，接收第三方里程计算系统发送的车辆210的第二行驶里程。从而，通过这种方式，使得在服务器300进行车辆210行驶里程的计算的同时，还可以将车辆210的定位数据发送至第三方里程计算系统，进而增加了一个行驶里程计算的来源。

可选地，还包括：接收指定终端设备发送的请求获取指定车辆的行驶里程的获取请求，其中指定终端设备为与指定车辆对应的终端设备；根据预先配置的规则，从多个行驶里程中确定指定车辆的推荐行驶里程，其中多个行驶里程包括第一行驶里程和第二行驶里程；以及将推荐行驶里程发送至指定终端设备。

具体地，服务器300接收指定终端设备发送的请求获取指定车辆(例如，车辆210)，其中指定终端设备为车辆210的司机110的终端设备。然后服务器300根据预先设置的规则，从多个行驶里程中确定车辆210的推荐行驶里程。例如：在司机110结束服务之后，服务器300拥有多份行驶里程的信息，分别为：服务器300自身计算的车辆210的第一行驶里程、从第三方里程计算系统接收的车辆210的第二行驶里程以及司机110的终端设备计算的第三行驶里程。

进一步地，预先设置的规则可以为：在第一行驶里程、第二行驶里程以及第三行驶里程之间的差值不大于预设的阈值(例如0.1公里)的情况下，服务器300将第一行驶里程确定为推荐行驶里程；在第一行驶里程与第二行驶里程之间的差值大于预设的阈值，并且第二行驶里程与第三行驶里程之间的差值不大于预设的阈值的情况下，服务器300将以自身计算的行驶里程为准，将第一行驶里程确定为推荐行驶里程；在第一行驶里程、第二行驶里程以及第三行驶里程之间的差值大于预设的阈值的情况下，服务器300判定与车辆210对应的行驶里程在计算的过程中出现了问题，并分析出现问题的原因，进而修正。并将修正后的行驶里程确定为推荐行驶里程。最后，服务器300将推荐行驶里程发送至司机110的终端设备。通过这种方式，服务器300可以根据预选设置的规则，选择合适的行驶里程返回。

可选地，接收多个车辆的定位数据的操作，包括：从定位服务系统获取多个车辆的定位数据，其中定位服务系统可以通过以下任意一种方式获取多个车辆的定位数据：通过长连接服务与多个车辆对应的终端设备进行连接，并获取多个车辆的定位数据；和/或调用多个车辆对应的终端设备的网关服务，并获取多个车辆的定位数据。

具体地，参考图2b所示，服务器300(即，里程计算系统的服务器)从定位服务系统获取多个车辆的定位数据。其中，定位服务系统可以通过两条路径与多个车辆的司机进行连接，并获取定位数据。一条是定位服务系统以长连接的方式与司机的终端设备进行连接。另一条是定位服务系统调用网关服务获取多个车辆的定位点，再由网关将定位数据发送到定位处理服务。第一条路径传输的点是司机的终端设备按固定频率上传定位数据，第二条路径是带有业务信息的定位数据，例如车辆出发地、目的地以及开始服务的时间等。通过这种方式，使得获取定位数据的路径是具有选择性的。

可选地，还包括：在预定时间内未能在指定消息队列中获取与指定车辆对应的定位数据的情况下，存储已经完成计算的第一行驶里程，并清除指定消息队列中的与指定车辆对应的定位数据。

具体地，服务器300在预定时间内未能在指定消息队列中获取与指定车辆对应的定位数据的情况下，服务器300存储已经完成计算的指定车辆(例如，车辆210)的第一行驶里程，并清除指定消息队列中与车辆210对应的定位数据。其中，预定时间可以为5分钟，然后在5分钟内，服务器300未能在指定消息队列中获取车辆210对应的定位数据。从而，通过这种方式，使得在车辆210的定位数据出现异常的情况下，服务器300可以及时的清除指定队列中的与车辆210对应的定位数据，进而减轻了消息队列的存储负担。

可选地，还包括：在判定服务订单中不包括指定车辆的起始点信息的情况下，清除指定消息队列中的与指定车辆对应的定位数据。

具体地，服务器300在判定服务订单中不包括指定车辆(例如，车辆210)的起始点信息的情况下，清除指定消息队列中的与车辆210对应的定位数据。由于无起始点的服务订单是无效的，因此存储于指定消息队列中的车辆210对应的数据为无效数据，进而服务器300需要对无效数据进行清除。通过这种方式，进一步地减轻了本地消息队列的存储负担。

可选地，还包括：确定指定车辆的第一行驶里程是否异常；以及在第一行驶里程异常的情况下，分析造成第一行驶里程异常的因素。具体地，服务器300可以实时对计算行驶里程的过程进行监控，以及在服务器300确定指定车辆(例如：车辆210)的第一行驶里程异常的情况下，分析造成异常的因素。从而，通过这种方式，可以针对性的对出现异常的因素进行优化。

此外，参考图1所示，根据本实施例的第二个方面，提供了一种存储介质104。存储介质104包括存储的程序，其中，在程序运行时由处理器执行以上任意一项所述的方法。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如rom/ram、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

实施例2

图4示出了根据本实施例所述的里程计算装置400，该装置400与根据实施例1的第一个方面所述的方法相对应。参考图4所示，该装置400包括：第一确定模块410，用于从多个消息队列中确定与指定车辆对应的指定消息队列，其中多个消息队列分别用于存储多个车辆的定位数据；获取模块420，用于从指定消息队列中获取与指定车辆对应的定位数据；以及计算模块430，用于根据定位数据，计算指定车辆的第一行驶里程。

可选地，还包括：第一接收模块，用于接收多个车辆的定位数据；第二确定模块，用于从多个消息队列中，确定与多个车辆分别对应的消息队列；以及第一存储模块，用于将多个车辆的定位数据分别存储至对应的消息队列。

可选地，第一确定模块410，包括：第一获取子模块，用于获取服务订单的订单号，其中服务订单指示由指定车辆进行服务；运算子模块，用于对订单号进行哈希运算，得到哈希值；第二获取子模块，用于将哈希值除以多个消息队列的队列数量，并获取余数；以及确定子模块，用于根据余数，确定指定消息队列。

可选地，还包括：第一发送模块，用于将与指定车辆对应的定位数据发送至第三方里程计算系统；以及第二接收模块，用于从第三方里程计算系统接收指定车辆的第二行驶里程。

可选地，还包括：第三接收模块，用于接收指定终端设备发送的请求获取指定车辆的行驶里程的获取请求，其中指定终端设备为与指定车辆对应的终端设备；第三确定模块，用于根据预先配置的规则，从多个行驶里程中确定指定车辆的推荐行驶里程，其中多个行驶里程包括第一行驶里程和第二行驶里程；以及第二发送模块，用于将推荐行驶里程发送至指定终端设备。

可选地，第一接收模块，包括：第三获取子模块，用于从定位服务系统获取多个车辆的定位数据，其中定位服务系统可以通过以下任意一种方式获取多个车辆的定位数据：通过长连接服务与多个车辆对应的终端设备进行连接，并获取多个车辆的定位数据；和/或调用多个车辆对应的终端设备的网关服务，并获取多个车辆的定位数据。

可选地，还包括：第二存储模块，用于在预定时间内未能在指定消息队列中获取与指定车辆对应的定位数据的情况下，存储已经完成计算的第一行驶里程，并清除指定消息队列中的与指定车辆对应的定位数据。

可选地，还包括：清除模块，用于在判定服务订单中不包括指定车辆的起始点信息的情况下，清除指定消息队列中的与指定车辆对应的定位数据。

可选地，还包括：第四确定模块，用于确定指定车辆的第一行驶里程是否异常；以及分析模块，用于在第一行驶里程异常的情况下，分析造成第一行驶里程异常的因素。

进一步地，图5示出了计算里程计算装置400的又一个结构示意图。参考图5所示，实时里程计算系统主要由以下模块组成：

1)、trackconsumeworker模块：为里程计算线程模块，用于计算与指定车辆相关的行驶里程；

2)、queueswitchtask模块：用于在一段时间内服务订单指定的车辆无轨迹点上传的情况下，将里程计算结果保存至内存数据库集群，并将与指定车辆对应的定位数据清出本地消息队列；

3)、endlocationtask模块：用于在判定服务订单中不包括指定车辆的起始点信息的情况下，将与指定车辆对应的定位数据清出本地消息队列；

4)、logtrackconsumer模块：用于将分布式消息中间件(rocketmq)中的定位数据放入本地阻塞队列；

5)、queuestatetask模块：用于打印阻塞队列状态，监控实时计算性能；

6)、trackconsumequeue模块：为本地阻塞队列模块，用于保存车辆的定位数据；

7)、过滤规则模块，用于根据预先设置的饿规则，选择合适的行驶里程返回；

8)、分析模块，用于在里程结果出现问题时，分析出现问题的因素；

9)、监控模块，用于对里程计算过程以及获取里程过程进行监控，在监控到状态异常的情况下，发送报警信息。

进一步地，里程计算装置的计算过程分为两部分，一部分是进行实时里程计算的deamon服务，另一部分是提供给其它应用(例如，第三方里程计算系统)获取定位数据的rest接口。实时里程计算过程由logtrackconsumer、trackconsumeworker和trackconsumerqueue完成。其中logtrackconsumer将定位数据从分布式消息中间件(rocketmq)放入trackconsumequeue中。然后trackconsumeworker消费trackconsumequeue中的定位数据并进行里程计算，并根据配置的时间间隔进行里程计算，然后将计算结果同步到内存数据库集群(rediscluster)中(配置的时间间隔建议在一分钟左右，进行里程计算时，要调用内存数据库集群还有第三方里程计算平台，而且同时要算很多订单的里程，如果太频繁，会使系统cpu占用率偏大；服务中获取里程数据有一定的延迟，最大延迟时间为配置的时间间隔，所以时间间隔不能太大)。在里程计算装置获取到指定车辆的行驶里程时，将拿到的司机端计算的行驶里程、第三方里程计算平台的计算的行驶里程和内存数据库集群中保存的实时里程计算系装置自己计算的行驶里程，根据配置的规则，选择合适的里程返回。

logtrackconsumer在消费分布式消息中间件(rocketmq)中的定位数据时，注册的消费监听事件使用messagelistenerorderly，保证同一队列的定位消息同一时刻只能由一个线程消费，确保消息的顺序。定位数据放入本地阻塞队列时，用订单号的hash值与本地阻塞队列的队列数取余确定定位数据要放入的本地队列中指定的消息队列，使得一个订单的数据只会放入一个本地队列中，由一个trackconsumeworker进行里程计算。

trackconsumeworker通过concurrenthashmap和trackconsumequeue进行1对1的映射，一个队列只能由一个线程进行处理，trackconsumeworker和trackconsumequeue数量在服务启动时从配置文件获取。这样里程计算线程就不用考虑多个线程同时计算时的并发问题，因为不会有多个线程同时处理同一个订单的情况。通过offer方法在本地阻塞队列中添加数据，通过take方法取数据，取数据时不要通过remove和poll方法，否则很容易造成cpu超负荷的情况。trackconsumeworker和trackconsumequeue的数量可以动态的调整，确保系统的吞叶能力。

从而根据本实施例，使得在司机进行服务的过程中，不仅由司机的终端设备计算车辆的行驶里程，服务器也在进行车辆的行驶里程的计算，最后由服务器决定里程计算的结果。使得在司机的终端设备计算的里程丢失时，可以使用服务器计算的行驶里程。并在所计算的行驶里程的结果出现问题时，服务器可以对里程计算过程进行回放，进而定位出现问题的因素。达到了由服务器对车辆的行驶里程进行计算，不易造成里程信息丢失以及在里程信息出现问题时，可以快速的确定原因的技术效果。进而解决了现有技术中存在的由司机端进行里程计算时，容易造成里程信息丢失以及在里程信息出现问题时无法快速确定原因的技术问题。

实施例3

图6示出了根据本实施例所述的里程计算装置600，该装置600与根据实施例1的第一个方面所述的方法相对应。参考图6所示，该装置600包括：处理器610；以及存储器620，与处理器610连接，用于为处理器610提供处理以下处理步骤的指令：从多个消息队列中确定与指定车辆对应的指定消息队列，其中多个消息队列分别用于存储多个车辆的定位数据；从指定消息队列中获取与指定车辆对应的定位数据；以及根据定位数据，计算指定车辆的第一行驶里程。

可选地，存储器620还用于为处理器610提供处理以下处理步骤的指令：接收多个车辆的定位数据；从多个消息队列中，确定与多个车辆分别对应的消息队列；以及将多个车辆的定位数据分别存储至对应的消息队列。

可选地，从多个消息队列中确定与指定车辆对应的指定消息队列的操作，包括：获取服务订单的订单号，其中服务订单指示由指定车辆进行服务；对订单号进行哈希运算，得到哈希值；将哈希值除以多个消息队列的队列数量，并获取余数；以及根据余数，确定指定消息队列。

可选地，存储器620还用于为处理器610提供处理以下处理步骤的指令：将与指定车辆对应的定位数据发送至第三方里程计算系统；以及从第三方里程计算系统接收指定车辆的第二行驶里程。

可选地，存储器620还用于为处理器610提供处理以下处理步骤的指令：接收指定终端设备发送的请求获取指定车辆的行驶里程的获取请求，其中指定终端设备为与指定车辆对应的终端设备；根据预先配置的规则，从多个行驶里程中确定指定车辆的推荐行驶里程，其中多个行驶里程包括第一行驶里程和第二行驶里程；以及将推荐行驶里程发送至指定终端设备。

可选地，接收多个车辆的定位数据的操作，包括：从定位服务系统获取多个车辆的定位数据，其中定位服务系统可以通过以下任意一种方式获取多个车辆的定位数据：通过长连接服务与多个车辆对应的终端设备进行连接，并获取多个车辆的定位数据；和/或调用多个车辆对应的终端设备的网关服务，并获取多个车辆的定位数据。

可选地，存储器620还用于为处理器610提供处理以下处理步骤的指令：在预定时间内未能在指定消息队列中获取与指定车辆对应的定位数据的情况下，存储已经完成计算的第一行驶里程，并清除指定消息队列中的与指定车辆对应的定位数据。

可选地，存储器620还用于为处理器610提供处理以下处理步骤的指令：在判定服务订单中不包括指定车辆的起始点信息的情况下，清除指定消息队列中的与指定车辆对应的定位数据。

可选地，存储器620还用于为处理器610提供处理以下处理步骤的指令：确定指定车辆的第一行驶里程是否异常；以及在第一行驶里程异常的情况下，分析造成第一行驶里程异常的因素。

从而根据本实施例，使得在司机进行服务的过程中，不仅由司机的终端设备计算车辆的行驶里程，服务器也在进行车辆的行驶里程的计算，最后由服务器决定里程计算的结果。使得在司机的终端设备计算的里程丢失时，可以使用服务器计算的行驶里程。并在所计算的行驶里程的结果出现问题时，服务器可以对里程计算过程进行回放，进而定位出现问题的因素。达到了由服务器对车辆的行驶里程进行计算，不易造成里程信息丢失以及在里程信息出现问题时，可以快速的确定原因的技术效果。进而解决了现有技术中存在的由司机端进行里程计算时，容易造成里程信息丢失以及在里程信息出现问题时无法快速确定原因的技术问题。上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

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

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。