CN104616238A - 用于分配订单的方法及装置 - Google Patents

Abstract

本公开的实施例公开了一种用于分配订单的方法及装置。该方法包括：从多个第一用户和多个第二用户分别接收用于订单分配的初始数据；基于所述初始数据，生成用于订单分配的中间数据；存储用于订单分配的所述中间数据；基于存储的所述中间数据，生成订单分配的结果；以及向所述第一用户和所述第二用户发送所述订单分配的结果。本公开的实施例能够针对高并发的订单数据进行高可用的订单分配。通过异步化的设计思想降低了订单数据流量对于订单分配模块的冲击，平滑了系统流量并且提升了系统伸缩性，解决了订单分配系统面临的主要挑战。

Description

用于分配订单的方法及装置

技术领域

本公开的实施例涉及订单分配，具体涉及一种用于分配订单的系统及方法。

背景技术

随着互联网及移动设备的迅猛发展，特别是智能手机和智能移动导航系统的普及，给人们的出行带来了极大的便利。随着城市的发展，打车需求已经是社会各阶层人士的普遍需求。打车平台需要面对每天高达几千万的订单出行数据，在上下班的高峰时段订单的数量甚至会接近每分钟数十万个。高并发的订单量对于打车平台的订单分配系统将会是极大的挑战。

针对特定的业务场景，打车平台的订单分配系统主要面临以下几个挑战：

数据集中性问题：订单及出行数据的分布比较集中。例如，周一上午7点至9点，周五下午17点至19点，订单的发生量是其他时段的10倍左右，需要系统具有足够的弹性面对数据流量的剧烈变化；

订单匹配的问题：订单匹配的计算量巨大。例如，北京市国贸附件下班的高峰期，针对数以千计的订单量和周边数以千计的司机，需要在短时间内完成上百万次的订单匹配工作。

系统稳定性问题：订单分配系统需要7×24小时提供服务，任何一次系统短时间的宕机，都会对人们的出行造成影响。

打车平台的订单分配系统设计的好坏将极大地影响打车平台的服务质量和打车用户的用户体验。

发明内容

本公开的实施例旨在提供一种用于分配订单的方法及装置，可以针对高并发的订单数据进行高可用的订单分配。通过异步化的设计思想降低了订单数据流量对于订单分配模块的冲击，平滑了系统流量并且提升了系统伸缩性，解决了以上所述的问题。

根据本公开的一个方面，提供了一种用于分配订单的方法，该方法包括：从多个第一用户和多个第二用户分别接收用于订单分配的初始数据；基于所述初始数据，生成用于订单分配的中间数据；存储用于订单分配的所述中间数据；基于存储的所述中间数据，生成订单分配的结果；以及向所述第一用户和所述第二用户发送所述订单分配的结果。

在一个实施例中，所述初始数据包括以下的一个或多个：所述第一用户的名称；所述第一用户的坐标；订单的标识符ID；订单的起始地址和目的地址；订单的特征；所述第二用户的标识符ID；以及所述第二用户的坐标。

在另一个实施例中，所述中间数据包括：标识信息，所述标识信息包括待分配的订单的标识符ID和待分配订单的第二用户的标识符ID；以及特征信息，所述特征信息包括所述待分配的订单的特征信息和所述待分配订单的第二用户的特征信息。

在又一个实施例中，所述订单分配的结果包括：所述待分配的订单的ID和所述待分配订单的第二用户的ID之间的匹配关系。

在再一个实施例中，存储用于订单分配的所述中间数据包括：通过缓冲服务单元来存储所述标识信息；以及通过特征服务单元来存储所述特征信息。

在再一个实施例中，基于存储的所述中间数据，生成订单分配的结果包括：从所述缓冲服务单元获取所述标识信息，并且从所述特征服务单元获取所述特征信息；以及基于所述标识信息和所述特征信息，计算所述待分配的订单的ID和所述待分配订单的第二用户的ID之间的匹配关系。

根据本公开的另一方面，提供了一种用于分配订单的装置，该装置包括：数据接收模块，用于从多个第一用户和多个第二用户分别接收用于订单分配的初始数据；数据处理模块，用于基于所述初始数据，生成用于订单分配的中间数据；数据服务模块，用于存储用于订单分配的所述中间数据；计算服务模块，用于基于存储的所述中间数据，生成订单分配的结果；以及推送服务模块，用于向所述第一用户和所述第二用户发送所述订单分配的结果。

在一个实施例中，所述初始数据包括以下的一个或多个：所述第一用户的名称；所述第一用户的坐标；订单的标识符ID；订单的起始地址和目的地址；订单的特征；所述第二用户的标识符ID；以及所述第二用户的坐标。

在另一个实施例中，所述中间数据包括：标识信息，所述标识信息包括待分配的订单的标识符ID和待分配订单的第二用户的标识符ID；以及特征信息，所述特征信息包括所述待分配的订单的特征信息和所述待分配订单的第二用户的特征信息。

在又一个实施例中，所述订单分配的结果包括：所述待分配的订单的ID和所述待分配订单的第二用户的ID之间的匹配关系。

在再一个实施例中，所述数据服务模块包括：缓冲服务单元，用于存储所述标识信息；以及特征服务单元，用于存储所述特征信息。

在再一个实施例中，所述计算服务模块用于：从所述缓冲服务单元获取所述标识信息，并且从所述特征服务单元获取所述特征信息；以及基于所述标识信息和所述特征信息，计算所述待分配的订单的ID和所述待分配订单的第二用户的ID之间的匹配关系。

本公开的实施例能够针对高并发的订单数据进行高可用的订单分配。通过异步化的设计思想降低了订单数据流量对于订单分配模块的冲击，平滑了系统流量并且提升了系统伸缩性，解决了上述订单分配系统面临的问题。

附图说明

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

图1示意性地图示了根据本公开的实施例的用于分配订单的方法100的流程图；

图2示意性地图示了根据本公开的实施例的用于分配订单的装置200的框图；

图3示范性地图示了根据本公开的实施例的在打车平台中用于分配订单的装置300的架构图。

具体实施方式

在下文中，将参考附图详细描述本公开的各个示例性实施例。应当注意，这些附图和描述涉及的仅仅是作为示例性的优选实施例。应该指出的是，根据随后描述，很容易设想出此处公开的结构和方法的替换实施例，并且可以在不脱离本公开要求保护的原理的情况下使用这些替代实施例。

应当理解，给出这些示例性实施例仅仅是为了使本领域技术人员能够更好地理解进而实现本公开，而并非以任何方式限制本公开的范围。

在此使用的术语“包括”、“包含”及类似术语应该被理解为是开放性的术语，即“包括/包含但不限于”。术语“基于”是“至少部分地基于”。术语“一个实施例”表示“至少一个实施例”；术语“另一实施例”表示“至少一个另外的实施例”。其他术语的相关定义将在下文描述中给出。

参考图1，其示意性地图示了根据本公开的实施例的用于分配订单的方法100的流程图。如图1所示，该方法包括步骤S101至步骤S105。

在步骤S101，从多个第一用户和多个第二用户分别接收用于订单分配的初始数据。例如，在打车平台中，第一用户为打车用户，即订单的发送者；第二用户为司机，即订单的接收者。

在步骤S101，将从多个打车用户和多个司机接收他们实时上传的数据。

根据本公开的实施例，在此所述的初始数据包括但不限于：所述第一用户的名称；所述第一用户的坐标；订单的标识符ID；订单的起始地址和目的地址；订单的特征；所述第二用户的标识符ID；以及所述第二用户的坐标。例如，在打车平台中，初始数据包括：打车用户的名称；打车用户的坐标；打车订单的标识符ID；打车订单的起始地址和目的地址；以及打车订单的特征，例如所述订单是实时的还是预约的、所述订单是否去往特定地址(例如机场)以及所述订单的价值等；司机的标识符ID；以及司机的坐标。

接下来，方法进行至步骤S102,基于所述初始数据，生成用于订单分配的中间数据。

根据本公开的实施例，在此所述的中间数据包括：标识信息，所述标识信息包括待分配的订单的标识符ID和待分配订单的第二用户的标识符ID；以及特征信息，所述特征信息包括所述待分配的订单的特征信息和所述待分配订单的第二用户的特征信息。例如，在打车平台中，业务系统接收了用户下发的订单和司机上传的坐标这两路实时数据后，进行相关的逻辑处理(例如，数据有效性验证等)，分别提取了新发订单的ID和需要获取订单的司机ID，以及新发订单的特征和需要获取订单的司机的特征。其中，新发订单的特征包括订单发送者的名称及坐标、订单的起始地址和目标地址、订单的其他特征数据，比如订单的模式(比如，实时的或者预约的)、订单的价值等；司机的特征包括司机当前的坐标等。

接下来，方法进行至步骤S103，存储用于订单分配的所述中间数据。例如，在打车平台中，业务系统提取了新发订单的ID和需要获取订单的司机ID，以及新发订单的特征和需要获取订单的司机的特征后，将新发订单的ID和需要获取订单的司机ID写入缓冲服务单元，将新发订单的特征和需要获取订单的司机的特征写入特征服务单元。通过对待分配的订单数据和需要获取订单的司机数据进行缓冲，将需要同步分配的需求异步化，可以有效地应对在热点时段或者热点区域突发的大量订单数据，缓解后续订单分配系统的计算压力。

接下来，方法进行至步骤S104，基于存储的所述中间数据，生成订单分配的结果。根据本公开的实施例，在此所述的订单分配的结果指所述待分配的订单的ID和所述待分配订单的第二用户的ID之间的匹配关系。例如，在打车平台中，订单分配系统将新发订单分配给需要获取订单的司机，订单的ID和司机的ID之间的匹配关系即为最终订单分配的结果。

根据本公开的实施例，步骤S104进一步包括从所述缓冲服务单元获取所述标识信息，并且从所述特征服务单元获取所述特征信息；以及基于所述标识信息和所述特征信息，计算所述待分配的订单的ID和所述待分配订单的第二用户的ID之间的匹配关系。例如，在打车平台中，下游计算服务模块通过主动拉取的操作模式，从缓冲服务单元和特征服务单元主动获取数据，实时新发订单和需要获取订单的司机的匹配需求，提升了系统的计算能力和系统的稳定性；机器的处理性能瓶颈与宕机都可以通过机器的扩充来解决。

最后，方法进行至步骤S105，向所述第一用户和所述第二用户发送所述订单分配的结果。例如，在打车平台中，由计算服务模块计算得出的订单分配结果交给推送服务模块，由推送服务模块向打车用户及司机推送订单分配的结果。

参考图2，其示意性地图示了根据本公开的实施例的用于分配订单的装置200的框图。装置200包括：数据接收模块201，用于从多个第一用户和多个第二用户分别接收用于订单分配的初始数据；数据处理模块202，用于基于所述初始数据，生成用于订单分配的中间数据；数据服务模块203，用于存储用于订单分配的所述中间数据；计算服务模块204，用于基于存储的所述中间数据，生成订单分配的结果；以及推送服务模块205，用于向所述第一用户和所述第二用户发送所述订单分配的结果。

根据本公开的实施例，在此所述的初始数据包括但不限于：所述第一用户的名称；所述第一用户的坐标；订单的标识符ID；订单的起始地址和目的地址；订单的特征；所述第二用户的标识符ID；以及所述第二用户的坐标。例如，在打车平台中，初始数据包括：打车用户的名称；打车用户的坐标；打车订单的标识符ID；打车订单的起始地址和目的地址；以及打车订单的特征，例如所述订单是实时的还是预约的、所述订单是否去往特定地址(例如机场)以及所述订单的价值等；司机的标识符ID；以及司机的坐标。

根据本公开的实施例，所述中间数据包括：标识信息，所述标识信息包括待分配的订单的标识符ID和待分配订单的第二用户的标识符ID；以及特征信息，所述特征信息包括所述待分配的订单的特征信息和所述待分配订单的第二用户的特征信息。例如，在打车平台中，业务系统接收了用户下发的订单和司机上传的坐标这两路实时数据后，进行相关的逻辑处理(例如，数据有效性验证等)，分别提取了新发订单的ID和需要获取订单的司机ID，以及新发订单的特征和需要获取订单的司机的特征。其中，新发订单的特征包括订单发送者的名称及坐标、订单的起始地址和目标地址、订单的其他特征数据，比如订单的模式(比如，实时的或者预约的)、订单的价值等；司机的特征包括司机当前的坐标等。

根据本公开的实施例，所述订单分配的结果包括：所述待分配的订单的ID和所述待分配订单的第二用户的ID之间的匹配关系。

根据本公开的实施例，所述数据服务模块包括：缓冲服务单元，用于存储所述标识信息；以及特征服务单元，用于存储所述特征信息。

例如，在打车平台中，缓冲服务单元可以通过nginx(即enginex，一种高性能的超文本传输协议HTTP和反向代理服务器，也是邮件访问协议IMAP/邮局协议版本3POP3/简单邮件传输协议SMTP代理服务器)+LUA(一种轻巧的脚本语言，是巴西里约热内卢天主教大学(Pontifical Catholic University of Rio de Janeiro)里的一个研究小组，由Roberto Ierusalimschy、Waldemar Celes和Luiz Henrique deFigueiredo所组成并于1993年开发)+redis(一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、键-值数据库，并提供多种语言的应用程序接口API)的模式开发，大大提升了系统的吞吐量，很好地解决了上游数据流量的集中性问题，避免高并发的数据流量对下游系统的冲击。特征服务单元存储订单与司机的特征数据，采用同步更新的服务化模式。特征服务单元将零散的订单和司机的特征数据进行聚合，降低了获取订单与司机的特征数据的输入输出I/O消耗，大大降低了下游系统的响应时间。

根据本公开的实施例，所述计算服务模块用于：从所述缓冲服务单元获取所述标识信息，并且从所述特征服务单元获取所述特征信息；以及基于所述标识信息和所述特征信息，计算所述待分配的订单的ID和所述待分配订单的第二用户的ID之间的匹配关系。

参考图3，其示范性地图示了根据本公开的实施例的在打车平台中用于分配订单的装置300的架构图。其中分为两个部分：业务系统301和订单分配系统302。业务系统301中的订单系统301a体现了装置200中的数据接收模块201和数据处理模块202。订单分配系统302中的缓冲服务302a和特征服务302b体现了装置200中的数据服务模块203，其中缓冲服务302a体现了所述缓冲服务单元，特征服务302b体现了所述特征服务单元。订单分配系统302中的策略计算服务302c体现了装置200中的计算服务模块204。订单分配系统302中的推送服务302d体现了装置200中的推送服务模块205。

综上所述，根据上述本公开的实施例，提供了一种用于分配订单的方法及装置。该方法包括：从多个第一用户和多个第二用户分别接收用于订单分配的初始数据；基于所述初始数据，生成用于订单分配的中间数据；存储用于订单分配的所述中间数据；基于存储的所述中间数据，生成订单分配的结果；以及向所述第一用户和所述第二用户发送所述订单分配的结果。本公开的实施例能够针对高并发的订单数据进行高可用的订单分配。通过异步化的设计思想降低了订单数据流量对于订单分配模块的冲击，平滑了系统流量并且提升了系统伸缩性，解决了订单分配系统面临的主要挑战。

显然，本领域的技术人员应该明白，上述的本公开的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本公开不限制于任何特定的硬件和软件结合。

以上所述仅为本公开可选实施例，并不用于限制本公开，对于本领域的技术人员来说，本公开可以有各种更改和变化。凡在本公开的精神和原则之内，所作的任何修改、等效替换、改进等，均应包含在本公开的保护范围之内。

Claims (12)

1.一种用于分配订单的方法，包括：

从多个第一用户和多个第二用户分别接收用于订单分配的初始数据；

基于所述初始数据，生成用于订单分配的中间数据；

存储用于订单分配的所述中间数据；

基于存储的所述中间数据，生成订单分配的结果；以及

向所述第一用户和所述第二用户发送所述订单分配的结果。

2.根据权利要求1所述的方法，其中所述初始数据包括以下的一个或多个：

所述第一用户的名称；

所述第一用户的坐标；

订单的标识符ID；

订单的起始地址和目的地址；

订单的特征；

所述第二用户的标识符ID；以及

所述第二用户的坐标。

3.根据权利要求1所述的方法，其中所述中间数据包括：

标识信息，所述标识信息包括待分配的订单的标识符ID和待分配订单的第二用户的标识符ID；以及

特征信息，所述特征信息包括所述待分配的订单的特征信息和所述待分配订单的第二用户的特征信息。

4.根据权利要求3所述的方法，其中所述订单分配的结果包括：

所述待分配的订单的ID和所述待分配订单的第二用户的ID之间的匹配关系。

5.根据权利要求3所述的方法，其中存储用于订单分配的所述中间数据包括：

通过缓冲服务单元来存储所述标识信息；以及

通过特征服务单元来存储所述特征信息。

6.根据权利要求5所述的方法，其中基于存储的所述中间数据，生成订单分配的结果包括：

从所述缓冲服务单元获取所述标识信息，并且从所述特征服务单元获取所述特征信息；以及

基于所述标识信息和所述特征信息，计算所述待分配的订单的ID和所述待分配订单的第二用户的ID之间的匹配关系。

7.一种用于分配订单的装置，包括：

数据接收模块，用于从多个第一用户和多个第二用户分别接收用于订单分配的初始数据；

数据处理模块，用于基于所述初始数据，生成用于订单分配的中间数据；

数据服务模块，用于存储用于订单分配的所述中间数据；

计算服务模块，用于基于存储的所述中间数据，生成订单分配的结果；以及

推送服务模块，用于向所述第一用户和所述第二用户发送所述订单分配的结果。

8.根据权利要求7所述的装置，其中所述初始数据包括以下的一个或多个：

所述第一用户的名称；

所述第一用户的坐标；

订单的标识符ID；

订单的起始地址和目的地址；

订单的特征；

所述第二用户的标识符ID；以及

所述第二用户的坐标。

9.根据权利要求7所述的装置，其中所述中间数据包括：

标识信息，所述标识信息包括待分配的订单的标识符ID和待分配订单的第二用户的标识符ID；以及

特征信息，所述特征信息包括所述待分配的订单的特征信息和所述待分配订单的第二用户的特征信息。

10.根据权利要求9所述的装置，其中所述订单分配的结果包括：

所述待分配的订单的ID和所述待分配订单的第二用户的ID之间的匹配关系。

11.根据权利要求9所述的装置，其中所述数据服务模块包括：

缓冲服务单元，用于存储所述标识信息；以及

特征服务单元，用于存储所述特征信息。

12.根据权利要求11所述的装置，其中所述计算服务模块用于：

从所述缓冲服务单元获取所述标识信息，并且从所述特征服务单元获取所述特征信息；以及

基于所述标识信息和所述特征信息，计算所述待分配的订单的ID和所述待分配订单的第二用户的ID之间的匹配关系。