一种网约车订单生成方法及系统与流程

1.本公开涉及网约车技术领域，具体涉及一种网约车订单系统及一种网约车订单生成方法。


背景技术：

2.网约车订单除过来自于自有运力平台(如首汽约车，滴滴打车等)外，还来自于聚合平台(如高德，百度)。随着网约车市场的发展，聚合平台逐渐崛起。2022年聚合平台已经占据了网约车20％的市场份额。现有技术对来自于聚合平台和来自于自有运力平台的下单请求，都采用同一个订单系统处理。但是，在接到客户下单请求后，聚合平台会同时对多个自有运力平台发送下单请求直至某个自有运力平台派单。因此自有运力平台在承接聚合平台海量下单流量时，对于下单接口的响应要求会很高。在打车高峰期，来自于聚合平台海量的下单请求会使订单系统的下单压力呈现指数级上升，从而使订单系统响应变慢，系统不稳定。


技术实现要素：

3.本公开实施例提出了一种网约车订单系统、一种网约车订单生成方法、一种网约车订单生成装置、一种网约车订单查询方法、一种网约车订单查询装置、电子设备，以解决现有技术在在打车高峰期，订单系统因为来自于聚合平台海量的下单请求而响应变慢、系统不稳定的问题。
4.本公开实施例的第一方面提供了一种网约车订单系统，包括第一订单系统，用于接收自有平台订单，还包括第二订单系统：
5.所述第二订单系统用于接收聚合平台订单，
6.所述第二订单系统包括若干数据库，每个数据库包含若干数据表，所述数据库和所述数据表分别分配有编号，编号顺序增加。
7.在一些实施例中，所述第二订单系统包括n个数据库，每个数据库包含k个数据表，n、k为自然数，所述数据库和所述数据表分别分配有编号包括：
8.第一个数据库编号为1，后续数据库编号顺序增加，直至第n个数据库编号为n；
9.数据库n第一个数据表编号为k(n-1)，后续数据表编号顺序增加，直至数据库n的第k个数据表表编号为kn-1。
10.本公开实施例的第二方面提供了一种网约车订单生成方法，应用于如本公开第一方面所述的订单系统，其特征在于，包括：
11.接收下单请求，所述下单请求至少包括乘车人手机号和打车渠道信息；
12.基于所述打车渠道信息判断所述打车渠道是否属于高流量渠道列表，如是，则基于所述乘车人手机号在所述第二订单系统生成订单，如否，则在所述第一订单系统生成订单；
13.返回对应订单系统生成的订单号。
14.在一些实施例中，所述方法还包括：
15.如果在预设的同一时间间隔内接收到的下单请求超过预设阈值，且所述下单请求的打车渠道属于高流量渠道列表，则按预设规则在所述第二订单系统中增加1个或多个数据库。
16.在一些实施例中，所述基于所述乘车人手机号在第二订单系统生成订单包括：
17.基于所述手机号获取下单数据表的数据表编号，其中，
18.所述数据表编号＝所述手机号％(kn)；
19.基于所述手机号获取下单数据库的数据库编号，其中，
20.所述数据库编号＝math.floordiv(数据表编号，k)+1；
21.在所述编号的下单数据库的所述编号的下单数据表中增加订单记录。
22.本公开实施例的第三方面提供了一种网约车派车装置，包括：
23.订单接收模块，用于接收下单请求，所述下单请求至少包括乘车人手机号和打车渠道信息；
24.订单生成模块，用于基于所述打车渠道信息判断所述打车渠道是否属于高流量渠道列表，如是，则基于所述乘车人手机号在所述第二订单系统生成订单，如否，则在所述第一订单系统生成订单；
25.订单号返回模块，用于返回对应订单系统生成的订单号。
26.本公开实施例的第四方面提供了一种网约车订单查询方法，应用于如本公开第一方面所述的订单系统，包括：
27.获取订单查询请求，基于所述查询请求获取网约车订单号；
28.如果所述订单来自于高流量渠道，则基于所述订单号获取下单数据库和下单数据表的编号，在所述第二订单系统所述编号对应的下单数据库中的下单数据表中，基于所述订单号获取订单记录，如果所述订单不来自于高流量渠道，则在所述第一订单系统中，基于所述订单号获取订单记录；
29.返回所述订单记录。
30.在一些实施例中，所述基于所述订单号获取下单数据库和下单数据表的编号包括：
31.计算所述第二订单系统包含的数据表总数的位数m，其中，
32.m＝digit(kn)；
33.基于所述订单号获取下单数据表的数据表编号，其中，
34.所述数据表编号＝所述订单号后m位；
35.基于所述订单号获取下单数据库的数据库编号，其中，
36.所述数据库编号＝math.floordiv(数据表编号,k)+1。
37.本公开实施例的第五方面提供了一种网约车订单查询装置，包括：
38.第一获取模块，用于获取订单查询请求，基于所述查询请求获取网约车订单号；
39.第二获取模块，用于如果所述订单来自于高流量渠道，则基于所述订单号获取下单数据库和下单数据表的编号，在所述第二订单系统所述编号对应的下单数据库中的下单数据表中，基于所述订单号获取订单记录，如果所述订单不来自于高流量渠道，则在所述第一订单系统中，基于所述订单号获取订单记录；
40.返回模块，用于返回所述订单记录。
41.本公开实施例的第六方面提供一种电子设备，包括存储器和处理器，
42.所述存储器，用于存储计算机程序；
43.所述处理器，用于当执行所述计算机程序时，实现根据本公开第二方面和第四方面所述的方法。
44.本公开实施例的第七方面提供了一种计算机可读存储介质，所述存储介质上存储有计算机程序，当所述计算机程序被处理器执行时，实现根据本公开第二方面和第四方面所述的方法。
45.本公开实施例的第八方面提供了一种计算机程序产品，包括计算机程序、指令，当所述计算机程序、指令被处理器执行时，实现根据本公开第二方面和第四方面所述的方法。
46.本公开各实施例提供的网约车订单系统、网约车订单生成方法、网约车订单生成装置、网约车订单查询方法、网约车订单查询装置、电子设备、计算机可读存储介质和程序产品，通过对来自于聚合平台和自有运力平台的网约车订单请求采用不同的订单系统处理，对于处理来自于聚合平台订单请求的订单系统分库分表，每个数据库与数据表平均了聚合平台的下单流程，极大的提高下单与查询订单效率，订单系统一旦出现压力过高，可以及时的增加数据库与数据表，系统扩展性也得到了很大的提高，从而提高了打车高峰期对聚合平台海量下单请求的响应及时性。
附图说明
47.通过参考附图会更加清楚的理解本公开的特征和优点，附图是示意性的而不应理解为对本公开进行任何限制，在附图中：
48.图1是本公开适用的一种计算机系统的示意图；
49.图2是根据本公开的一些实施例所示的一种网约车订单生成方法的流程图；
50.图3是根据本公开的一些实施例所示的一种网约车订单生成装置的示意图；
51.图4是根据本公开的一些实施例所示的一种网约车订单查询方法的流程图；
52.图5是根据本公开的一些实施例所示的一种网约车订单查询装置的示意图；
53.图6是本公开的一些实施例所示的一种电子设备示意图。
具体实施方式
54.在下面的详细描述中，通过示例阐述了本公开的许多具体细节，以便提供对相关披露的透彻理解。然而，对于本领域的普通技术人员来讲，本公开显而易见的可以在没有这些细节的情况下实施。应当理解的是，本公开中使用“系统”、“装置”、“单元”和/或“模块”术语，是用于区分在顺序排列中不同级别的不同部件、元件、部分或组件的一种方法。然而，如果其他表达式可以实现相同的目的，这些术语可以被其他表达式替换。
55.应当理解的是，当设备、单元或模块被称为“在
……
上”、“连接到”或“耦合到”另一设备、单元或模块时，其可以直接在另一设备、单元或模块上，连接或耦合到或与其他设备、单元或模块通信，或者可以存在中间设备、单元或模块，除非上下文明确提示例外情形。例如，本公开所使用的术语“和/或”包括一个或多个相关所列条目的任何一个和所有组合。
56.本公开所用术语仅为了描述特定实施例，而非限制本公开范围。如本公开说明书
和权利要求书中所示，除非上下文明确提示例外情形，“一”、“一个”、“一种”和/或“该”等词并非特指单数，也可包括复数。一般说来，术语“包括”与“包含”仅提示包括已明确标识的特征、整体、步骤、操作、元素和/或组件，而该类表述并不构成一个排它性的罗列，其他特征、整体、步骤、操作、元素和/或组件也可以包含在内。
57.参看下面的说明以及附图，本公开的这些或其他特征和特点、操作方法、结构的相关元素的功能、部分的结合以及制造的经济性可以被更好地理解，其中说明和附图形成了说明书的一部分。然而，可以清楚地理解，附图仅用作说明和描述的目的，并不意在限定本公开的保护范围。可以理解的是，附图并非按比例绘制。
58.本公开中使用了多种结构图用来说明根据本公开的实施例的各种变形。应当理解的是，前面或下面的结构并不是用来限定本公开。本公开的保护范围以权利要求为准。
59.图1是本公开适用的一种计算机系统的示意图。如图1所示的系统，订单处理服务器和一种或多种打车终端(打车终端1a、打车终端2a、
…
打车终端na,打车终端1b、打车终端2b、
…
打车终端nb,n为自然数)网络连接，接收所述打车终端的打车请求，生成订单,并可处理对所述订单的查询请求。
60.其中：
61.所述打车终端是具有用户交互能力的设备，可以是基于移动操作系统，如安卓或苹果系统的移动设备，也可以是基于windows操作系统的个人电脑、工作站或服务器，还可以是智能汽车或者是汽车的智能中控台或中控屏。用户可以通过所述打车终端向所述订单处理服务器发起打车请求。
62.在本公开的一些实施例中，所述打车终端是具有用户交互能力的软件，所述软件部署于上述的移动终端、个人电脑或车载终端。
63.所述打车终端可以是属于自有运力平台的终端，或者是注册于自有运力平台管理软件的用户端软件，如图1中打车终端1a、打车终端2a、
…
打车终端na。自有运力平台就是具有网约车运营资格与能力，并开展实际运营，同时接收客户的网约车打车请求的平台，如首汽约车，滴滴打车等。所述打车终端也可以是属于聚合平台的终端，或者是注册于聚合平台管理软件的用户端软件，如图1中打车终端1b、打车终端2b、
…
打车终端nb。所述聚合平台，是指接收客户的网约车打车请求，但不开展网约车的实际运营，而是将所述打车请求转发给自有运力平台，由所述自有运力平台完成所述打车请求的平台。现在市场的主流聚合平台有高德，百度等。接到客户下单请求后，聚合平台会同时对多个自有运力平台发送下单请求直至某个自有运力平台派单。
64.所述订单处理服务器接收打车请求，生成打车订单，并可处理对所述打车订单的查询请求。如图1所示，所述订单处理服务器包含第一订单系统和第二订单系统。其中所述第一订单系统处理来自自有运力平台打车终端的打车请求。所述第二订单系统包含多个数据库，每个数据库包含多个数据表，处理处理来自聚合平台打车终端的打车请求。
65.所述订单处理服务器可以是单机、集群或分布式服务器中的任一种。
66.本公开的一些实施例公开了一种网约车订单系统，如图1所示，所述网约车订单系统包括第一订单系统和第二订单系统。所述第一订单系统用于接收自有平台订单。所述第二订单系统用于接收聚合平台订单。所述第二订单系统包括若干数据库，每个数据库包含若干数据表，所述数据库和所述数据表分别分配有编号，编号顺序增加。
67.在本公开的一些实施例中，所述第二订单系统包括n个数据库，每个数据库包含k个数据表，n、k为自然数，所述数据库和所述数据表分别分配有编号包括：
68.第一个数据库编号为1，后续数据库编号顺序增加，直至第n个数据库编号为n；
69.数据库n第一个数据表编号为k(n-1)，后续数据表编号顺序增加，直至数据库n的第k个数据表表编号为kn-1。
70.在本公开的一些实施例中，所述第二订单系统包括8个数据库，名称分别db1,db2,db3,db4,db5,db6,db7,db8。
71.每个数据库包含32个数据表。共256个。数据表命名如下：
72.db1:order000-order031
73.db2:order032-order063
74......
75.db8:order224-order255
76.图2是根据本公开的一些实施例所示的一种网约车订单生成方法的流程图。在一些实施例中，所述网约车订单生成方法可以由图1所示的订单处理服务器执行。如图2所示，所述网约车订单生成方法包括以下步骤：
77.s201，接收下单请求，所述下单请求至少包括乘车人手机号和打车渠道信息。
78.具体的，打车渠道包括自有平台渠道和聚合平台渠道。聚合平台，是指接收客户的网约车打车请求，但不开展网约车的实际运营，而是将所述打车请求转发给自有运力平台，由所述自有运力平台完成所述打车请求的平台。现在市场的主流聚合平台有高德，百度等。聚合平台渠道又称为高流量渠道。
79.s202，基于所述打车渠道信息判断所述打车渠道是否属于高流量渠道列表，如是，则基于所述乘车人手机号在所述第二订单系统生成订单，如否，则在所述第一订单系统生成订单。
80.具体的，在本公开的一些实施例中，所述基于所述乘车人手机号在第二订单系统生成订单包括：
81.基于所述手机号获取下单数据表的数据表编号，其中，
82.所述数据表编号＝所述手机号％(kn)；
83.基于所述手机号获取下单数据库的数据库编号，其中，
84.所述数据库编号＝math.floordiv(数据表编号，k)+1；
85.在所述编号的下单数据库的所述编号的下单数据表中增加订单记录。
86.在本公开的一些实施例中，所述订单记录包含订单号，订单号由所述第二订单系统包含的数据表总数和所述订单属于的数据表编号决定。
87.具体的，如果所述数据表总数为m位的自然数，则将所述订单属于的数据表编号作为所述订单的后m位。
88.如在本公开的一些实施例中第二订单系统总共256张数据表，那么订单号设计用最后3位来存数据表编号，如果总数据表个数到了1000，则订单号设计需要预留最后4位给到数据表编号。
89.s203，返回对应订单系统生成的订单号。
90.在本公开的一些实施例中，所述方法还包括：
91.如果在预设的同一时间间隔内接收到的下单请求超过预设阈值，且所述下单请求的打车渠道属于高流量渠道列表，则按预设规则在所述第二订单系统中增加1个或多个数据库。
92.具体的，因为接到客户下单请求后，聚合平台会同时对多个自有运力平台发送下单请求直至某个自有运力平台派单。所以在打车高峰期，自有运力平台订单系统会收到海量的来自于聚合平台的打车请求。因此，聚合平台渠道又称为高流量渠道。
93.通过在第二订单系统中根据预设的扩容规则增加1个或多个数据库，可以平滑打车高峰期海量的来自于高流量渠道的突发打车请求，从而保持订单系统的稳定运行。
94.图3是根据本公开的一些实施例所示的一种网约车订单生成装置示意图。如图3所示，所述网约车订单生成装置300包括订单接收模块310、订单生成模块320、订单号返回模块330。所述网约车订单生成功能可以由图1中的订单处理服务器执行。其中：
95.订单接收模块310，用于接收下单请求，所述下单请求至少包括乘车人手机号和打车渠道信息；
96.订单生成模块320，用于基于所述打车渠道信息判断所述打车渠道是否属于高流量渠道列表，如是，则基于所述乘车人手机号在所述第二订单系统生成订单，如否，则在所述第一订单系统生成订单；
97.订单号返回模块330，用于返回对应订单系统生成的订单号。
98.图4是根据本公开的一些实施例所示的一种网约车订单查询方法的流程图。在一些实施例中，所述网约车订单查询方法可以由图1所示的订单处理服务器执行。如图4所示，所述网约车订单查询方法包括以下步骤：
99.s401，获取订单查询请求，基于所述查询请求获取网约车订单号
100.s402，如果所述订单来自于高流量渠道，则基于所述订单号获取下单数据库和下单数据表的编号，在所述第二订单系统所述编号对应的下单数据库中的下单数据表中，基于所述订单号获取订单记录，如果所述订单不来自于高流量渠道，则在所述第一订单系统中，基于所述订单号获取订单记录；
101.具体的，所述高流量渠道指的是聚合平台渠道。
102.在本公开的一些实施例中，所述基于所述订单号获取下单数据库和下单数据表的编号包括：
103.计算所述第二订单系统包含的数据表总数的位数m，其中，
104.m＝digit(kn)；
105.基于所述订单号获取下单数据表的数据表编号，其中，
106.所述数据表编号＝所述订单号后m位；
107.基于所述订单号获取下单数据库的数据库编号，其中，
108.所述数据库编号＝math.floordiv(数据表编号,k)+1。
109.在本公开的一些实施例中，所述第二订单系统包含256个数据表，每个数据库有32个数据表，所以：
110.数据表总数为3位数，m＝3，
111.数据表编号为截取订单号最后三位，
112.数据库编号＝math.floordiv(数据表编号,32)+1。
113.s403，返回所述订单记录。
114.图5是根据本公开的一些实施例所示的一种网约车订单查询装置示意图。如图3所示，所述网约车订单查询装置500包括第一获取模块510、第二获取模块520、返回模块530。所述网约车订单查询功能可以图1所示的订单处理服务器执行执行。其中：
115.第一获取模块510，用于获取订单查询请求，基于所述查询请求获取网约车订单号；
116.第二获取模块520，用于如果所述订单来自于高流量渠道，则基于所述订单号获取下单数据库和下单数据表的编号，在所述第二订单系统所述编号对应的下单数据库中的下单数据表中，基于所述订单号获取订单记录，如果所述订单不来自于高流量渠道，则在所述第一订单系统中，基于所述订单号获取订单记录；
117.返回模块530，用于返回所述订单记录。
118.本公开的一个实施例提供了一种电子设备，所述电子设备600包括存储器620和处理器610，所述存储器620，用于存储计算机程序；所述处理器610，用于当执行所述计算机程序时，实现图2中s201-s203或图4中s401-s403所述的网约车派车方法。
119.本公开的一个实施例提供了一种计算机可读存储介质，所述存储介质上存储有计算机程序，当所述计算机程序被处理器执行时，实现图2中s201-s203或图4中s401-s403所述的网约车派车方法。
120.本公开的一个实施例提供了一种计算机程序产品，包括计算机程序、指令，当所述计算机程序、指令被处理器执行时，实现图2中s201-s203或图4中s401-s403所述的网约车派车方法。
121.综上所述，本公开各实施例提供的网约车订单系统、网约车订单生成方法、网约车订单生成装置、网约车订单查询方法、网约车订单查询装置、电子设备，通过对来自于聚合平台和自有运力平台的网约车订单请求采用不同的订单系统处理，对于处理来自于聚合平台订单请求的订单系统分库分表，每个数据库与数据表平均了聚合平台的下单流程，极大的提高下单与查询订单效率，订单系统一旦出现压力过高，可以及时的增加数据库与数据表，系统扩展性也得到了很大的提高，从而提高了打车高峰期对聚合平台海量下单请求的响应及时性。
122.所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的设备和模块的具体工作过程，可以参考前述装置实施例中的对应描述，在此不再赘述。
123.尽管此处所述的主题是在结合操作系统和应用程序在计算机系统上的执行而执行的一般上下文中提供的，但本领域技术人员可以认识到，还可结合其他类型的程序模块来执行其他实现。一般而言，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、组件、数据结构和其他类型的结构。本领域技术人员可以理解，此处所述的本主题可以使用其他计算机系统配置来实践，包括手持式设备、多处理器系统、基于微处理器或可编程消费电子产品、小型计算机、大型计算机等，也可使用在其中任务由通过通信网络连接的远程处理设备执行的分布式计算环境中。在分布式计算环境中，程序模块可位于本地和远程存储器存储设备的两者中。
124.本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及方法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟
以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本公开的范围。
125.应当理解的是，本公开的上述具体实施方式仅仅用于示例性说明或解释本公开的原理，而不构成对本公开的限制。因此，在不偏离本公开的精神和范围的情况下所做的任何修改、等同替换、改进等，均应包含在本公开的保护范围之内。此外，本公开所附权利要求旨在涵盖落入所附权利要求范围和边界、或者这种范围和边界的等同形式内的全部变化和修改例。

技术特征：
1.一种网约车订单系统，包括第一订单系统，用于接收自有平台订单，其特征在于，还包括第二订单系统：所述第二订单系统用于接收聚合平台订单，所述第二订单系统包括若干数据库，每个数据库包含若干数据表，所述数据库和所述数据表分别分配有编号，编号顺序增加。2.根据权利要求1所述的系统，其特征在于，所述第二订单系统包括n个数据库，每个数据库包含k个数据表，n、k为自然数，所述数据库和所述数据表分别分配有编号包括：第一个数据库编号为1，后续数据库编号顺序增加，直至第n个数据库编号为n；数据库n第一个数据表编号为k(n-1)，后续数据表编号顺序增加，直至数据库n的第k个数据表表编号为kn-1。3.一种网约车订单生成方法，应用于如权利要求2所述的订单系统，其特征在于，包括：接收下单请求，所述下单请求至少包括乘车人手机号和打车渠道信息；基于所述打车渠道信息判断所述打车渠道是否属于高流量渠道列表，如是，则基于所述乘车人手机号在所述第二订单系统生成订单，如否，则在所述第一订单系统生成订单；返回对应订单系统生成的订单号。4.根据权利要求3所述的方法，其特征在于，还包括：如果在预设的同一时间间隔内接收到的下单请求超过预设阈值，且所述下单请求的打车渠道属于高流量渠道列表，则按预设规则在所述第二订单系统中增加1个或多个数据库。5.根据权利要求3所述的方法，其特征在于，所述基于所述乘车人手机号在第二订单系统生成订单包括：基于所述手机号获取下单数据表的数据表编号，其中，所述数据表编号＝所述手机号％(kn)；基于所述手机号获取下单数据库的数据库编号，其中，所述数据库编号＝math.floordiv(数据表编号，k)+1；在所述编号的下单数据库的所述编号的下单数据表中增加订单记录。6.一种网约车订单生成装置，其特征在于，包括：订单接收模块，用于接收下单请求，所述下单请求至少包括乘车人手机号和打车渠道信息；订单生成模块，用于基于所述打车渠道信息判断所述打车渠道是否属于高流量渠道列表，如是，则基于所述乘车人手机号在所述第二订单系统生成订单，如否，则在所述第一订单系统生成订单；订单号返回模块，用于返回对应订单系统生成的订单号。7.一种网约车订单查询方法，应用于如权利要求2所述的订单系统，其特征在于，包括：获取订单查询请求，基于所述查询请求获取网约车订单号；如果所述订单来自于高流量渠道，则基于所述订单号获取下单数据库和下单数据表的编号，在所述第二订单系统所述编号对应的下单数据库中的下单数据表中，基于所述订单号获取订单记录，如果所述订单不来自于高流量渠道，则在所述第一订单系统中，基于所述订单号获取订单记录；返回所述订单记录。
8.根据权利要求7所述的方法，其特征在于，所述基于所述订单号获取下单数据库和下单数据表的编号包括：计算所述第二订单系统包含的数据表总数的位数m，其中，m＝digit(kn)；基于所述订单号获取下单数据表的数据表编号，其中，所述数据表编号＝所述订单号后m位；基于所述订单号获取下单数据库的数据库编号，其中，所述数据库编号＝math.floordiv(数据表编号,k)+1。9.一种网约车订单查询装置，其特征在于，包括：第一获取模块，用于获取订单查询请求，基于所述查询请求获取网约车订单号；第二获取模块，用于如果所述订单来自于高流量渠道，则基于所述订单号获取下单数据库和下单数据表的编号，在所述第二订单系统所述编号对应的下单数据库中的下单数据表中，基于所述订单号获取订单记录，如果所述订单不来自于高流量渠道，则在所述第一订单系统中，基于所述订单号获取订单记录；返回模块，用于返回所述订单记录。10.一种电子设备，其特征在于：包括存储器和处理器，所述存储器，用于存储计算机程序；所述处理器，用于当执行所述计算机程序时，实现根据权利要求3-5任一项或权利要求7-8任一项所述的方法。

技术总结
本公开涉及网约车技术领域，具体涉及一种网约车订单系统及一种网约车订单生成方法。所述方法应用于网约车订单系统，包括：接收下单请求，所述下单请求至少包括乘车人手机号和打车渠道信息；基于所述打车渠道信息判断所述打车渠道是否属于高流量渠道列表，如是，则基于所述乘车人手机号在所述第二订单系统生成订单，如否，则在所述第一订单系统生成订单；返回对应订单系统生成的订单号。本公开实施例通过对来自于聚合平台和自有运力平台的网约车订单请求采用不同的订单系统处理，对于处理来自于聚合平台订单请求的订单系统分库分表，从而极大的提高下单与查询订单效率，提高了打车高峰期对聚合平台海量下单请求的响应及时性。峰期对聚合平台海量下单请求的响应及时性。峰期对聚合平台海量下单请求的响应及时性。


技术研发人员：赵雨
受保护的技术使用者：首约科技（北京）有限公司
技术研发日：2023.04.14
技术公布日：2023/7/25