一种道路数据处理系统的制作方法

1.本发明实施例涉及数据处理领域，特别是涉及一种道路数据处理系统。


背景技术：

2.道路数据处理系统(drc)可以为道路路况检测和车辆辅助驾驶提供数据处理支持。然而，相关技术中，单机drc的处理性能有限，无法满足大批量用户的数据请求处理，以致于无法及时响应用户请求。部署多台drc则会导致多台drc彼此之间难以实现消息通信和数据共享，导致多个路段的信息彼此隔离，无法实现多个路段的信息的融合计算。
3.基于此，亟需一种新的道路数据处理系统。


技术实现要素：

4.本发明提供一种道路数据处理系统，可以在接收到用户请求之后，根据用户请求的类型分别利用控制端和数据处理端对用户请求进行处理。
5.为了解决上述问题，本发明实施例提供了一种道路数据处理系统，包括：客户端、控制端以及数据处理端；
6.所述客户端在检测到用户的操作时，生成请求；
7.所述控制端对类型为控制类的请求进行处理，并将处理结果返回给所述客户端；
8.所述数据处理端对类型为数据处理类的请求进行处理，并将处理结果返回给所述客户端。
9.可选地，所述控制端与所述数据处理端分别为：部署在同一服务器上的第一进程和第二进程。
10.可选地，所述控制端与所述数据处理端分别为：部署在第一服务器上的第一进程和部署在第二服务器上的第二进程。
11.可选地，所述系统还包括：配置中心，所述控制端在当前接收到的请求的数量超出预设数量时，向所述配置中心发出控制端扩增请求；
12.所述配置中心根据所述控制端扩增加请求，在服务器上创建新的进程作为新的控制端。
13.可选地，所述系统还包括：配置中心，所述数据处理端在当前需要处理的数据量超出预设数据量时，向所述配置中心发出数据处理端扩容请求；
14.所述配置中心根据所述数据处理端扩容请求，在服务器上创建新的进程作为新的数据处理端。
15.可选地，所述客户端的数量是多个，分别为布设在不同路段上的道路监控数据采集单元或行驶在不同路段上的车辆中的车机、自动驾驶工控单元或应用程序，所述数据处理端的数量是多个，一个数据处理端用于处理一个路段上的客户端发出的数据处理类请求。
16.可选地，所述控制端执行以下步骤：
17.接收并检测所述客户端发送的请求的类型；
18.在所述类型为控制类的情况下，所述控制端对控制类的请求进行本地处理；
19.在所述类型为数据处理类的情况下，所述控制端将类型为数据处理类的请求转发给所述数据处理端；
20.接收所述数据处理端产生的处理结果并转发给所述客户端。
21.可选地，所述系统还包括：配置中心，实时检测每个路段当前已接入所述数据处理系统的客户端的数量，根据所述数据量，在服务器上创建相应数量的进程作为控制端。
22.可选地，所述系统还包括：配置中心，实时检测每个路段的当前交通情况，根据所述当前交通情况，在服务器上创建相应数量的进程作为数据处理端。
23.可选地，所述控制端与所述数据处理端之间的数据交互采用grpc网络通信，所述控制端和所述数据处理端分别连接nosql数据库，以存储处理结果和需要交互的数据。
24.在本发明实施例中提供了一种道路数据处理系统，包括：客户端、控制端以及数据处理端，在本发明中，将原有运行在一个服务器中一个进程(单机drc)的整体服务拆分为控制端和数据处理端，利用控制端处理控制类请求，利用数据处理端处理数据处理类请求，从而实现交互控制和数据处理的分离，以提高道路数据处理系统的响应速度。并且，在本发明中，多个数据处理端之间可以进行消息通信和数据共享，避免了信息隔离，提高了道路数据的融合计算能力。从而，本发明可以实现大批量用户请求的及时响应，同时满足大型复杂道路环境下的道路数据处理。
附图说明
25.为了更清楚地说明本发明实施例的技术方案，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
26.图1是本发明实施例提供的一种道路数据处理系统的示意图；
27.图2是本发明实施例提供的一种控制端执行步骤流程图；
28.图3是本发明实施例提供的另一种道路数据处理系统的示意图。
具体实施方式
29.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
30.在本发明中，基于现有的单机道路数据处理系统(drc)和drc集群部署两种技术方案中存在的问题，提出了一种分布式drc。
31.本发明实施例提出的一种道路数据处理系统100，包括：客户端101、控制端102以及数据处理端103，如图1所示：客户端101与控制端102之间进行交互，控制端102可以与数据处理端103进行交互。
32.所述客户端101在检测到用户的操作时，生成请求。
33.在本实施例中，客户端的数量是多个，分别为布设在不同路段上的道路监控数据采集单元或行驶在不同路段上的车辆中的车机、自动驾驶工控单元或应用程序。
34.其中，布设在不同路段上的道路监控数据采集单元用于采集道路数据(包括：道路车辆、道路障碍物等)上传到数据处理端，行驶在不同路段上的车辆中的车机、自动驾驶工控单元或应用程序用于为用户提供操作界面，以根据用户操作生成用户请求。
35.在本实施例中，用户可以在客户端上进行相应的操作，从而发起相应的请求，客户端在检测到用户的操作时，生成相应的请求发送给控制端。
36.在本实施例中，用户请求主要分为控制类请求和数据处理类请求。其中，控制类请求包括：网络连接请求、注册请求、配置请求等。数据处理类请求包括：数据上传请求、数据获取请求、数据计算请求等。
37.在本发明实施例中，若用户请求为控制类请求，则利用控制端对用户请求进行处理；若用户请求为数据处理类请求，则利用数据处理端对用户进行处理。
38.所述控制端102对类型为控制类的请求进行处理，并将处理结果返回给所述客户端。
39.具体地，控制端对控制类的请求进行本地处理，或者发送至云端服务器进行处理，从而得到处理结果，并将处理结果返回至客户端。
40.示例地，用户请求为认证请求，则控制端对用户请求中携带的用户信息与预先存储在本地的用户信息进行认证，认证成功则下发认证成功结果，认证失败则下发认证失败结果。
41.所述数据处理端103对类型为数据处理类的请求进行处理，并将处理结果返回给所述客户端。
42.具体地，数据处理端对数据处理类请求进行本地处理，或者与其他数据处理端进行交互以对数据处理请求进行请求，并将处理结果返回给客户端。
43.示例地，用户请求为路况检测请求，则数据处理端根据用户请求中携带的路段信息，在本地存储的道路信息中获取相关的路况信息，并下发至客户端。
44.在本实施例中，如图2所示，所述控制端执行以下流程：
45.步骤s110，接收并检测所述客户端发送的请求的类型。
46.在本实施例中，客户端与控制端之间进行交互，将生成的请求发送到控制端，并接收控制端返回的处理结果。
47.步骤s120，在所述类型为控制类的情况下，所述控制端对控制类的请求进行本地处理。
48.步骤s130，在所述类型为数据处理类的情况下，所述控制端将类型为数据处理类的请求转发给所述数据处理端。
49.步骤s140，接收所述数据处理端产生的处理结果并转发给所述客户端。
50.在本实施例中，若控制端接收到的请求是控制类请求，则控制端对该类请求进行本地处理，得到处理结果并返回客户端。若控制端接收到的请求是数据处理类请求，则客控制端对该类请求进行转发，将数据处理类请求转发至数据处理端，由数据处理端对其进行处理，数据处理端对数据处理请求进行处理后得到处理结果，将该处理结果返回控制端，控制端在接收到数据处理端发送的处理结果之后，将该处理结果转发至客户端。
51.在本发明实施例中，通过分离控制端和数据处理端，客户端不直接与数据处理端进行交互，而是与控制端进行交互，通过控制端将数据处理类请求转发至数据处理端，并将数据处理端得到的数据处理结果转发至客户端，客户端只能从控制端获取到与自身请求相关的数据，从而可以保证数据处理端的数据安全。
52.在本发明一种可选的实施例中，所述控制端与所述数据处理端分别为：部署在同一服务器上的第一进程和第二进程。
53.在本实施例中，控制端和数据处理端可以在同一服务器上的不同进程中运行，以充分利用服务器性能。
54.在本发明一种可选的实施例中，述控制端与所述数据处理端分别为：部署在第一服务器上的第一进程和部署在第二服务器上的第二进程。
55.在本实施例中，控制端和数据处理端可以在不同服务器上的不同进程中运行，从而提高响应速度进而提高控制端和数据处理端的服务质量。
56.在本发明实施例中，将原有运行在一个服务器中一个进程(单机drc)的整体服务拆分为控制端和数据处理端，利用控制端处理控制类请求，利用数据处理端处理数据处理类请求，从而实现交互控制和数据处理的分离，以提高道路数据处理系统的响应速度。并且，在本发明中，多个数据处理端之间可以进行消息通信和数据共享，避免了信息隔离，提高了道路数据的融合计算能力。从而，本发明可以实现大批量用户请求的及时响应，同时满足大型复杂道路环境下的道路数据处理。
57.本发明实施例提出的一种道路数据处理系统200，包括：客户端201、控制端202、数据处理端203以及配置中心204，如图2所示：客户端201与控制端202之间进行交互，控制端202可以与数据处理端203进行交互，配置中心204对控制端202和数据处理端203进行统一管理。
58.在本实施例中，所述控制端202在当前接收到的请求的数量超出预设数量时，向所述配置中心204发出控制端扩增请求。
59.在实际应用中，当控制端当前接收到的请求数量超出预设数量时，即表明当前控制端过载，可能无法及时处理当前所有用户请求数量，需要对控制端进行扩增。
60.所述配置中心204根据所述控制端扩增加请求，在服务器上创建新的进程作为新的控制端。
61.配置中心在接收到控制端发出的扩增请求之后，可以任选一台或多台可用服务器，在所选服务器上创建新的进程作为新的控制端，以对当前用户请求数量进行处理。
62.在本实施例中，所述数据处理端203在当前需要处理的数据量超出预设数据量时，向所述配置中心发出数据处理端扩容请求。
63.在实际应用中，当数据处理端需要处理的数据量超出预设数量时，即表明当前数据处理端过载，可能无法及时处理当前所有的数据处理请求，需要对数据处理端进行扩增。
64.所述配置中心204根据所述数据处理端扩容请求，在服务器上创建新的进程作为新的数据处理端。
65.配置中心在接收到数据处理端发出的扩增请求之后，可以任选一台或多台可用服务器，在所选服务器上创建新的进程作为新的数据处理端，以对当前需要处理的数据进行处理。
66.在本发明一种可选的实施例中，配置中心204还可以根据实时检测结果主动对控制端202和数据处理端203进行配置管理。
67.配置中心204可以实时检测每个路段当前已接入所述数据处理系统的客户端的数量，根据所述数据量，在服务器上创建相应数量的进程作为控制端。
68.具体的，配置中心可以根据实时检测到的当前接入系统的客户端的数量，实时地对控制端的配置数量进行调整，在当前接入系统的客户端数量较大的情况下，扩增控制端的配置数量，以适应当前实际需求。
69.配置中心204还可以实时检测每个路段的当前交通情况，根据所述当前交通情况，在服务器上创建相应数量的进程作为数据处理端。
70.具体的，配置中心可以根据实时检测到每个路段的当前交通情况，实时地对数据处理端的配置数量进行调整，在交通情况复杂的情况下，扩增数据处理端的配置数量，以适应当前实际需求。
71.示例地，为城市路段为例，配置中心可以根据当前城市的客户端接入量和实际交通情况进行控制端和数据处理端的多服务架设，以得到符合当前城市的实际需求的道路数据处理系统。
72.在本实施例中，配置中心可以采用etcd集群，对整个分布式drc的各项服务的配置文件进行统一管理，完成各个服务上下线的注册和感知。
73.在本技术一种可选的实施例中，配置中心204还可以实时检测控制端202和数据处理端203的可用性。具体的，当控制端或数据处理端配置为冗余时，若配置中心实时检测到某控制端或数据处理端下线，则立即通知冗余的其他可用的控制端或数据处理端上线接替工作。
74.在本实施例中，通过配置中心实时对各项服务进行统一管理，使得道路数据处理系统的部署更加灵活，更加符合实际需求。
75.在本发明实施例中，当交互控制服务无法满足当前接入量时可扩增drc_cp，当数据处理服务无法满足当前数据处理量时可扩增drc_up。本发明中，控制端和数据处理端的分布式部署使得道路数据处理系统的部署更加灵活，更加符合实际需求。
76.在一种可选的实施例中，所述数据处理端203的数量是多个，一个数据处理端用于处理一个路段上的客户端发出的数据处理类请求。
77.在本实施例中，对于数据客户端，按照不同的路段进行任务分割。以高速路为例，将长途高速划分为多个高速路段，每个数据处理端负责处理一个高速路段上的数据处理类请求。在具体实施时，还可以按照对道路数据处理系统所覆盖的完整地图区域进行划分，得到多个子区域，每个数据处理端负责一个子区域内的客户端发出的数据处理类请求。
78.在具体实施时，也可以按照预设数量个路侧单元的覆盖范围作为一个数据处理端的覆盖区域，则数据处理端负责处理其覆盖区域内的客户端发出的数据处理类请求。其中，路侧单元为布设在不同路段上的道路监控数据采集单元，用于采集相应路段上的道路数据。
79.在相关技术中，常见的分布式方案均是针对业务功能进行分割，实现对各个业务的独立部署，以提高业务处理的性能。在处理涉及到多种业务的用户请求时，这种分布式方案需要对多个业务功能进行远程调用，从而增加系统内的网络开销。而在本发明实施例中，
采用分布式的控制端和数据处理端的部署，又按照覆盖区域对数据处理端进行分割，不同覆盖区域的数据处理端分别处理对应区域的数据处理请求。从而，对于某一区域上的数据处理请求而言，相应的数据处理端在对该请求进行处理时，无需远程调用其他数据处理端，依据本地存储的数据即可完成数据处理，从而节省系统内的网络开销，进一步提升服务响应速度。
80.在本实施例中，客户端与控制端连接，不对数据处理端进行感知。从而，在实际应用中，当车辆行驶在道路上时，客户端(例如车辆中的车机)由于所处的位置发生变化，当客户端所处的位置从一个数据处理端的覆盖范围内移动到另一个数据处理端的覆盖范围内时，该客户端的数据处理请求所涉及的数据处理端也需要发生变更，但是由于客户端直接与控制端进行连接，因此不会感知到数据处理端的切换，从而避免在客户端上不断的进行数据处理端的切换，降低客户端的自主切换耗时和系统设计复杂度。
81.在本发明提供的分布式drc中，多个控制端和多个数据处理端之间可以进行信息交互，不同区域的数据处理端之间也可以进行交互。因此，本发明提供的分布式drc中不会产生数据隔离，可以通过多个控制端和多个数据处理端之间的彼此交互实现全路段覆盖。
82.本发明所提供的道路数据处理系统以c 语言为开发语言，其中，为了保证数据交互的高效性，所述控制端与所述数据处理端之间的数据交互采用grpc网络通信，可满足100ms内的数据请求回复，以实现多个控制端与多个数据处理端之间的消息处理和数据共享。
83.在本实施例中，多个数据处理端之间可以通过redis实现数据共享以进行数据融合计算。
84.示例地，假设在高速路段上行驶有两辆汽车：汽车a和汽车b，其中，汽车a和汽车b相距500米，但是汽车a处于数据处理端a覆盖范围内，汽车b处于数据处理端b覆盖范围内。此时，汽车a发生交通事件，并将自身位置和事件等相关消息作为事件信息a通过控制端上传至数据处理端a，数据处理端a将该信息同步至redis。
85.此时汽车b向控制端发起相关交通事件获取请求，控制端将该请求转发至数据端b进行处理，则数据处理端b可以结合汽车b的当前位置，并通过redis获取到距离汽车b 500米范围内的汽车a的事件信息a，并将该事件信息通过控制端下发至汽车b，从而汽车b可以根据该事件信息作出相应的响应。
86.在相关技术中，若汽车a和汽车b处于两个不同的drc的覆盖范围内(假设为：drc
‑
a和drc
‑
b)，则汽车b在发起交通事件获取请求时，drc
‑
b无法与drc
‑
a进行数据共享，也就无法获取到汽车a的交通事件信息，从而无法将相关信息下发至汽车b，导致处理结果中存在信息遗漏。
87.在本实施例提供的道路数据处理系统中，不同的数据处理端之间可以通过数据库实现数据共享，从而避免了信息隔离，提高了道路数据的融合计算能力，使得客户端可以获取到由全局覆盖的信息计算得到的处理结果。
88.在本实施例中，所述控制端和所述数据处理端分别连接nosql数据库，以存储处理结果和需要交互的数据。从而在本发明中，对于客户端发起的请求的处理可以以本地处理为主。
89.在本实施例中，可以采用zabbix和grafana对道路数据处理系统进行监控，实现日
志等文件的可视化和事故告警。
90.在本实施例中，道路数据处理系统还可以设置有云端服务器，控制端以及数据处理端与云端进行交互采用kafka消息队列。
91.本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。
92.以上对本发明提供的道路数据处理系统进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。
93.通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件实现。基于这样的理解，上述技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。