一种网约车乘客历史行程展示优化方法与流程

1.本发明涉及网约车领域，尤其涉及一种网约车乘客历史行程展示优化方法。


背景技术：

2.在网约车平台中，查看历史行程是很重要的功能之一，但网约车会包括多种类型的服务，比如专车、巴士、出租车、国际用车、多日预定、顺风车、代驾。由于各种服务类型的数据不完全相同，存在差异，例如，专车只有起终点，而巴士有起点、途经站点、终点；例如：多日预定会有主单，一个主单对应一个订单，包括多个子单，所以底层数据存储会使用不同的数据表，互不干扰，保持数据独立性。
3.在用户行程列表中也是分开展示的。但随着业务的发展，类型越来越多，行程列表的展示就会面临一些挑战，分tab展示因为用车偏好不同，tab不好排序，例如，家长一般用多日用车接送孩子；国际友人一般用国际用车；有人习惯打出租车，无法满足用户的的需求偏好，只能合并展示，按预定用车时间来排序，达到了常用出行方式展示在最上边的目的。随着业务体量的增加，直接将多表数据合并面临排序和分页的两大问题。
4.用户行程是按照预定时间倒序分页展示，每次查询指定数量20条，从多张表查询，无法确定多个表中预定时间先后，需要从所有表把对应用户数据全部取出，在内存中进行排序，从排序后的结果中截取需要指定分页数量。随着数据的累积，用户数据越来越多，查询效率越来越低。
5.当用户订单量比较多时，取出大量数据在内存中排序，会瞬间占用大量内存。不同类型订单存储数据有差异，需要取出后进行数据整理，合并重新排序处理，并且处理是实时进行，逻辑处理耗时，且结果不能供之后再次查询使用，有一定的资源浪费。无法灵活扩展，例如新的订单类型扩展时，例如要对接租车，就需要改动行程列表的数据获取，重新整合。


技术实现要素：

6.鉴于上述问题，提出了本发明以便提供克服上述问题或者至少部分地解决上述问题的一种网约车乘客历史行程展示优化方法。
7.根据本发明的一个方面，提供了一种网约车乘客历史行程展示优化方法，所述优化方法包括：
8.制作用于记录行程的数据表，获得聚合表；
9.实时获取订单完成事件和订单取消事件；
10.对所述订单完成事件和所述订单取消事件进行数据整理，并写入所述聚合表；
11.行程查询时，直接从所述聚合表中获取满足条件的数据，过滤被用户标记删除的订单，获得过滤条件满足数据；
12.将所述过滤条件满足数据返回前端进行展示。
13.可选的，所述聚合表的字段包括：
14.订单号、订单类型、多日主单号、拼车主单号、预定时间、上车地址、下车地址和是
否删除。
15.可选的，所述优化方法还包括：
16.用户在所述数据表中操作删除订单时，将所述是否删除字段设置为0。
17.可选的，所述对所述订单完成事件和所述订单取消事件进行数据整理，并写入所述聚合表具体包括：
18.如果订单为专车订单数据，所述多日主单号设置为0，所述拼车主单号设置为flase；
19.如果订单为多日订单，包括主单信息和子单数据，只展示所述主单信息，将所述主单信息写入所述聚合表，将所述子单数据过滤掉；
20.如果订单为巴士用车，将实际起点设置为预定用车的起点，实际终点设置为预定用车的终点。
21.可选的，所述如果订单为专车订单数据还包括：
22.计算实际和预定的距离偏差，若偏差大于500米，将实际上下车地址作为用车上下车地址；
23.有短地址信息的订单，将所述短地址信息解析后放入所述聚合表实际上下车地址。
24.本发明提供的一种网约车乘客历史行程展示优化方法，所述优化方法包括：制作用于记录行程的数据表，获得聚合表；实时获取订单完成事件和订单取消事件；对所述订单完成事件和所述订单取消事件进行数据整理，并写入所述聚合表；行程查询时，直接从所述聚合表中获取满足条件的数据，过滤被用户标记删除的订单，获得过滤条件满足数据；将所述过滤条件满足数据返回前端进行展示。通过将用户行程数据整合的过程前置，解决多表排序问题和查询时占用大量内存的问题。
25.上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。
附图说明
26.为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。
27.图1为本发明实施例提供的一种网约车乘客历史行程展示优化方法流程图。
具体实施方式
28.下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。
29.本发明的说明书实施例和权利要求书及附图中的术语“包括”和“具有”以及他们
的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元。
30.下面结合附图和实施例，对本发明的技术方案做进一步的详细描述。
31.如图1所示，制作用于行程的数据表，获得聚合表，数据字段少，信息结构简洁，查询效率高，表简化结构如表一。
32.表一
33.订单号订单类型多日主单号拼车主单号预定时间上车地址下车地址是否删除ordernoservicetypeidmultiordernocarpoolmainordernobookingdatestartaddrendaddrisdisplay
34.使用rocketmq监听订单完成事件和订单取消事件，行程列表中展示的都是终态订单，包括完成订单和取消订单。不同类型的订单经过对应的数据整理，写入聚合表。
35.专车订单数据，多日主单号multi_order_no设为0，拼车主单号carpool_order_id设为flase。
36.计算实际和预定的距离偏差，如果距离偏差》500米，使用实际上下车地址作为用车上下车地址，避免按行程开票时，行程信息有偏差，导致无法报销。
37.有短地址信息的订单，将短地址解析后放入聚合表实际上下车地址，避免信息展示时，地址过长，单行展示不下，用户app信息展示不全的问题。
38.多日订单，只展示主单，将主单信息写入聚合表，子单数据过滤，不写入聚合表。
39.巴士用车，将实际起点和实际终点设置为预定用车的起点和终点，因为巴士涉及中间停靠不能将中间地点作为起终点展示。
40.若是订单取消，查询取消原因，放入聚合表，避免用户。
41.行程查询时，直接从聚合表中获取满足条件的数据，过滤被用户标记删除的订单，返回前端展示。
42.用户在行程列表操作删除订单时，将聚合表is_display设置为0，在查询行程列表时，数据会被过滤。
43.本发明解决了解决网约车乘客历史行程，由于服务类型众多，数据需要重新组合排序，查询效率越来越低，且查询过程会占用大量的内存资源而接近的。通过将用户行程数据整合的过程前置，解决多表排序问题和查询时占用大量内存的问题。同时由于不用在查询时实时整合数据，提高用户界面响应效率。另外，当新的业务扩展时，无需改动行程列表获取的代码，将数据整合到同一张数据表，使系统保持扩展的灵活性。
44.有益效果：优化行程请求响应时间。通过聚合表的设计，将多表数据聚合的过程前置，完成不同表信息差异处理，特殊字段存储信息处理等工作，使用户请求行程的接口响应时间从平均1.5s到现在的不到50ms。
45.优化数据库查询。避免了多表数据聚合，需要查出所有单表满足条件数据的问题，不管用户有没有该类型的订单，都会去访问一次数据库，查询数据。
46.优化了大量数据排序对内存的影响问题。多表查询时，由于多表间时间完全无序，需要在内存中，将数据重新排序，会瞬间占用大量内存，使用聚合表，直接查询时按预定时间排序取出满足条件的记录。
47.以上的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明
的保护范围之内。