智慧交通大脑一体化管理平台整体建设方案V0

智慧交通大脑一体化管理平台整体建设方案V6.0管理平台智慧交通大脑一体化管理平台整体建设方案V6.0目录TOC\o"1-5"\h\z\o"CurrentDocument"第1章 前言 11\o"CurrentDocument"第2章 总体设计 12系统概述 12系统设计原则 14系统框架 16\o"CurrentDocument"第3章 交通大脑采集子系统 20前端采集技术 20数据共享和交换平台 22框架支撑平台 23基础网络服务平台 23架构 24服务端NetServer 25NetBusiness 25NetClient 26核心技术 26EPOLL多路复用I/O模型 26共享内存数据库 29智慧交通大脑一体化管理平台整体建设方案V6.0TOC\o"1-5"\h\z概述 29设计思路 30MEMORYCACHE的通道 30消息组件 40日志管理 44系统预警及系统告警与状态管理 45一致性哈希分发 46\o"CurrentDocument"第4章 大数据资源整合存储子系统 58基础交通数据 58城市路网数据 59公交线路数据 106公交车辆数据 109长途客运车数据 110出租车数据 113危化品车数据 114共享单车数据 115火车客运数据 116民航客运数据 119智慧交通大脑一体化管理平台整体建设方案V6.0TOC\o"1-5"\h\z交通资产数据 121出行需求数据 122公路费用数据 127气象数据 127监控设备数据 128追逃车辆数据 129实时采集数据 129实时计算数据 129城市交通运行数据 130公交车实时位置数据 133公交（地铁）卡刷卡数据 134长途客车实时数据 135出租车实时数据 136危化品车实时数据 137共享单车实时数据 138路口通行量 139套牌嫌疑车数据 139基于车辆识别的OD分析数据 140智慧交通大脑一体化管理平台整体建设方案V6.0TOC\o"1-5"\h\z基于车辆识别的车辆数据 141第5章 大数据清洗子系统 144概述 144数据清洗 144缺失值处理 145数据选择 146数据变换 146数据集成 147数据削减 148数据清洗评估 149在交通领域的应用 150数据清洗方法 152错误数据的判别和修正 152丢失数据补齐 163冗余数据简约 172基于Hadoop的分布式数据清洗 177第6章 大数据融合分析子系统 210交通调查指标数据计算 211智慧交通大脑一体化管理平台整体建设方案V6.0TOC\o"1-5"\h\z概述 211处理流程 214D= 218交通运行指数计算 221概述 221交通运行指数各项指标计算 224信号优化 232自适应信控配时计算 232CARREN 257ADS 258基于大数据的OD分析 284概述 284基于Hadoop大数据OD分析 289基于移动通信手机定位数据的OD分析 301基于车辆识别的大数据套牌车分析 342概述 343流式计算Storm简介 345框架 349智慧交通大脑一体化管理平台整体建设方案V6.0TOC\o"1-5"\h\z技术实现 351实时数据 352基于Strom流式计算的数据分析. 354尾气排放分析 358概述 358传统的计算模型 359基于Hadoop的城市交通尾气计算模型 366交通信息发布系统 369设计原则 369总体诱导方案设计 370杆件及基础 373主要设备技术参数 374.色度性能 374.视认性 374.电气安全性能 375.环境适应性能 375.功能要求 376.材料要求 376智慧交通大脑一体化管理平台整体建设方案V6.0TOC\o"1-5"\h\z.指标要求 377第7章 统一消息服务子系统 378概述 378服务接口 379公交优先通行系统接口 379城市交通运行监测平台接口 381第8章 三维GIS平台子系统 385概述 385国内外应用现状 385建设需求分析 387建设范围 388建设内容 388建设目标 389三维系统平台介绍 389三维GIS系统平台构成 390三维GIS地图特点 391三维地图模型设计与建设 392三维GIS地图模型设计 392智慧交通大脑一体化管理平台整体建设方案V6.0TOC\o"1-5"\h\z三维系统的建设 398三维数据的建设 401系统软硬件环境 405第9章 系统规划和平台建设 408存储规划 408数据库存储. 408视频云存储. 412数据库规划 423Oracle数据库规划 423数据对象的命名规范 423Hbase数据库规划 4302、ROWKEYS设计 4313、列族CF设计 431主机规划 431采集主机规划 432Hadoop集群主机规划 434Storm集群主机规划 436统一消息服务平台主机规划 437智慧交通大脑一体化管理平台整体建设方案V6.0TOC\o"1-5"\h\z云平台建设 438云平台总体架构 439云平台资源池设计 441虚拟数据中心VDC设计 444存储资源池设计 447配置清单 451第10章大数据支撑平台系统的性能设计要求 453系统的处理能力 453系统的可用性 454系统的安全性 45410智慧交通大脑一体化管理平台整体建设方案V6.0第1章前言智慧交通大脑平台是将先进的信息技术、数据通讯传输技术、电子传感技术、电子控制技术及计算机处理技术等有效的集成运用于整个地面交通管理系统而建立的一种在大范围内、全方位发挥作用的、实时、准确、高效的综合交通运输管理系统。智慧交通大脑平台作为智慧交通建设的核心和数据采集、处理、融合、应用的枢纽，将智能交通建设的各个外场子系统的数据进行实时的采集、转换、处理及存储，并在数据集成、融合、分析挖掘的基础上，汇聚于公安交通的智慧应用中，大大推进了交通业务的智能化和智慧化，提高了交警各部门人员的工作效率。智慧交通大脑平台集成了信息化、流程化、规范化的集成管理与指挥调度、接处警、设施维护管理、运营服务等智慧交通业务功能。指挥中心指挥调度人员可以基于GIS电子地图实时监控城市道路的实时路况、警情在地图上的实时位置、处理过程的监控、警力实时位置的监控、设施设备的实时运行状态，还实现了监控视频的实时访问、信号控制设备的远程控制以及诱导屏的实时发布等功能。11智慧交通大脑一体化管理平台整体建设方案V6.0第2章总体设计系统概述城市交通服务提供全面的路况，需要交通监测网对城市道路交通状况、交通流信息、交通违法行为等的全面监测，采集、处理及分析大量的实时监测数据，具有数据量巨大的特点；随着城市机动车保有量不断提高，城市道路交通状况日趋复杂化，交通流特性呈现随时间变化大、区域关联性强的特点，需要根据实时的交通流数据及时全面采集、处理和分析等，因此具有系统负载时变性高、波动大的特点应支持低延迟、高并发事务；公众出行服务对交通信息发布的时效性要求高，需将准确的信息及时提供给不同的需求主体，信息处理、分析时效性要求高，这给交通大脑支撑平台提出了挑战。交通大脑支撑平台面对海量数据，系统不能仅依靠少数几台机器的升级满足数据量的增长，必须做到横向可扩展，既满足性能的要求，也满足存储的要求；由于服务需求的多样化，平台既要支持交通数据流的实时分析与处理又要支持复杂查询与深度分析所需的高性能、低延迟需求。平台需具有高度容错性，大数据的容错性要求在作业执行的过程中，一个参与节点失效不需要重做整个作业。另外平台应支持异构环境，交通大脑平台的建设是分步骤的，分阶段进行的。12智慧交通大脑一体化管理平台整体建设方案V6.0大数据支撑平台囊括了城市交通运行的基本数据，大数据支撑平台系统的设计、实施，按照一切从实际出发，遵循经济实用的原则，对于整个城市交通运行状态检测的整个过程可以分为确定数据采集目标、采集数据、分析数据和功能实现四个阶段。第一阶段，确定数据采集目标。目标就是监测的对象，首先要定义哪些对象是城市交通运行需要检测采集数据的，从社会经济、城市基础设施和人民生活等多个方面进行考虑。第二阶段，采集数据。确定好城市交通运行需要检测采集的数据目标之后，可以从相关部门或者采用相关仪器设备及手段进行数据采集。第三阶段，分析数据。城市交通运行特征处于'常态”和“非常态”，需要对采集的数据进行全方位的分析，由“常态”到“非常态”的一个动态过程，包括很多特殊情况的孕育、发展、扩大和爆发。通过对采集到的数据进行建模等方式来统计分析其诱发因素，以各相关管理部门、工作人员能迅速清晰掌握了解情况的方式进行展现。第四阶段，功能实现。展示城市运行实时监测状况，显示各项数据分析结果，及多种系统功能。交通大脑支撑平台应具有如下的特性：高度可扩展性，横向大规模可扩展，大规模并行处理；13智慧交通大脑一体化管理平台整体建设方案V6.0实时性，对交通数据流，事件的实时处理；高性能、低延迟分析，快速响应复杂查询和深度分析、实时分析结果；高度容错性，系统在硬件级、软件级实现容错；可用性，系统具有相当高的可用性；支持异构环境，对硬件平台一致性不高，适应能力强；开放性、易用性，系统之间可实现数据共享，服务集成；较低成本，较高的性价比。系统设计原则1）安全性原则本系统要实现基于大型数据中心、强大信息处理环境和高速网络为一体，可为交通信息管理的获取、共享和处理服务，支持实时网上数据信息处理，支持协同工作及虚拟办公环境的新一代信息基础设施支撑平台。由于整个系统涉及大量的保密数据，而且部分数据共享基于网络环境，在设计过程中，必须考虑信息安全及保密措施，确保系统中的信息资源不被非法窃取和篡改，数据中心不被破坏，同时还要保证用户能够正常使用系统中的共享资源，提供应有的信息服务。为了确保该系统的安全性，在建立健全安全管理制度基础上，还必须采用有效的安全保密技术。本14智慧交通大脑一体化管理平台整体建设方案V6.0系统采用一整套科学、便利的安全管理模式，系统对终端用户的权限严格界定，终端用户的权限细化到每一个模块的每一个功能，在此基础上系统灵活地使用组的管理方式，很大程度上简化了系统管理人员的工作复杂度。2）集成统一性、开放性和标准化原则各个不同方面的机房需求应组成一个完整的机房信息系统。并在系统安全性、资源共享、工作协同和系统管理及其开销、系统升级等方面进行规划和设计，所以系统必须具有开放性，标准化。系统的开放性是关系到系统生命周期长短重要问题，只有开放的系统才能满足互操作性、可移植性以及可伸缩性的要求，不断为系统的扩展、升级创造条件。3）先进性和实用性原则系统设计立足于高起点，采用国际先进、成熟和实用的技术，构建合理并适当超前的技术体系架构，用以确保长时间的技术领先。各系统通过集成，实现资源和信息共享。系统软、硬件配置采用模块化、开放式结构，以适应系统灵活组织、扩展和系统集成整体提升的需要。4）经济性、投资保护性原则应以较高的性能价格比建设整个系统，使资金的产出投入比达到最大值。能以较低的成本、较少的人员投入来维持系统运转，15

智慧交通大脑一体化管理平台整体建设方案V6.0提供高效能与高效益。尽可能保留并延长已有系统的投资，充分利用以往在资金与技术、设备方面的投入。系统框架大数据支撑平台框架图如下所示，主要由如下几个子系统组成：用户 ._智慧交通信息指挥中心 交通局信息指挥中心 公众 企业 管理部门应用层城市交通运行监测平台公交及特种车辆优先出行系统智能公交站台应用层城市交通运行监测平台公交及特种车辆优先出行系统智能公交站台智慧交通通用

功能平台服务总线 工作流服务 消息队列 智慧交通通用

功能平台服务总线 工作流服务 消息队列 GIS地图服务接口统一身份认证 统一鉴权 统一消息服务大数据分析平台大数据及支撑平台标准体系大数据仿真预测平台（数据挖掘'模拟仿真'分析预测大数据分析平台大数据及支撑平台标准体系大数据仿真预测平台（数据挖掘'模拟仿真'分析预测'辅助决策）数据整合管理平台 | 数据共享交换平台 数据采集与清洗平台 数据资产管理与服务平台数据库及共享平台 .一 —一 —一♦- fc- --.一一安全体系空间地理数据库 动态信息数据库 出行服务数据库 公共信息数据库 业务中间数据库 3DGIS引擎和模型OS DBMS 2DGIS引擎和模型基础环境 _云计算数据中心'硬件环境通用接入 交通物联网通用接入平台网络层3G/4G/WIFI光纤/双绞线专网（政务网、交通专网、公安专网等） 智慧交通网升级改造（其他）感知层城市道路截面采集城市高点监控网络层3G/4G/WIFI光纤/双绞线专网（政务网、交通专网、公安专网等） 智慧交通网升级改造（其他）感知层城市道路截面采集城市高点监控城市交通现状调查 浮动车电子警察 气象信息 RFID等图2.1大数据及支撑平台框架交通大脑采集子系统交通大脑采集子系统基于基础网络服务平台，采集前端感知设备传输的信息，通过统一的采集服务将数据接入到大数据支撑16智慧交通大脑一体化管理平台整体建设方案V6.0平台，进行后续的分析处理，基础网络服务平台可满足各种数据接入，同时支持大量客户端的并行处理。交通大脑资源整合存储子系统交通大脑资源整合子系统整合了整个交通相关的数据，包括前端采集的实时交通数据、路网数据、公交车数据、交警数据中心、交通运输管理数据中心和城市管理数据中心的数据通过数据交换平台也整合到该系统中。交通大脑清洗子系统交通大脑清洗子系统负责交通数据清洗和规整，剔除无用、错误和冗余的数据，保证数据的质量。大数据融合分析子系统大数据计算是整个系统的核心，基于Hadoop分布式计算以及基于Strom流式计算可满足不同的计算需求。统一消息服务子系统统一消息服务子系统为各种综合应用提供服务接口，可满足各种系统的接入查询。三维GIS平台子系统三维GIS系统是用于空间基础信息三维数据浏览显示与查询分析的应用系统，三维GIS系统为用户提供了一个三维可视化的17

智慧交通大脑一体化管理平台整体建设方案V6.0数据浏览、查询的信息平台，通过三维GIS系统可以浏览和查询平台基础信息数据库中的DEM、城市景观、遥感影像、城市绿化、城市公共设施分布等数据。系统可以导入各种常用的二维以及三维地理信息数据文件，兼容大多数开放的标准格式。系统数据流图如下:Netgear（

雷达）Netgear（视频）消息队列NetClientNetServer数据清洗前端感知设备Netgear（

车辆识

另IJ）车辆识

别车辆

信息规整后的信息oracl

eRedisRedis集群&Oracle主:oracl

eRedRedis数据规整计算oracl

eoracl

eisNetgear（

雷达）Netgear（视频）消息队列NetClientNetServer数据清洗前端感知设备Netgear（

车辆识

另IJ）车辆识

别车辆

信息规整后的信息oracl

eRedisRedis集群&Oracle主:oracl

eRedRedis数据规整计算oracl

eoracl

eisttRedisRedis统一消息服务平台图2.2大数据及支撑平台数据流1、前端感知设备采集的交通数据通过专网发送到大数据及支撑平台采集主机，采集子系统将处理后的数据一部分发给hadoop集群主机，一部分发给计算主机。2、计算主机进行数据的规整和清洗并进行一些基本的计算，包括交通运行指数、交通指标数据等的计算，计算后的结果保存18

智慧交通大脑一体化管理平台整体建设方案V6.0到oracle和redis集群中。3、Hadoop集群主机上进行大数据融合分析，包括基于大数据的OD分析，套牌车分析，尾气排放分析等。4、统一消息服务平台将数据以服务的形式提供给各个应用子系统。交通数据及支撑平台物理架构如下图：城市运行监测平台 公交信号优先系统徐州智慧交通大数据及支撑平台智慧徐州云计算中心城管数据中心图2.3大数据及支撑平台物理架构红外设备城管局前端展示 前端展示现有的前端感知设备专网城市运行监测平台 公交信号优先系统徐州智慧交通大数据及支撑平台智慧徐州云计算中心城管数据中心图2.3大数据及支撑平台物理架构红外设备城管局前端展示 前端展示现有的前端感知设备专网智慧交通大脑及支撑平台部署在智慧城市云计算中心。现有的前端感知设备采集的交通数据还是通过原有的方式将19智慧交通大脑一体化管理平台整体建设方案V6.0数据汇集到各业务部门数据中心，再通过数据共享和交换平台将数据共享到大数据及支撑平台，新增的前端采集设备直接将数据传送到大数据及支撑平台。交警、交通以及城管现有的业务数据通过数据共享和交换平台共享到大数据及支撑平台，大数据及支撑平台计算分析后的数据通过数据共享和交换平台共享给交警、交通和城管数据中心。大数据及支撑平台以服务的方式将数据提供给各个应用系统，比如城市交通运行监测平台。第3章交通大脑采集子系统前端采集技术通常根据信息的变化程度，将交通信息分为2种：静态交通信息和动态交通信息。其中，静态交通信息指短期内不会发生太大变化的交通信息，如路网信息、交通基础设施信息等；动态交通信息是指随时间变化的交通信息，如交通流信息、交通事故信息和环境状况信息等。而智能交通的信息采集主要关注的是动态交通信息中的交通流信息，如车流量、平均车速、车辆类型、车辆定位以及行程时间等。对于上述不同类型的交通信息，采集技术种类很多，动态交通信息采集可分为非自动采集和自动采集两大类。非自动采集需要人工干预才能完成交通信息的采集，需要20智慧交通大脑一体化管理平台整体建设方案V6.0大量的人力和物力，不适用于长时间的观测，而且人工采集获得的动态交通信息很难满足ITS对交通信息的实时性要求。自动采集技术完全依靠采集设备自动感知道路上车辆的存在和通过，实现对交通流信息全方位、实时的采集。下图为一些常用的动态交通采集的方式:图3.1常用的动态交通采集的方式1、采集公交车实时定位数据，数据经过处理可以提供给公交车信息以及路线查询服务使用，实时公交车数据可以提供给公交优先通行系统使用。2、雷达设备采集基本的交通指标数据，后期可用于交通运行指数的计算。3、视频设备一方面可以采集车辆的排队长度等交通信息，一方面可以实时监控道路交通状况。基于车辆识别的视频设备可以采集社会车辆的实时位置信息，这部分数据后期可以用于OD分21智慧交通大脑一体化管理平台整体建设方案V6.0析以及黑车、套牌车的分析。4、出租车通过安装车载GPS设备，采集到的出租车实时位置信息可以用来分析道路拥堵情况。5、客车以及危险品车的实时GPS定位数据可以用于两客一危系统的建设。数据共享和交换平台通过数据共享和交换平台，将交警局、交通局、城管局以及其他单位的基础数据和业务数据及时、准确、可靠的采集到大数据及支撑平台，同样，通过共享平台将大数据及支撑平台汇聚和计算到的数据共享给其他业务系统，共享平台的架构图如下：22

智慧交通大脑一体化管理平台整体建设方案V6.0交警局交通局城管局智慧交通大脑一体化管理平台整体建设方案V6.0交警局交通局城管局其他局图3.2数据共享和交换平台架构框架支撑平台基础网络服务平台neatgear（网络组件）是一个基于linux2.6+内核的网络服务框架，是一个基于网络通信与消息中间件的二次开发平台。该平台提供了基于tcp（数据传输协议）udp（用户数据报协议）的网络服务，客户端以及业务端的封装，使开发者不需要去关注网络处理细节就可以以很快的速度开发网络应用服务程序。服务端封装采用socket（套接字）非阻塞模式与epoll（改进的文件读写机23智慧交通大脑一体化管理平台整体建设方案V6.0制）多路复用结合，可以处理海量（一万以上）的慢速客户端以及一定数量的高速客户端数据，服务端可以自动处理tcp（数据传输协议）拆包，粘包的情况，可以依据一定策略自动处理超时，僵死客户端，回收系统资源，客户端封装可以依据策略进行服务器重连，数据分发。业务端规定了4种业务模式，对应着网络服务系统中常用的几种网络服务模式，分别为数据采集转发模式，问答模式，业务异步回复模式，订阅模式。3.3.2、 架构SocketG 4 另外一台服务器服务端通过网络给 数据处理模块处酗列服务端回送数据 中的数据，并写入瓢列③ 让服务端读取前置机 后置机④图3.3基础网络组件架构24智慧交通大脑一体化管理平台整体建设方案V6.0netgear（网络组件）主要由3个基础类库NetServer（服务端）、NetBusiness（业务处理）和NetClient（客户端）组成。服务端/NetServerNetServer（服务端）是基础服务端组件，封装了服务端的基本操作，采用socket（套接字）非阻塞模式以及epoll（改进的文件监控机制）多路复用模式结合，能够处理海量客户端连接，能够及时响应客户端请求，目前支持处理TCP（传输控制协议）、UDP（用户数据报协议）协议的报文请求消息。NetServer（服务端）一般可以用于两种用法，一是作为和外部客户端连接的主体，比如接收公交车车载定位设备发过来的udp（用户数据报协议）报文信息，接受公交信号优先前台展示系统发过来的请求信息，二是作为公交系统优先后台系统内部主机的通信进程，负责主机间的通信及消息的传递。NetBusinessNetBusiness（业务处理）是基础业务组件，主要封装了基本的业务处理过程，比如消息的解析以及消息的打包。NetBusiness（业务处理）可以作为NetServer（服务端）组件的一部分，也可以作为一个单独的进程使用（NetFreeBusiness）。NetBusiness（业务处理）目前支持4种业务模式，数据采集转发模式，问答模式，业务异步回复模式，订阅模式。25智慧交通大脑一体化管理平台整体建设方案V6.0数据采集转发模式：服务端接受到消息后，可转发至其他机器。问答模式：一问一答，客户端发送一条消息，服务端就回复一条消息。订阅模式：客户端发送消息，服务端根据配置可以间隔时间回复。业务异步回复模式：客户端发送消息，服务端接收消息，发送给业务处理模块，由业务处理模块来回复消息。NetClientNetClient（客户端）是基础客户端组件，封装了基本的客户端操作，基于NetClient开发的后台进程可用于主机间的通信。核心技术Epoll多路复用I/O模型I/O（输入/输出端口）多路复用技术是为了解决线程或者进程阻塞到某个I/O（输入/输出端口）系统调用而出现的技术，使进程不阻塞于某个特定的1/0（输入/输出端口）系统调用，select（），poll（），epoll（）都是I/O多路复用的机制，在linux2.6内核之前我们一般选择用select或者poll等IO（输入/输出端口）多路复用的方法来实现并发服务程序，但是在大数据、高并发的情况下，26智慧交通大脑一体化管理平台整体建设方案V6.0select\poll模型存在着很多的局限性，比如文件描述符限制等，相对于select和poll，epoll更加的灵活，没有描述符的限制，因此Netgear（网络组件）采用了Epoll模型，Epoll模型有如下的优点：监视的描述符数量不受限制，可以满足海量的连接请求I/O（输入输出）的效率不会随着监视的描述符数量增加而下降，可以在高并发的情况下满足效率的要求NetServerepoll时序图：图3.4基础网络组件类时序图服务端、客户端、业务端分离27智慧交通大脑一体化管理平台整体建设方案V6.0Netgear（网络组件）平台由NetServer（服务端）、NetBusiness（业务处理）、NetClient（客户端）3个组件组成，3个组件封装了不同的功能，可以灵活组合，满足不同的需求，如下是一些常见的组合场景。NetServer作为服务端Socket①图3.5网络组件一问一答模式这里的Server（服务端进程）是基于NetServer（服务端组件）二次开发的服务端进程，这种场景是客户端发送消息，服务端直接回复消息，对于一些业务不复杂的场景，可以采用这种模式NetServer（服务端）和NetBusiness（业务处理）结合使用服务端通过网络给 数据处理模块处理MC队列服务端回送数据 中的数据，并写入到CF队列让服务端读取图3.6netserver和netbusiness结合示意图Server（服务端）用于接收Clinet（客户端）请求，Business28智慧交通大脑一体化管理平台整体建设方案V6.0（业务）用于业务处理，这种场景一般用于业务处理相对复杂以及需要支持不同的业务模式，比如说订阅模式，这时就需要Busines（业务处理）实现这种模式。NetServer（服务端）和NetClinet（客户端）实现跨主机通信另外一台服务器图3.7跨主机通信示意图这里的Client（客户端进程）是基于NetClient（客户端组件）二次开发的客户端程序，这种场景主要用于主机间消息的传递。共享内存数据库概述MemoryCache（MC）是目前系统中使用的基于共享内存的一种数据存取仓库。MemoryCache目前支持k.v模式与k.k.v模式的数据存取。由于所有操作都是基于共享内存，实际使用中数据存取效率比一般的基于c/s服务模式的数据库要高1,2个数量级，是用于存放系统中的不易变的数据，如参数、资料，对访问者提供高速的数据访问的靠谱选择。29智慧交通大脑一体化管理平台整体建设方案V6.0设计思路MemoryCache的通道MemoryCache在创建的时候就必须选择通道的个数，MC的通道是物理上的概念，不能无限制的扩展，而且通道编号必须是从0开始的整数，通道会在内存上占用一定的内存空间，用于存放本通道所使用的内存页地址，hash队列地址，以及空闲内存地址。通道与通道之间逻辑上是完全分开的，即一个通道的数据对别的通道是完全不可见的。所有的通道共享所有的数据内存空间。通道示意图见如下图所示:基于hash的查找算法MemoryCache的数据存放于查找是基于hash算法的，利用key值通过hash算法直接映射实际物理地址，查找算法复杂度永远为O（1），不会因为数据的多少而影响了查询效率，算法弊端是无法进行不等值比较查找，数据在内存中是乱序存放，不进30

智慧交通大脑一体化管理平台整体建设方案V6.0行排序操作。出现hash冲突的时候会进行顺序查找，在冲突比较频繁的状态下会影响存放以及查询效率。HashArray IndexNode HashConflict图3.9数据组织示意图31智慧交通大脑一体化管理平台整体建设方案V6.0数据存入解析数据判断key

对应的hash位置申请索引节点了成功失败申请数据空间失败•二Hash位置上是

否已有节点无查找是否有相有修改hash数组上对

应位置的地址为新

申请的索引位定位到链表最后一

个索引节点，并修

改链表指针为新申

请的索引节点程序报错释放资源

返回拷贝数据，建立索引节点与数据节点的指针关系结束图3.10数据存放流程图32智慧交通大脑一体化管理平台整体建设方案V6.0图3.11数据查找流程图33智慧交通大脑一体化管理平台整体建设方案V6.0图3.12数据删除流程图通道内存管理对于通道的内存一般分为以下几个种类，最大的一块为hash表，存放着本通道的hash索引位，另外就是本通道的索引页链表与数据页链表以及空闲索引页链表，空闲数据页链表。其中空闲链表是正常链表的子集，存在的目的只是为了在申请空闲空间的时候能更有效率。34

智慧交通大脑一体化管理平台整体建设方案V6.0LockLockPidAddressHashArray图3.13索引节点的数据结构图数据内存管理内存页面的概念系统中出了通道占用内存，其余的内存均作为数据内存管理，由于数据内存可以非常大，为了管理方便，实际使用时系统会将其切成一块块的小内存块加以管理。这种小内存块这边暂且成为内存页面。目前系统中使用的内存页面大小为1M。35智慧交通大脑一体化管理平台整体建设方案V6.0系统级内存页链表在整个共享内存块中存在一个各个通道均可见的内存页链表，用于各个通道来申请内存页。（目前内存页申请过后直接存入各个通道的内存页链表中，即使页面完全闲置也不会归还给系统内存链表，主要为效率考虑，实际应用中需要归还内存页的情况比较少）内存页的申请与释放在系统有新的页面申请请求（包括索引页面和数据页面）的时候，进程会锁定系统的空闲页链表，以防止多个进程同时申请造成标记混乱。然后将系统空闲页链表的首页面地址获取后挂接到自身的页面链表上，同时将系统链表的首指针下移。释放的时候，锁定系统链表后，将释放的页面挂接到系统链表的表尾，同时表尾指针下移。包含有空闲数据空间的内存页组织在每个通道内都有两个页面链表，分别是存放本通道索引节点的索引页面链表，存放本通道数据的数据页面链表。同时为了分配算法的高效，确保查找空闲索引或者数据块的高命中率，在每个通道内还维持另外两个页面链表，空闲索引页面链表，空闲数据页面链表。加入空闲链表的规则是页面内有空闲数据空间即加入，一旦数据空间被申请完，则当前内存页从空闲链表中剔除，36智慧交通大脑一体化管理平台整体建设方案V6.0如果不在空闲页链表中的内存也有空间被释放，则重新加入空闲链表。空闲页面链表为当前通道的页面链表的子集。索引节点的申请与释放索引数据都是定长数据，在内存页初始化之初先根据索引大小初始化一个个的索引节点，并且由链表将所有的节点串联起来，页头记录链表的首节点与尾节点。如需申请索引节点，则从链表头中取出一个，并且头记录下移，如果链表头为空，则表明当前页没有空闲节点，需要向系统申请新的空闲页。归还的时候，则是将所属页面的尾记录节点指向归还节点，同时修改尾记录节点指针至新归还节点。可变内存的申请与释放数据存放与删除的核心就是可变内存申请与释放。首先，内存的申请是一内存页为单位的，所有的内存操作都必须在内存页内进行。内存页内维护一个页面内的空闲内存链表，对于一个新内存页来说，内存链表就一个节点，即为除了页头之外的所有空间。如果有请求申请内存，则由系统判断所需要申请的内存大小，然后将申请的大小与现存系统空闲大小进行比较，如果可以分配，则进入分配流程，如果不可以分配，则按照次序寻找下一个可分配的空闲页，如果所有空闲页都无法分配，则向系统申请新的空闲页。37智慧交通大脑一体化管理平台整体建设方案V6.0如果当前的空闲节点大小超过了需申请的大小，为了节省内存空间，需要将当前空闲节点做切割处理，除了分出去的拿部分内存外，剩余的内存依然作为节点等待下一次分配。切割后的内存需要归还的时候，原则上先将自己挂接到虚拟节点的链表尾端，等待下次分配。由于数据块在分配中会被不断切割，会导致数据块不断的由大变小，为了防止内存碎片的过多产生，需要对产生的内存碎片做合并。内存合并算法在内存被归还后执行，主要思路是查看当前内存块与前后内存块的关系。归还后，如果当前内存块的后一块内存为空闲内存，则表明可以与后内存合并，直接将当前内存的空间扩充至当前内存空间与后置内存空间的综合即可，同时将后置内存块从链表中删除，并将当前内存块加入即可。继续判断前置内存块是否为空，如前置内存块为空，则可以直接将前置内存块的空间扩充至当前内存块即可。判断后置内存块位置的方法可以直接根据当前内存块的起始位置加上当前内存块的长度即可得到下个内存块的起始位置。这种方法不能判断前置内存块起始位置，所以在进行数据结构设计的时候，在内存块的最后保留4字节记录当前数据块的起始位置，根据这个结构可以在数据块的起始位置.4就可以得到前置数据块的位置信息。然后根据前置数据块的位置信息可以直接定位前置数据块的位置并查询前置数据块被占用的情况，从而做出内存合并的操作。38智慧交通大脑一体化管理平台整体建设方案V6.0由于内存在分配的过程中不断的被分配切割，虽然有合并内存操作，对于某些特定场合，切割开的剩余内存如果太小的话会一直滞留在系统中不满足任何分配条件，但系统还需要花资源去维护这部分的碎片内存，造成分配效率的低下，在本系统中，为了解决这个问题，在切割内存后，如果被剩下的待分配内存小于系统设定的最小内存分配大小，那么整个内存将不做内存切割，而是整块分配。这样对于申请内存的函数，一样可以满足使用要求，对于剩余内存的维护，则大幅度降低了碎片内存的产生，提升了整体内存分配效率。二级key的算法实现memorycache除了支持key.value模存储之夕卜，还支持key.key.value的存储模式，可以根据第一级key的值进行全部数据的查询与删除。二级key数据存储的时候跟一级key主要的区别在索引构建上，除了正常的keyl,key2的索引构建，在hash队列上专门开辟一空间专门存放基于keyl的索引节点，两个索引节点会指向同一块数据空间。重复的keyl索引节点会从samenext指针往下连接，冲突的keyl指针会从next指针往后连接，从而形成一个类似二叉树的索引树结构。在这种索引树的支持下，可以达到直接根据key1的值查询所有key1值得记录，也可以直接删除所有基于key1的值得记录。基本可以支持表名.索引.数据三级数据存放，也可以更好的支持原来基于关系型数据39智慧交通大脑一体化管理平台整体建设方案V6.0库的数据模型的数据查询。并发访问控制对于数据的并发访问，比如说一个进程在进行插入删除操作的时候另一个进程在进行查询操作。由于共享内存本身对数据并发访问没有任何控制，所以就需要memorycache本身提供机制将可能引起冲突的操作在时间上隔开。首选方案即在hash队列上增加一个锁位，每个在此节点上操作数据的操作都必须先获得锁才能进行下一步动作，这样做的效果是最好的，但因为hash队列本身非常大（百万级），每个节点上增加锁位跟pid位会造成非常大的空间浪费，因为行锁冲突的可能性并不大，为了解决这种可能性不大的冲突浪费大量的空间，最终的解决方案为在hash队列上开辟一块空间，叫锁区，每个hash节点通过专用的hash算法可以映射到锁区上的一个位置，锁住这个位置后就可以对hash节点进行操作，这样同样可以达到效果。只是对于不同的hash节点，可能映射到同样的锁区位置，这样就增加了潜在冲突的可能性，但由于发生冲突本身的可能性非常低，即使增加了冲突概率，发生冲突的代价还是在可接受范围之内，同时大幅度降低了行锁的内存使用量。消息组件IpcBase是目前系统中用于传递进程间消息的消息中间件。模40智慧交通大脑一体化管理平台整体建设方案V6.0块构建在共享内存上，以定长消息环队列数据结构封装，以系统原子锁操作来间隔生产者与消费者的同步关系。对外提供统一的，并发安全的进程级的FIFO（先进先出）队列操作。队列内部结构块数每块记录数记录大小块0块1头数据0数据1数据图3.14队列内部结构图队列头记录，队列块数，每块记录数大小，所有块分布。每块队列内部包含：pid（进程id），队列状态（有无数据），锁标记，队列数据。当队列状态为0（无数据），无需加解锁;当队列状态为1（有数据），通过进程标记位来实现锁机制。队列与模块关系图队列分为两种，系统中分别称为MC队列与CF队列。通常41

智慧交通大脑一体化管理平台整体建设方案V6.0MC队列用于连接数据采集与数据处理模块，CF队列用于连接数据处理与消息输出模块。队列与模块示意图如下：业务采集模块

（采集数据并存放到

相应的MC队列通道中）MC队列读取配置文件中该进程对应的读写通读取配置文件中该进程对应的读写通

道号配置文件（存放每个进程的

读写通道号）消息输出模块

（输出业务采集模块

（采集数据并存放到

相应的MC队列通道中）MC队列读取配置文件中该进程对应的读写通读取配置文件中该进程对应的读写通

道号配置文件（存放每个进程的

读写通道号）消息输出模块

（输出CF队列中的消息）读取配置文件中该进程对应的读写通道号图3.15队列与模块关系图MC与CF队列可分为多个物理通道，每个通道对应一定数量的一个fifo（先进先出）队列。每个进程都可以根据配置来占用一个或多个通道进行读写。设计逻辑主要设计逻辑：1、采用轻量级原子锁，每个全双工通道配2个锁位，正向跟反向各一个。2、通过访问队列状态标记位减少加解锁次数。当队列状态为42智慧交通大脑一体化管理平台整体建设方案V6.00,表明当前队列无数据，无需访问，无需加解锁;当队列状态为1（有数据）时，通过第三点的进程号记录位实现访问机制；3、通过加解锁的进程号记录位来实现锁机制，进程加解锁的时候自己填入，方便及时排查锁故障以及自解锁的判断。1）进程对操作的通道先加锁；2）如果加锁失败操作超过配置设定的时间，则检查通道队列头锁标识的PID对应进程是否存在；3）不存在则将队列上锁标记清除，供当前进程加锁处理。4）若一直加锁失败，并且通道队列锁标识的PID对应进程存在，则证明锁机制出了问题，需要排查其他故障。4、采用哈希散列算法，ipc通道与进程通道的一对多映射，通过提供全局配置来实现；5、可实现一次性读取或放入多个消息的方法，对比每次读写单个消息的场景，大幅度降低读写消息锁需要的加解锁次数，降低加解锁碰到冲突的概率。6、请求与回复通道个数可以不对等，可以自由根据消息数量以及进程的消息处理速度自由配置进程所占有的捅到个数，以求平衡系统内的进程处理数据，消除系统内的处理瓶颈。43智慧交通大脑一体化管理平台整体建设方案V6.0日志管理levellog模块为系统提供的静态库函数，系统可根据需要记录运行过程及遇到的各种问题。根据日志内容，可以查询系统的处理流程，有利于系统维护，排除故障。可以针对某一模块设置特定的日志控制（控制日志不输出，全输出，按方式输出），方便统一查询系统日志。根据日志配置信息查找相关记录，以此决定是从配置文件读取日志输出路径和日志配置图根据日志配置信息查找相关记录，以此决定是从配置文件读取日志输出路径和日志配置图3.16日志管理与模块关系.各模块的日志级别:采集处理模块：log_type=30公交位置计算：log_type=4044智慧交通大脑一体化管理平台整体建设方案V6.0信号优先： log_type=50行驶模拟： log_type=60.日志类别代表含义：Level_log=0不写日志Level_log=1写日志Level_log=3按特定方式输出系统预警及系统告警与状态管理系统告警与状态模块是集成在框架中的，每个进程运行的过程中都可以向框架提交告警，每个提交的告警都会被框架提交到一个系统级的消息队列中，由专门的搜集程序将系统告警读出并落地成文件，然后提交到数据库保存，提供查询。每个进程在运行中也可以调用接口填写自身的状态，所有的进程状态会被保存到一块本地的共享内存中，由专门的进程负责维护，将状态读出并通过udp（用户数据报协议）提交给远端的状态搜集进程，此进程搜集全部业务进程的运行状态并展示。以便运维人员查看。45

智慧交通大脑一体化管理平台整体建设方案V6.0信号优先模块/SignalControl位置测算模块/RegionTriggei告警写入

/WriteWarning向共享内存写告警消息图3.17告警与模块关系消息队列从数据库读消息用于展示告警信息和状态信息位置测算模块/RegionTriggei告警写入

/WriteWarning向共享内存写告警消息图3.17告警与模块关系消息队列从数据库读消息用于展示告警信息和状态信息把共享内存中的消息通过网络发送给Webserver一致性哈希分发哈希算法将任意长度的二进制值映射为较短的固定长度的二进制值，这个小的二进制值称为哈希值。哈希值是一段数据唯一且极其紧凑的数值表示形式。公交信号优先是基于分布式部署的系统，当使用普通的哈希散列算法，将公交数据从前置机分发到后置机时，如果其中一台后置机宕机，或者由于业务增加需要，扩充一台后置机时，如果不做哈希改变，原先分发至宕机机器的数据无法再分发，公交数据也无法分到到新增的机器；如果重新设置哈希，所有的值将重新映射，原先所有的缓存全部失效。需要引入一致性哈希来解决46智慧交通大脑一体化管理平台整体建设方案V6.0这些问题。一致性哈希基本场景分布式集群中，如果有N台cache服务器(后面简称cache),采用通用方法将一个对象object映射到N个cache上，公式：hash(object)%N如果出现以下两种情况：.一个cache服务器mdown宕机，如果映射公式不做更改，所有映射到cachem的对象都会失效；如果把cachem从cache中移除，这时cache是N.1台，修改映射公式为hash(object)%(N.1)，那之前所有的数据也全部失效。.由于访问加重，需要添加cache，这时候cache是N+1台，如果映射公式不做改变，仍然为hash(object)%(N)，数据对象无法分发到新增的cache。如果映射公式变成了hash(object)%(N+1)，映射公式的改变，代表之前的所有数据都失效，重新映射。以上两种情况，都会造成大量数据失效，需要一致性哈希来解决。一致性哈希算法47智慧交通大脑一体化管理平台整体建设方案V6.0consistenthashing/一致性哈希是一种hash/哈希算法，提出了在动态变化的Cache环境中，判定哈希算法好坏的四个定义：1、平衡性(Balance)：平衡性是指哈希的结果能够尽可能分布到所有的缓冲中去，这样可以使得所有的缓冲空间都得到利用。很多哈希算法都能够满足这一条件。2、单调性(Monotonicity):单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中，又有新的缓冲加入到系统中。哈希的结果应能够保证原有已分配的内容可以被映射到原有的或者新的缓冲中去，而不会被映射到旧的缓冲集合中的其他缓冲区。3、分散性(Spread)：在分布式环境中，终端有可能看不到所有的缓冲，而是只能看到其中的一部分。当终端希望通过哈希过程将内容映射到缓冲上时，由于不同终端所见的缓冲范围有可能不同，从而导致哈希的结果不一致，最终的结果是相同的内容被不同的终端映射到不同的缓冲区中。这种情况显然是应该避免的，因为它导致相同内容被存储到不同缓冲中去，降低了系统存储的效率。分散性的定义就是上述情况发生的严重程度。好的哈希算法应能够尽量避免不一致的情况发生，也就是尽量降低分散性。4、负载(Load)：负载问题实际上是从另一个角度看待分散性问题。既然不同的终端可能将相同的内容映射到不同的缓冲区中，48智慧交通大脑一体化管理平台整体建设方案V6.0那么对于一个特定的缓冲区而言，也可能被不同的用户映射为不同的内容。与分散性一样，这种情况也是应当避免的，因此好的哈希算法应能够尽量降低缓冲的负荷。在分布式集群中，对机器的添加删除，或者机器故障后自动脱离集群这些操作是分布式集群管理最基本的功能。如果采用常用的hash（object）%N算法，那么在有机器添加或者删除后，很多原有的数据就无法找到了，这样严重的违反了单调性原则。以下介绍一致性哈希如何设计。环形hash空间通常的hash算法都是将value映射到一个32为的key值，也即是0〜2八32.1次方的数值空间，可看作首（0）尾（2-32.1）相接的圆环，如下图所示。0图3.18环形hash空间把数据对象映射到hash空间接下来考虑4个对象objectl〜object4，通过hash函数计算出的hash值key在环上的分布如下图所示。49智慧交通大脑一体化管理平台整体建设方案V6.0hash(objectl)=keyl;hash(object2)=key2；hash(object3)=key3;hash(object4)=key4;02A32-1object2图3.19对象映射分布把机器映射到hash空间一致性哈希算法的分布式集群中将新的机器加入，其原理是通过使用与对象存储一样的Hash算法将机器也映射到环中（一般情况下对机器的hash计算是采用机器的IP或者机器唯一的别名作为输入值），然后以顺时针的方向计算，将所有对象存储到离自己最近的机器中。50智慧交通大脑一体化管理平台整体建设方案V6.0假设现在有CacheA,CacheB,CacheC三台机器，通过Hash算法得到对应的KEY值，映射到环中，其示意图如下：Hash(CacheA)=KEYA;Hash(CacheB)=KEYB;Hash(CacheC)=KEYC;02A32-1object2图3.20cache和对象的key值分布通过图中可以看出对象与机器处于同一哈希空间中，这样按顺时针转动objectl存储到了CacheA中，object2,object3存储到51智慧交通大脑一体化管理平台整体建设方案V6.0了CacheC中，object4存储到了CacheB中。在这样的部署环境中，hash环是不会变更的，因此，通过算出对象的hash值就能快速的定位到对应的机器，找到对象真正的存储位置。cache的添加与删除普通hash求余算法最为不妥的地方就是在有机器的添加或者删除之后会照成大量的对象存储位置失效，这样就大大的不满足单调性了。以下介绍一致性哈希算法的处理方式。移除cache以下图分布为例，如果CacheB出现故障被删除，按照顺时针迁移的方法，object4将会被迁移到CacaheC中，这样仅仅是object4的映射位置发生了变化，其它的对象没有任何的改动。52

智慧交通大脑一体化管理平台整体建设方案V6.002A32-1object2图3.21cacheB被移除后的cache映射添加cache如果往集群中添加一个新的节点CacheD,通过对应的哈希算法得到KEYD，并映射到环中，如下图:53

智慧交通大脑一体化管理平台整体建设方案V6.00CacheDobject2图3.22添加cacheD后的映射关系通过按顺时针迁移的规则，那么object2被迁移到了CacheD中，其它对象还保持这原有的存储位置。通过对节点的添加和删除的分析，一致性哈希算法在保持了单调性的同时，还是数据的迁移达到了最小，这样的算法对分布式集群来说是非常合适的，避免了大量数据迁移，减小服务器的压力。虚拟节点根据上面的图解分析，一致性哈希算法满足了单调性和负载均衡的特性以及一般hash算法的分散性，但这还并不能当做其被广泛应用的原由，因为还缺少了平衡性。下面将分析一致性哈54智慧交通大脑一体化管理平台整体建设方案V6.0希算法是如何满足平衡性的。hash算法是不保证平衡的，如上面只部署了CacheA和CacheC的情况见图4.2.8.3.5.1.1（CacheB失效的情况），objectl存储到了CacheA中，而object2、object3、object4都存储到了CacheC中，CacheC存储量远大于CacheA的存储量，分布不均衡，在一致性哈希算法中，为了尽可能的满足平衡性，其引入了虚拟节点。“虚拟节点”（virtualnode）是实际节点在hash空间的复制品（replica），一实际个节点对应了若干个“虚拟节点”，这个对应个数也成为“复制个数”，“虚拟节点”在hash空间中以hash值排列。仍以仅部署cacheA和cacheC的情况为例，对象在cache的分布很不均衡。现在我们引入虚拟节点，并设置'复制个数”为2，这就意味着一共会存在4个“虚拟节点"，cacheA1,cacheA2代表了cacheA；cacheC1,cacheC2代表了cacheC。55智慧交通大脑一体化管理平台整体建设方案V6.002A32-1CacheA1object2图3.23引入“虚拟节点”后的映射关系对象到“虚拟节点”的映射关系为：objec1.>cacheA2；objec2.>cacheA1；objec3.>cacheC1；objec4.>cacheC2；因此对象objectl和object2都被映射到了cacheA上，而objects和object4映射到了cacheC上，平衡性有了很大提高。引入“虚拟节点”后，映射关系就从｛对象.>节点｝转换到56智慧交通大脑一体化管理平台整体建设方案V6.0了｛对象.＞虚拟节点｝。查询物体所在cache时的映射关系如图所示。图3.24对象到虚拟节点的映射关系“虚拟节点”的hash计算可以采用对应节点的IP地址加数字后缀的方式。例如假设cacheA的IP地址为202.168.14.241。引入“虚拟节点”前，计算cacheA的hash值：Hash(“202.168.14.241”)；引入“虚拟节点”后，计算“虚拟节”点cacheA1和cacheA2的hash值：Hash(“202.168.14.241#1”)；//cacheA1Hash(“202.168.14.241#2”)；//cacheA2虚拟节点数量越多，分布越均匀，平衡性越满足。总结57智慧交通大脑一体化管理平台整体建设方案V6.0一致性hash算法通过减少影响范围的方式解决了增减服务器导致的数据散列问题，从而解决了分布式环境下负载均衡问题，如果存在热点数据，那么通过增添节点的方式，对热点区间进行划分，将压力分配至其他服务器，重新达到负载均衡的状态。第4章大数据资源整合存储子系统通过前端采集过来的数据经过格式转换后存储到数据库中，一般采用两种方式存储数据，对于基本的交通数据如路网数据、交通指标数据统一的存储到oracle数据库中，对于基于车辆识别的车辆数据因为数据量比较大，统一存储到HDFS文件系统中，便于后续基于大数据的分析计算。图4.1采集服务示意图基础交通数据58智慧交通大脑一体化管理平台整体建设方案V6.0基础交通数据为整个交通运行的静态数据部分，所谓静态数据指的是一旦确定轻易不会做出变动，是确保交通大脑平台稳定，精确运行的基础。随着日新月异的城市发展，以及城镇化脚步的较快，基础交通数据变动也变动日益频繁，对基础交通数据的及时更新维