目前我国车联网行业处于与 5G 技术的深度融合时期，随着 5G 与 V2X 技术的发展成熟以及整个汽车出行领域新四化的推进，各个汽车制造厂商正逐步构建以智能驾驶和智能网联为核心的车联网系统。新一代的车联网系统对于底层消息采集、传输和处理的平台架构提出了更高的要求。
本文将结合行业实践经验，从协议选择等理论知识，到平台架构设计等实战操作，与大家分享如何搭建一个可靠、高效、符合行业场景需求的车联网平台。主要内容有：
1、车联网场景通信协议选择
2、千万级车联网消息平台架构设计
3、车联网 TSP 平台 MQTT 消息主题设计
4、车联网 MQTT 消息 QoS 等级设计
车联网场景通信协议选择
MQTT 协议早已是物联网领域当之无愧的主流协议，其凭借轻巧高效、可靠安全、双向通讯等特性在诸多行业物联网平台搭建中得到了广泛的应用。
那么 MQTT 协议在车联网场景中的应用情况如何呢？
MQTT 协议适合车联网吗？
整个车联网业务架构复杂，涉及多个通信环节，在本文中我们讨论的是车联网平台主要负责的云-端消息接入模块。
MQTT 是基于发布/订阅模式的物联网通信协议，具有简单易实现、支持 QoS、报文小等特点，占据了物联网协议的半壁江山。
在车联网场景中，MQTT 依然能够胜任海量车机系统灵活、快速、安全接入，并保证复杂网络环境下消息实时性、可靠性， 其主要应用优势如下：
开放消息协议，简单易实现。市场上有大量成熟的软件库与硬件模组，可以有效降低车机接入难度和使用成本；
提供灵活的发布订阅和主题设计，能够通过海量的 Topic 进行消息通信，应对各类车联网业务；
Payload 格式灵活，报文结构紧凑，可以灵活承载各类业务数据并有效减少车机网络流量；
提供三个可选的 QoS 等级，能够适应车机设备不同的网络环境；
提供在线状态感知与会话保持能力，方便管理车机在线状态并进行离线消息保留。
综上，如果配以具备海量车端连接、软实时、高并发数据吞吐以及多重安全保障能力的消息中间件产品，MQTT 协议无疑是将为车联网平台的搭建带来便利。
相比 MQTT，其它协议差在哪里？
目前为止大多数车联网客户首选的都是 MQTT 协议，我们也遇到过一些客户曾选择其他诸如私有 TCP、HTTP 协议，但从最终结果来看，MQTT 都是车联网场景下的最佳选择。
下面将通过几个真实的客户案例来说明为什么 MQTT 协议更适合车联网场景：
在没有接触过 MQTT 协议之前，华南某大型主机厂采用了私有化的 TCP 协议（ACP 协议）构建车联网服务平台。经过长周期的协议规范设计和开发，基本实现了车联网平台的主要功能。
但随着车联网业务场景的不断增加和车机数量的不断增长，私有化的 TCP 的弊端逐渐凸显：协议私有化定义与版本维护困难、所有的协议功能（如保活、断线重连、离线消息等）都需要定制开发，私有的协议也导致终端硬件适配都需要定制开发，成本高、周期长，更新迭代慢等问题突出。
随着 MQTT 协议生态不断完善和在车联网平台通讯协议选型中被广泛采用，该主机厂在新一代车联网平台的开发中选择采用 MQTT 协议。
华东某大型主机厂现有一百多万的存量车机，之前的车联网平台采用私有的 TCP 协议构建，面对百万车机海量的消息通信，私有化的 TCP 协议维护成本高，消息可靠性无保障，日常系统维护和功能扩展开发工作量大。
随着 MQTT 协议在集团内部车联网平台广泛采纳，该主机厂也开始启动 MQTT 协议的改造升级工作，目前针对部分车型已经通过 OTA 升级的方式完成了升级，未来他们计划分阶段逐步完成所有车型的升级改造工作。
还有一个车企客户早期与我们接触过，但考虑到初期业务比较简单以及自身技术选型问题，最终使用了自建 HTTP 服务的形式接入车机。
随着业务发展，传统的请求-响应模式通信已经无法满足新增业务需求，同时随着功能与终端数量增多，整个平台通信量成倍增加，使用 HTTP 接入出现了性能瓶颈。该客户最终还是选择了 MQTT 作为接入协议。
总体来看，私有协议具有封闭性、排他性等特点，在制定初期是为了解决特定的问题而设计导致缺乏灵活性，往往在业务调整之后难以满足新的需求，企业不得不在协议中加入更多的特性；又或者因为接入量的增多，私有协议 Server 端过早达到了性能和扩展性的瓶颈。
以上种种原因最终导致用户工作的重心从业务开发转移到接入层、中间件的开发，无形中增加了平台项目成本。因此 MQTT 协议顺理成章地成为最适合车联网领域的主流协议。
千万级车联网消息平台建设
在车联网建设高速发展的今天，所有的主机厂业已形成了一个共识: 车联网建设的目的不是为了联网而联网，也不是为了车载娱乐而联网，联网是为了数据。有了车联网，就有了数据。有了数据，辅以完整的数据治理和应用体系，就有了一切。
而这个业务的目标数据，也不仅仅限于车端的相关数据。在 V2X 框架中，需要解决车与车（V2V）、车与路（V2R）、车与网（V2I）、车与云（V2C）、车与人（V2H）等的互联互通，实现针对车、路、云、网、人的全面数据采集和分析。基于 5G 的 C-V2X 协议和通讯方式，为整个系统的建设提供基础能力保障。
从传统的 OTA 应用到智能座舱、高精地图适配、厘米级定位、车机端长连接、手机端消息采集、车路云图、车路协同等众多新型智能应用场景，车联网业务对于消息平台和数据处理系统的需求已从原始的车云扩展为人-车-路-网-云的整体架构建设，也因此对整个消息平台的建设提出了更高的要求。
如何建设一个海量连接、高并发吞吐、低时延的消息通信和传输系统架构，来保证整个系统的泛在性、便利性、高可用性、可靠性、安全性和高并发性，就成为了基于自动驾驶和车路协同场景下新一代车联网系统建设的关键所在。
业务挑战
■ 车机、路测单元和手机端系统安全接入
车端需要涵盖车机数据上报、POI 下发、推送文件、下发配置、推送消息、运营关怀等全新车联业务，产生的海量消息 Topic 需要更加安全稳定的接入与传输实现消息订阅和发布。路端需要实现路侧 RSU 的安全接入，消息采集和传输、地图数据的传输等。
■ 大并发消息传递的实时性和可靠性
高精地图、厘米级定位、车路协同等应用场景均需要解决海量车路图消息的毫秒级低延时和高可靠的传输能力保障，需要消息处理平台具备高性能、低延时、高可靠支持千万连接和百万并发业务场景的能力。
■ 丰富的应用场景集成
在以自动驾驶为核心的车联网系统中，需要使用消息平台对接各种基于人、路、图、云相关的应用对接。将车端数据通过消息平台同高精地图、厘米级定位、车路协同、手机端连接等应用场景进行连接，通过消息平台保障应用的消费供给，并提供高性能、低延时和高可靠的数据架构。
■ 海量数据存储、处理和分发
来自于人、车、路、云、图、网的海量物联网数据被采集后，需要针对这些大规模实时数据流的接入、存储、处理、分发等环节进行全生命周期管理，为应用提供针对动态连续数据流的数据库支撑，支持应用深度使用车联网数据服务于消费者，进行商业决策。
整体解决方案
我们将以 EMQ 的车联网消息平台和数据处理整体解决方案为例，介绍如何构建一个千万级的车联网消息平台。在方案中我们主要采用 EMQ 旗下的云原生分布式物联网接入平台 EMQX，来实现车联网系统中车端和人、路端的数据连接、移动和处理。
EMQX 一体化的分布式 MQTT 消息服务和强大的 IoT 规则引擎，可为高可靠、高性能的物联网实时数据移动、处理和集成提供基础能力底座，助力企业快速构建关键业务的 IoT 平台与应用。
■ 针对车端的消息处理
EMQX 采用 MQTT 协议接入车联系统。车机端通过负载均衡与 EMQX 分布式集群进行连接，EMQX 的横向扩展能力可实现千万级车机连接和百万并发响应的数据通信能力。通过规则引擎，可一站式实现海量消息桥接消息队列、持久化入库、离线消息存储等能力，同时提供丰富的 API 原子能力北向集成。
在安全方面，EMQX 不仅支持 TLS/DTLS 或国密 GMSSL 安全协议，保障系统可靠与稳定；还提供心跳监测、遗嘱消息、QoS 等级等多重保障机制，通过离线消息存储实现在复杂的网络环境下实时、安全、可靠的车机消息通信。
■ 针对人、路端的消息处理
EMQX 为人、路端提供针对手机 APP、RSU 等终端的消息采集和处理平台。基于 5G 网络切片能力，通过个人终端和路侧单元的就近接入，实现超低时延的交通信息服务。通过 MQTT 等协议将人端、路侧设施感知到的路况信息推送到云控平台，通过云控平台融合 V2X 算法实现道路协同感知知、安全提醒、远程协同控制等智能交通场景。
在安全方面，支持国际标准的 TLS/DTLS 加密或国密算法 GMSSL 加密，通过扩展基于 PKI/CA 证书认证体系保障人车路信息系协同的安全通信。
参考架构
■ 千万消息接入框架模型
针对新一代车联网场景，EMQ 千万级连接规模和百万级并发的整体消息接入和数据处理平台参考架构如下：
业务场景：车联网体系中的车辆、手机APP 端、路侧 RSU 等设备等通过 MQTT 接入，实现对千万量级的以上终端的并发接入能力。
系统架构：终端设备通过 MQTT、HTTP 等协议接入，经过负载均衡组件连接至分布式消息平台 EMQX。通过分布式多集群部署满足千万并发连接需求，按照百万级消息吞吐能力，通过规则引擎对接 Kafka 集群实现数据的转发。车联网服务平台、高精地图服务、V2X 云控服务、定位服务和其他车辆网相关应用可以直接通过订阅 Kafka 数据进行消费，同时 EMQ 提供了 REST、MQTT 和 MQ 消息队列三种南向接口服务实现对车控（远程控制）消息的双向通信。
以上参考框架可实现车联网场景下的千万连接、百万并发吞吐的业务需求。下面我们将对其连接能力进行进一步测试。
千万级消息接入测试
某车企计划在车联网场景下，基于测试环境验证 EMQX 集群的以下能力，为后续业务增长做相应的技术架构和能力支撑准备：
可支撑 1000 万并发连接，同时支持每秒 10 万～15 万、payload 为 100 字节的 QoS 0 消息通过规则引擎桥接到 Kafka；
1000 万并发连接订阅、消费 OTA 广播主题；
300 万用户同时连接不会造成集群雪崩，并测试连接所需时间。
另外，在完成上述所有测试后，继续探索在目前配置下 1000 万并发的同时可支持的最高消息发送并桥接转发至 Kafka 的吞吐量(根据 EMQX 集群资源使用情况提高客户端消息发送频率)，以及测试在 1000 万连接下满足 QoS 为 2 且平均响应时间在 50 毫秒内的最高消息吞吐。
压力测试工具简介和使用
本次测试由于所需测试机数量多，管理复杂，故使用 EMQ 旗下商业版测试软件 XMeter 性能测试平台和 JMeter-MQTT 插件进行。
XMeter 是基于开源测试工具JMeter 扩展的性能测试平台。针对物联网具有的接入规模大、弹性扩展要求、多种接入协议、混合场景等特点，XMeter 对 JMeter 进行了改造，可以支持大规模、高并发的性能测试，比如实现千万级别的 MQTT 并发连接和消息吞吐测试。除了测试 MQTT 协议之外，还可以支持 HTTP/HTTPS 等主流的应用的测试。
JMeter-MQTT 插件是由 XMeter 实现的开源 MQTT 性能测试插件，在众多的项目中得到了使用，目前是 JMeter 社区中流行度最高的 MQTT 插件。
XMeter 官网和试用地址: https://www.xmeter.net
XMeter MQTT 插件下载: https://github.com/xmeter-net/mqtt-jmeter
JMeter 下载地址: https://jmeter.apache.org
测试架构
客户端通过 TLS 加密连接负载均衡 ELB，然后在 HAProxy 对客户端进行 TLS 终结，最后通过 TCP 连接至 EMQX 集群。
通过在 HAProxy 上终结 TLS 的方式可以提高 EMQ X 集群的支持能力，在这种部署模式下 EMQX 的处理能力和客户端直接通过 MQTT TCP 连接是完全一致的。
另一方面，相比 MQTT TCP 连接，客户端通过 TLS 连接也需要消耗更多的资源，而本次测试规模为千万级，所需的测试机数量众多，为了减少所需测试资源的同时不影响对 EMQX 集群的测试目标，本次测试将直接使用 TCP 连接。
测试场景如下：
以下是本次测试的结果呈现：
如以上结果所示，在目前的部署架构下，可以满足该车企对于千万并发连接 +20 万消息桥接至 Kafka、消息广播及 300 万瞬时并发连接的验证需求。
在探索测试中，1000 万连接下测试到最高 120 万消息 TPS(QoS 0、payload 1kB)，测试持续 10 小时 EMQ X 集群稳定，CPU idle 最低至 20%，内存使用平稳。
车联网 TSP 平台 MQTT 消息主题设计
在车联网生态中，TSP（Telematics Service Provider）平台在产业链中居于核心地位，上接汽车、车载设备制造商与网络运营商，下接内容提供商，是主机厂车辆与服务的核心数据连接平台。随着智能汽车的发展和车主用户对应用场景需求的不断提升，主机厂对 TSP 平台的设备与应用承载能力需求将不断增加。
车联网 TSP 场景中，MQTT 协议作为「车-平台-应用」之间的业务消息通道，不仅要保证车与应用之间消息可以双向互通互联，而且需要通过一定规则将不同类型的消息识别与分发。而 MQTT 协议中的主题就是这些消息的标签，也可以看作是业务通道。
在车联网场景中，可以把消息分为从车-平台-应用的数据上行通道以及应用-平台-车的数据下行通道；对于车联网 TSP 平台，不同数据方向意味着不同的业务类型，需要通过 MQTT 主题进行明确的区分与隔离。
从车端角度看：
在 TSP 平台中车辆数据上报是上行数据的主要业务类型。随着车联网业务的不断丰富，如 T-box 等车载系统计算能力与通讯能力不断增强，车辆数据上报的业务场景、数据量及频率也不断增加。
基于业务隔离、实时性与安全等需求，从车联网早期的一车一主题逐渐向一车多消息通道发展。
从应用侧角度看：
平台应用作为车辆数据接收与消费方，同时也会作为数据下发，指令下发的消息发送方。根据业务需求不同，消息发送类型也可以分为：
一对一消息：针对一些如车控?关键业务与高安全性要求的业务，需要针对每辆车提供一对一的消息通道。
一对多消息：对于某一类业务或者某一种车型，可以通过相同主题通道向车机设备进行指令与数据下发。
消息广播：针对大规模的消息通知，配置更新场景，可以向平台所连设备发送大规模的消息广播。
MQTT 协议主题详解
在MQTT协议通信机制中有三个角色：消息发布者（publisher）、代理服务器（broker）和消息订阅者（subscriber）。消息从发布者发送到代理服务器，然后被订阅者接收，而主题就是发布者与订阅者之间约定的消息通道。
发布者指定的主题发送消息，订阅者从指定的主题订阅接收消息，而 Broker 则起到按照主题接受并分发消息的代理人。在车联网 TSP 平台场景中，车载设备、移动终端与业务应用都可以被看作是 MQTT 的客户端。根据业务不同与数据方向不同，车载设备、移动终端与业务应用的角色也会在发布者与订阅者之间切换。
■ 针对车端的消息处理
MQTT 协议中规定了主题是一段 UTF-8 编码的字符串，主题需要满足以下规则：
所有的主题名和主题过滤器必须至少包含一个字符。
主题名和主题过滤器是大小写敏感的。如：ACCOUNTS 和 Accounts 是不同的主题名。
主题名和主题过滤器可以包含空格字符。如：Accounts payable 是合法的主题名
主题名或主题过滤器以前置或后置斜杠 / 区分。如：/finance 和 finance 是不同的。
只包含斜杠 / 的主题名或主题过滤器是合法的。
主题名和主题过滤器不能包含 null 字符(Unicode U+0000)。
主题名和主题过滤器是 UTF-8 编码字符串，除了不能超过 UTF-8 编码字符串的长度限制之外，主题名或主题过滤器的层级数量没有其它限制。
■ 主题层级
MQTT 协议主题可以通过斜杠（“/” U+002F）将主题分割成多个层级；作为消息通道，客户端可以通过定义主题层级来实现对消息类型的细分；
例如：一个主机厂有多个车型，每个车型下面有多个车联网业务，我们在定义车机向对某个车型业务系统发消息时可以向<车型A>/ <车辆唯一标识>/<业务X>主题发消息；
当然在MQTT世界中主题可以有很多层（MQTT 协议中没有限制层级数量），比如：<车型A>/<车辆唯一标识(车架号)>/<业务X>/<子业务1>
这样，我们在定义车联网分层级的业务通道的时候可以按主题层级来设计。
■ 通配符
MQTT 协议中订阅者的订阅的主题过滤器可以包含特殊的通配符，允许客户端一次订阅多个主题。
多层通配符
#字符号（“#” U+0023）是用于匹配主题中任意层级的通配符。多层通配符表示它的父级和任意数量的子层级。如：订阅者可以通过订阅<车型A>/# 接收到：
<车型A>
<车型A>/<车架号1>
<车型A>/<车架号1>/<业务X>
这几类主题的消息。
单层通配符
加号 (“+” U+002B) 用于单个主题层级匹配的通配符。如：订阅者可以通过订阅<车型A>/+ 来接收
<车型A>/<车架号1>
<车型A>/<车架号2>
不同于多层通配符，使用单层通配符的时候无法匹配子层级的主题，比如：<车型A>/<车架号1>/<业务X>的主题消息就无法接收到。
主题设计原则最佳实践
前文中我们提到在车联网场景中 MQTT 主题定义了业务与数据的通道，主题定义的核心是区分业务场景。如何合理的定义主题，需要根据一定原则来设计。我们可以从以下几个维度来设计与定义主题：
■ 根据业务数据方向区分
首先，数据的上下行方向不同决定了数据由谁产生，被谁消费。在车联网场景中，车载设备到平台的数据上行通道与平台应用到车的下行数据需要通过主题分开。通过对上行、下行主题的设计区分，可以帮助设计、运维及业务人员快速定位场景、问题及相关干系方。
有些业务可能会同时用到上下行主题，比如车辆申请数据下发后平台下发数据，以及平台请求车辆上班数据后车辆上报数据。这种情况下，由于 MQTT 协议的异步通讯机制，也需要对一个整体业务的上下行主题分别定义。
■ 根据车型区分
在车联网场景中，不同车型意味着车辆产生的数据不完全相同，车机能力不完全相同同，对接的业务应用也不尽相同。我们可以根据车型型号对差异化的车辆数据以及业务进行主题上的区分。当然，同一个主机厂下的不同车型也会有相同的业务和数据，这些业务可以通过跨车型的主题来定义。
■ 根据车辆区分
在车联网场景中，如车控等安全等级较高的业务场景往往需要一对一的主题作为数据通通道。一方面通过主题来隔离车辆与车辆之间的业务信息，另一方面保证数据可以点对点的交互。在主题设计中，有时需要将车辆的唯一标识符作为主题的一部分来实现一对一的消息通道。常见的方案有使用车辆 VIN 码作为主题的一部分。
■ 根据用户区分
在实际使用场景中，也存在需要根据用户（而不是车辆）实现车云的一对一的消息通道，此类需求经常发生在用户促销、运营、ToB 业务等场景中。
在主题设计时，常见的方案有两种，一是使用用户 ID 作为主题的一部分；二是通过人-车关系转换成车辆级主题，但由于消息时效性、车内用户登录状态等原因，此方案下生产端及消费端均需要添加额外的设计及处理，相对复杂。
图片
■ 根据研发环境区分
从项目工程实施角度出发，一般在主题设计时同时会添加环境变量，通过配置实现不同研发环境下的资源复用以及正确性检查。
■ 根据数据吞吐量区分
由于业务的不同，不管是上行数据还是下行数据，数据的发送频率与报文大小都不尽相同。
不同的数据吞吐量会影响到消费端的处理以及架构设计，比如我们在处理高频的车辆数据上报业务时往往要考虑应用层的消费能力，这时候可能要借助类似 Kafka 之类的高吞吐消息队列来进行数据缓冲，防止应用消费不及时造成数据积压与数据丢失。所以在 MQTT 主题定义上，我们往往也需要对不同数据吞吐量的业务进行区分。
MQTT 协议主题设计在车联网场景中的应用
■ 车辆数据主动上报
车载设备（T-box，车机等）作为车辆运行数据的收集者，基于固定频率将车内各类控制器、传感器等数据打包发送到平台端。此类数据一般可以按照上报数据的车型、车架号、业务数据类型等多个层级进行设计。
例如在用户同意的前提下，车辆在行驶过程中会将位置、车速、电量等信息按照固定频率上报云平台，云端应用基于这些数据，提供位置查找、超速提醒、电量提醒、地理围栏服务给终端用户使用。
■ 平台请求下发后车辆数据上报
当云平台需要获取车辆的最新状态及信息时，可以主动下发命令要求车辆上报数据。此类场景一般可以按照车架号、业务类型等层级进行主题设计。
例如在诊断场景下，平台通过MQTT下发诊断命令至车辆，当车内各设备完成诊断操作后，会将诊断数据打包后上报至云平台，车辆诊断工程师将根据采集到的诊断数据对于车况进行整体的分析及问题定位。
■ 平台指令下发
车辆远程控制是车联网业务中最常见、最典型的场景，各主机厂均在手机 App 中提供各种远控功能，例如远程启动、远程开车门、远程闪灯鸣笛等等。
此类场景下，手机 App 发送控制命令至云平台，平台应用经过权限检查、安全检查等一系列操作后，通过 MQTT 将命令下发至车辆执行，车辆端执行成功后，异步通知平台执行结果。
此类场景一般可以按照上行下行、车架号、业务类型、操作类型等多个层级进行主题设计。
■ 车辆客户端请求后平台数据下发
在 SDV（软件定义汽车）的大背景下，车内很多配置是可以做到动态变化的，例如数据采集规则、安全访问规则，所以车辆在点火启动后，会主动请求平台最新的相关配置，若两侧配置不一致，平台侧会下发最新的配置信息至车辆，车辆侧实时生效。
此类场景一般可以按照上行下行、车架号、业务类型等多个层级进行主题设计。
使用 EMQX 进行车联网 TSP 平台主题设计
EMQX 作为全球领先的 MQTT 物联网消息中间件，基于分布式集群、大规模并发连接、快速低延时的消息路由等突出特性，能够有效处理车联网场景中高时效性业务需求，大幅度缩短端到端时延，为大规模车联网平台快速部署提供标准的 MQTT 服务。
海量主题支持
随着车联网场景中的业务不断增加，承载业务通道的主题数量也不断增加，尤其是包括车控场景所需要的一车一主题、一车多主题需求越来越大。在这种背景下，MQTT Broker 的主题数承载能力就成为了 TSP 平台的重要评估指标。
EMQX 在一开始的底层设计中就规划了对海量设备连接与海量主题支持的能力。常见的 16 核 32G 内存的 3 节点 EMQX 集群可以支持百万级主题同时运行，为 TSP 平台主题设计提供了灵活的设计空间。
强大规则引擎
EMQX 提供了内置的规则引擎， 基于规则引擎可以提供对不同主题数据的查找、过滤、数据分拆以及对消息重新路由。使用规则引擎，我们可以在已有车载设备与应用主题建立好的场景下，通过创建新的路由规则与数据预处理规则对已有主题中的数据进行再处理。在车辆上市后，通过在平台侧定义新规则实现对新业务应用的支持。
在 EMQX 企业版中，规则引擎提供了数据持久化对接能力，可以通过规则引擎中的配置将不同主题中的数据直接对接不同持久化方案。比如对数据吞吐量比较高的数据可以通过规则引擎对接 Kafka、Apache Pulsar 等高吞吐消息队列进行数据缓冲；而车辆报警等小吞吐低时延主题数据可以直接对接应用，实现数据的快速路由消费。
代理订阅功能
EMQX 提供了代理订阅功能，客户端在连接建立时，不需要发送额外的 SUBSCRIBE 报文，便能自动建立用户预设的订阅关系。这样可以让平台侧直接管理车载设备的主题订阅关系，方便平台侧进行统一管理。
丰富的主题监控与慢订阅统计
EMQX 企业版提供了以主题为监控维度的运行数据监控，可以在 EMQX 可视化 Dashboard 中清晰看到主题下消息流入流出、丢弃的总数和当前速率。
自 4.4 版本起，EMQX 提供了对慢订阅的统计。该功能会追踪 QoS1 和 QoS2 消息到达 EMQX 后，完成消息传输全流程的时间消耗，然后采用指数移动平均算法，计算该订阅者的平均消息传输时延，之后按照时延高低对订阅者进行统计排名。
通过在 TSP 平台运营过程中不断监控各种主题的数据接收与消费情况，平台运营者就可以根据业务变化不断调整平台业务设计与应用设计，实现平台的不断优化扩展。
同时，我们在使用 EMQX 作为车联网 TSP 平台 MQTT Broker 时，在设计主题的过程中需要注意以下问题：
通配符使用与主题数层级
由于 EMQX 采用主题树的数据结构对主题进行过滤匹配。在使用通配符来匹配多个主题的场景下，如果主题层级非常多，就会对 EMQX 产生比较大的资源消耗。所以在主题设计时，不建议层级太多，一般不建议超过5层。
主题与内存的消耗
由于在 EMQX 中主题数与主题长度主要与内存相关，我们在承载大量主题的同时也要重点监控 EMQX 集群内存的用量。
车联网 MQTT 消息 QoS 等级设计
通信的安全、稳定、可靠自始至终都是车联网亘古不变的话题，因此一套完善的数据传输保障方案也是车联网业务中不可忽视的一部分。
MQTT 协议中规定了消息服务质量（Quality of Service，以下简称 QoS）。QoS 保证了在不同的网络环境下消息传递的可靠性，可作为车联网场景中保障消息可靠性传输的首要实现技术。
MQTT 设计了 3 个 QoS 等级：
■ QoS 0
消息最多传递一次。如果当时客户端不可用，则会丢失该消息。Sender (可能是 Publisher 或者 Broker) 发送一条消息之后，就不再关心它有没有发送到对方，也不设置任何重发机制。
■ QoS 1
消息传递至少 1 次。包含了简单的重发机制，Sender 发送消息之后等待接收者的 ACK，如果没收到 ACK 则重新发送消息。这种模式能保证消息至少能到达一次，但无法保证消息重复。
■ QoS 2
消息仅传送一次。设计了重发和重复消息发现机制，保证消息到达对方并且严格只到达一次。
车联网场景中的消息 QoS 设计
首先需要明确的是 QoS 级别越高，消息交互越复杂，系统资源消耗越大，所以 QoS 等级不是设置的越高越好。应用程序可以根据自己的网络场景和业务需求，选择合适的 QoS 级别。
根据车联网信息服务相关数据的属性和特征，我们可以将其分为六类：基础属性类数据、车辆工控类数据、环境感知类数据、车控类数据、应用服务类数据和用户个人信息。
那么在不同的车联网场景中如何选择 MQTT QoS 等级呢？
■ 以下情况下可以选择 QoS 0
可以接受消息偶尔丢失的场景下可以选择 QoS 0。
车联网提供的与娱乐相关的多媒体服务，如天气预报等数据等。还有部分涉车服务类数据，如车辆历史行车数据的上报、历史行车操作数据等。
■ 以下情况下可以选择 QoS 1
车联网大部分场景都是选用 QoS1，它实现了系统资源性能和消息实时性、可靠性最优化。
QoS 1 广泛运用于控车消息、行车上报数据（含新能源国标和企标）、交通安全管控类数据，和交通安全、道路安全相关的预警数据。
■ 以下情况下可以选择 QoS 2
对于不能忍受消息丢失，且不希望收到重复的消息，数据完整性与及时性要求较高的场景，可以选择 QoS 2。
车联网场景中 QoS 2 的应用并不多，虽然其可以增加消息可靠性，但同时也使资源消耗和消息时延大幅增加。
QoS 2 主要运用于对数据完整性与及时性要求较高的银行、消防、航空等行业，有些主机厂的行车告警和车辆充电桩计费费单消息会选择采用 QoS 2。
特别提醒
需要注意的是 MQTT 发布与订阅操作中的 QoS 代表了不同的含义，发布时的 QoS 表示消息发送到 MQTT Broker 使用的 QoS 等级，订阅时的 QoS 表示 MQTT Broker 向自己转发消息时可以使用的最大 QoS 等级。
需要保障发送与订阅的 QoS 一致，才能确保最终收到的消息是固定的 QoS 等级，否则会出现消费降级的情况。例如：A 发送的消息 QoS 为 2，B 订阅的消息 QoS 为1，则最终接收到消息的 QoS 为 1。
结语
车联网是物联网技术在交通系统领域的典型应用，车联网行业所涉及的相关技术领域的融合布局与协同发展在某种程度上与物联网一脉相通。
本文详细介绍了搭建一个可靠的车联网消息平台需要了解的理论知识及实操经验，以期帮助整车制造商、T1 供应商、后市场服务商、出行服务公司等实现对人、车、路、云的统一连接，进一步打造智能网联、自动驾驶和 V2X 等场景解决方案，促进车联网产业的发展与繁荣。
Copyright © 2005-2021 网信安全世界版权所有