物联网基础概述【二】-CSDN博客

本文链接：https://blog.csdn.net/LB_bei/article/details/148587135

2.物联网的结构

物联网主要是由设备、网关、服务器构成的；

2.1 网关

网关能够连接多台设备，且能够直接连接互联网，负责将不能直接连接互联网的设备转发到互联网；

网关与设备通过接口连接，包括有线方式（串行通信、USB连接）和无线方式（蓝牙、Zigbee等）；

而网关连接外部网络通过网络接口连接，包括以太网（有线连接、通信稳定，但必须把LAN电缆布线到网关的位置）和Wi-Fi、5G/LTE（无线连接，通信质量受到信号强弱的影响）等方式；

2.2 服务器的结构

这个部分是我们主要要做的模块；

物联网服务主要分为前端部分、处理部分和数据库部分；

前端部分：包括数据采集服务与命令下发服务，采集服务接收设备和网关发送的数据，转交给处理部分；下发服务则将从处理部分接收的内容发送给设备；
处理部分：负责处理从前端部分接收到的数据，包括分解数据、存储数据、分析数据、生成发送给设备的通知内容；
数据库部分：包括关系型数据库与非关系型数据库，根据不同数据选择合适数据库存储；

2.3 接收数据

数据接收服务器接收设备发来的数据，设备可以通过MQTT、HTTP或者WebSocket、WebRTC来发送数据；

2.3.1 HTTP协议

HTTP协议提供的方法最简易，采用请求/响应模式，每次请求都会建立独立的短连接，设备使用HTTP的GET方法和POST方法访问服务器，把数据存入请求参数或请求体；

2.3.2 WebSocket协议

WebSocket协议是一种在单个TCP连接上进行全双工通信的协议，允许服务器与设备之间进行持续的双向数据传输，也就是长连接，设备和服务器可以独立的随时发送数据给对方，实时性高、开销小、支持服务器主动推送，适合需要低延迟、高频率的双向通信（如在线聊天、股票实时行情等）；

2.3.3 MQTT协议

MQTT协议是一种轻量级、基于发布/订阅模式的消息协议，具有消息小、耗能低等特点，主要由发布者（publisher）、订阅者（subscriber）、消息代理服务器（broker）构成；

消息代理服务器承担着转发MQTT通信的服务器的作用，发布者作为发送消息的客户端，订阅者作为接收消息的客户端，各个客户端将MQTT消息所附带的主题看做收信地址，来将消息收发到信箱（消息代理服务器），而订阅者订阅了某个主题收到消息后，消息代理服务器会将消息传递给对应的订阅者；

也就是说订阅者与消息代理服务器总是连接的，而发布者只有在需要发布时才建立连接，各个客户端之间通过消息代理服务器联系不需要知道彼此的IP地址；

下面介绍几个MQTT中的概念

2.3.3.1 QoS

当一消息代理服务器接收到发布者发布的消息后，每个订阅者的QoS将会是自身设置的QoS与发布者设置的Qos二者中的最小的那个；

MQTT中有三个等级的QoS

QoS0：最多只发送一次消息不保证消息到达；
QoS1：至少发送一次消息保证消息到达但是消息可能会重复发送，broker 接收到消息就会向发布者发送一个叫做“PUBACK消息”的响应，当发生故障或一定时间后没能确认 PUBACK 消息时，发布者会重新发送消息，也就是说如果 broker 收到了发布者发来的消息却没有返回 PUBACK，那么消息就会重复；
QoS2：保证成功发送有且只有一次消息，发送的消息里面含有消息ID，broker收到消息后将消息保存，然后给发布者发送 PUBREC 消息，发布者再给 broker 发送 PUBREL 消息，然后 broker 再给发布者发送 PUBCOMP 消息，再将消息发送到订阅者；（需要多次确认，因此开销较大）

2.3.3.2 Retain

正常来说订阅者只能接收订阅之后发布的消息，但如果发布者发布了带有 Retain 标志的消息，broker会保留最新的带有 Retain 标志的消息，当之后有新的订阅者订阅，broker 就会把这条消息发送给订阅者；

2.3.3.3 Will

Will就是一种遗言，如果发布者在连接 broker 时通过 CONNECT报文指定了 Will 标志，定义了触发 Will 要发送的消息以及 QoS，这样当连接意外断开，Will 消息就会发送给订阅者；

当发布者明确使用 DISCONNECT 消息表明正常断开连接，则不会发送 Will 消息；

2.3.3.4 Clean Session

Clean Session 在客户端连接到 broker 时通过 CONNECT 报文发送，决定了会话（Session）在客户端断开连接后的行为，以及客户端重新连接时会话如何恢复；

Clean Session = 1：每次连接都是新的会话，连接时存在旧会话直接销毁，断开连接直接销毁会话；
Clean Session = 0：连接后如果存在旧会话则恢复旧会话，不存在则新建会话，且断开连接不会销毁会话；

MQTT 5.0 之后 Clean Session 拆分成了两个字段：

Clean Start：为 true 表示总是创建一个新的会话；false 表示会尝试恢复旧会话，没有则创建新会话；
Session Expiry Interval：决定会话保留时间，0则断开连接后直接销毁会话，> 0 表示会话在断开连接后保留的描秒数，0xFFFFFFFF 表示会话永不超时；

目前实现 MQTT 使用最多的应该是 EMQX、Mosquitto、NanoMQ等，也可以使用 RabbitMQ 来实现，但是并不完全适配不够轻量；

2.3.4 数据格式

接收数据往往使用二进制形式接收，常用的二进制协议有 MessagePack、Protobuf、FlatBuffers等；

MessagePack 数据体积小（没有JSON中常见的字符{}\,"等，比JSON直接转换的二进制数据小）、解析速度快；

2.4 处理数据

处理服务器主要负责数据分析、数据处理结果保存、数据加工以及向设备发送命令；

而对于数据的分析和加工主要有两种方式：批处理、流处理

批处理：隔一段时间就分批处理一次积累在数据库的数据，因此数据量越多，执行处理的机器性能需要越好，对于高效的处理大数据量主要有 Hadoop、Spark 两种分布式处理平台；
流处理：实时对数据做出反应，数据通常在抵达后立即进行处理，也可能暂时积攒在内存中形成微批次处理，如果数据不需要保存就直接丢弃，高效的流处理平台主要有 Apache Flink、Spark Streaming；

2.5 存储数据

为满足不同类型数据和应用场景的需求，物联网系统通常采用多种类型的数据库来保存数据，以实现数据的最佳存储效率、查询性能和灵活运用；

数据库包括关系型数据库、非关系型数据库（非关系型数据库根据数据类型不同又分为键值存储、文档型、列式和图数据库等）

键值存储数据库：以 key-value 形式存储，具有性能极高、简单易用的特点，但是查询能力有限，不能存储复杂关系的数据，适合做缓存、会话管理、实时数据存储等，主要产品有Redis、Memcached等；
文档型数据库：以文档为单位存储，常见的有JSON、XML格式存储，具有开发灵活、与编程语言中的对象匹配、易于水平扩展（分片）等特点，但不适合处理复杂的多对多关系，事务性相对弱，适合日志和事件数据、结构不固定或频繁变化的场景、内容管理系统、用户画像等，主要产品有MongoDB、Elasticsearch等；
列式数据库：按列存储，具有高度可伸缩性、稀疏数据模型（每行可以拥有不同且大量的列，适合存储很多列没有值的数据）、写入速度与读取特定列速度很快等特点，但不适合复杂的多列条件查询和聚合查询，更新行困难，适合大数据分析、实时数据仓库、消息系统等，主要产品有HBase、Apache Cassandra等；
图数据库：以图结构存储数据，数据由节点（实体，如人、地点、产品）、边（节点之间的关系）、属性（用来描述节点和边的特征）构成，对于查询和分析复杂、多层次的关系数据具有优势，关系查询的性能远远超过关系型数据库的Join操作，与现实世界的实体和关系模型高度吻合，但不适合海量独立数据，需要学习不同的查询语言，难以分布式扩展，适合社交网络存储用户关注点赞等复杂关系、交通路线、推荐系统等，主要产品有Neo4j、ArangoDB、JanusGraph等；