MQTT学习笔记(1)粗略认识

1.前言
先来看下这种应用场景,如下图:
这里写图片描述
这张图是从阿里云网站上找到的,体现了下面内容:

  • 数据采集
    大量的车辆连接,几十万甚至上百万量车,数据要实时双向互通,数据有上传,也有下推数据,需要保证实时高并发可靠传输。
  • 数据处理和数据存储
    收集的数据要进行数据处理和存储。例如,要实时存储单车辆运行时的数据、电池用量、状态信息等,还需要对总体的车辆的数据进行计算和统计。

MQTT就比较适合做这种应用,其实我感觉那些社交聊天软件也是MQTT的思想。

MQTT–消息队列遥测传输协议,建立在TCP之上,基于发布Publish/订阅Subscribe模式,二进制传输的轻量级消息协议。

2.拓扑结构如下
这里写图片描述
从图中可以看到有3中角色,发布者Publisher -> 代理Broker -> 订阅者Subscriber
发布和订阅者可以是同一个设备,也可以是不同设备,发布者比较典型的代表就是散落在各地的传感器,比如温度传感器,订阅者可以是手机、电脑、数据库等,订阅者先要订阅相关主题,Broker就会把订阅者订阅的主题发给订阅者。
这种结构替代传统的客户端/服务器模型,可以实现以下解耦

  • 空间解耦 :发布者和订阅者不需要知道对方
  • 时间解耦 :发布者和订阅者不需要同时运行(离线消息)
  • 同步解耦 :发布和接收都是异步通讯,无需停止任何处理

3.基本概念

  • 报文结构
    一帧MQTT控制报文结构
  • 报文类型
    MQTT固定报头的第一个字节的高4bit表示报文类型
    这里写图片描述
    MQTT固定报头的第一个字节的低4bit表示报文类型对应的标志位
    这里写图片描述
    上表中的 DUP,QoS,RETAIN 是在 MQTT V3.1.1 协议里用的, 用于描述发布的这一帧消息的属性。
    综上可以得到固定报头第一个字节
    这里写图片描述
    可以分成这几类
    连接Connect / disconnect
    发布Publish
    订阅Subscribe / unsubscribe
    保活Pingreq
  • 特性
    服务质量QoS(Quality of Service)
    最多一次:发送一次,无需回复,消息有可能丢失。(传感器数据)
    至少一次:发送者没有收到接收者的PUBACK,过一段时间会重新发送,消息可能重复。
    只有一次:发送过程经过 PUBREC、PUBREL、PUBCOMP,保证一个包只收到一次
    保留消息Retained Messages
    持续会话Persistent Session
    最后遗嘱Last Will and Testament
    基于主题,具有主题过滤器
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值