IoT设备消息洪峰怎么扛? 阿里云AIoT消息队列深度解读

简介: 本文整理了一份IoT队列的干货知识,让物联网从业者更进一步了解IoT场景队列,一同探讨一个适合于物联网系统的消息队列。

传统的消息队列((Kafka、RocketMQ等)经过多年打磨,在高性能、海量堆积、消息可靠性等诸多方面都已经做得非常极致,但在物联网场景中,往往需要面临着海量的消息传递,传统的消息队列表现的“力不从心”。

IoT领域中,从应用服务器到嵌入式芯片,都需要传递事件消息,比如共享充电宝的开柜子、开灯指令从服务器发到设备、工业网关高频消息流等,在这些信息传递的过程中,队列最大意义在于让整个消息事件在不可控的环境因素变成一个平稳运行的系统,因为IoT设备时不时会由于故障或网络抖动会导致大量消息洪峰。

阿里云AIoT作为物联网领域的引领者和创新者,在消息队列领域不断深耕与沉淀,为了让物联网从业者更进一步了解IoT场景队列,阿里云技术专家吕建文,整理了一份IoT队列的干货知识,与大家一同探讨一个适合于物联网系统的消息队列。


一、IoT队列和普通队列的差异点

1,上下行隔离拆分


在IoT场景中,我们把需要队列分为两个场景,一个是上行队列,一个是下行队列。 拆分之后,可以隔离上下行链路,控制一个设备,比如支付成功要下发打开柜子等,上行出任何问题,千万不能影响到下行业务。另外,上下行两条链路的特点差异非常大。设备上行消息,并发量非常高,但很多场景下对于可靠性和时延要求低,而设备下行消息,并发量则比较低,但下行消息(一般是控制设备指令)要求到达成功率很高。

1.jpg

2,支持设备级的海量topic


传统队列的核心诉求是,不论堆积多少不影响它的性能。kafka的topic一多,原本消息顺序写文件优势就会导致一个broker要退化到随机写,失去优势,另外要zookeeper来协调这么多topic也是有局限,所以这些队列本身有提供一个外挂代理桥接器对外入口是多个设备topic,再桥接映射到少量的实际kafka topic,这方案有一定可行性,但做不到隔离效果,治标不治本。


通过,图1和图2对比较明显,一个队列拥塞尽量减少对其它设备影响。我们需要的是“海量topic尽量相互隔离,并且不影响整体性能”,尽量做到设备A的消息堆积topic,不影响设备B。

2.jpg

3,实时生成消息优先发送


先举一个例子,一个快递柜业务的队列堆积,然后“此时此刻”在柜子旁边的用户死命的在旁边用手机点开柜子怎么也打不开(此时后端系统都恢复了),问题就是队列里面还有几十万条的消息,新来的消息需要排队, 等着之前的那些消息消费完,甭管这些消息还有没有用。  因此,实时生成消息优先发送,堆积的消息进入降级模式。


二、IoT消息队列诞生


1, IoT队列的设计思路

3.jpg

设计目标是为了打造一个支持上下行隔离、实时优先、及海量topic的队列网关,设计原则如下:

  • 完全follow开源生态、和传统队列互补兼容
  • 保序降级,实时优先,堆积退化;仅实时消息相对有序。
  • 海量topic,多租户隔离
  • 连接、计算、存储分离

2, 消息模式


图片只是个片段,从这个模式可以看出来机制差别,大家都没有错,只是出发点不同。

4.jpg

3, 连接、计算、存储分离

5.jpg

broker不做连接,连接网关代理,broker只做流转分发,无状态+水平扩展;存储交给nosql DB,高吞吐写。

4, 消息策略-推拉结合


这个应该是队列的核心难点之一,和传统队列区分在于,我们考虑为平台化模式,独享资源过于昂贵。但带来问题是消费端不可控,所以使用结合模式,只有在消费者在线时会拉取堆积消息,而拉取是由AMQP队列网关来做,给到用户接口始终是推送过去的onMessage回调。

6.jpg

  • broker不是直接让consumer来连接,而是把队列网关剥离出来,  这样会更灵活,甚至对于部分用户我们的queue可以切换到ons、kafka等实现。kafka、rocketmq做法是在连接时会分配给客户端一个broker接入地址。


  • broker实时消息优先推送给consumer,失败才会落到queue ;这是一个完整事件,如果没有完成则不给producer commit。


  • 异步ACK


5, 线性扩展-离线消息部分


实时部分消息采用推方式,基本上不会成为瓶颈,消费不过来消息进入堆积模式。由于底层依赖存储已经帮我们解决核心存储的扩展,剩下主要问题点在于如何消除写入热点和消费热点,这样broker可以完全做到无状态。

640.png

三,一个思考——如何解决海量topic问题?



首先面对“大量”的问题一般都是考虑分区,单元化,分组等隔离和拆分,这里海量topic我们讨论针对一个单实例模式下如何尽可能做到更多topic,完全任意数量都能100%没问题肯定是不现实的。


由于broker和存储已经隔离,broker和topic已经没有什么关系,或者说任何topic数据生成,broker做的事情就是写入和分发。

  • 海量topic,每个topic有限数量订阅:  topic和订阅者关系使用redis缓存或本地缓存,针对mqtt topic匹配有个topic tree的树算法,hivemq有实现版本。
  • 单个topic 海量订阅:  这个场景其实是组播和广播,我们不会考虑在队列本身上面去做这个事情,而是在上层封装广播组件来协调任务和批量发送。


四, 阿里云AIoT消息队列

8.jpg

目前阿里云AIoT队列,也叫服务端订阅,意思就是用户用服务端订阅他们设备消息。为了降低接入成本,用户可以使用AMQP1.0协议接入,符合开源生态。 同时兼容传统队列和新队列,交给用户按场景来选择,用户即可选择使用kafka、mq,也可以选用iot队列,甚至组合模式,比如按消息特征规则来配置流转队列。

阿里云AIoT的场景队列实践,在现有mq队列、kafka队列融合之外,加了种自有的实时优先队列实现,同时,加入了队列网关代理,既能让用户选择普通消息队列,也可以选择轻便的IoT消息队列。

目录
相关文章
|
消息中间件 Java Kafka
一款消息队列的客户端框架——启明信息车联网MQ演进实践分享
一款消息队列的客户端框架——启明信息车联网MQ演进实践分享 分享人:阿里云MVP曾宪宇,2014开始 就职于启明信息,负责车联网平台的架构和建设,坐标吉林长春。 分享内容:结合主流MQ,介绍一款基于Java的开源消息队列客户端框架。
2971 0
一款消息队列的客户端框架——启明信息车联网MQ演进实践分享
|
6月前
|
消息中间件 存储 物联网
RocketMQ 之 IoT 消息解析:物联网需要的消息技术
RocketMQ 5.0 是为应对物联网(IoT)场景而发布的云原生消息中间件,旨在解决 IoT 中大规模设备连接、数据处理和边缘计算的需求。
1085 16
|
6月前
|
消息中间件 存储 Cloud Native
深度剖析 RocketMQ 5.0,IoT 消息:物联网需要什么样的消息技术?
本文来学习一个典型的物联网技术架构,以及在这个技术架构里面,消息队列所发挥的作用。在物联网的场景里面,对消息技术的要求和面向服务端应用的消息技术有什么区别?学习 RocketMQ 5.0 的子产品 MQTT,是如何解决这些物联网技术难题的。
91082 4
EMQ
|
消息中间件 物联网 网络安全
2023 年最适用于工业物联网领域的三款开源 MQTT Broker
本文对比分析了 2023 年工业物联网领域最优秀的三款 MQTT Broker,介绍了它们的优点、缺点和应用场景。
EMQ
1171 0
2023 年最适用于工业物联网领域的三款开源 MQTT Broker
|
消息中间件 机器学习/深度学习 监控
「物联网架构」通过 Kafka和MQTT实现大规模的物联网和事件流
「物联网架构」通过 Kafka和MQTT实现大规模的物联网和事件流
EMQ
|
弹性计算 负载均衡 监控
EMQX+阿里云飞天洛神云网络 NLB:MQTT 消息亿级并发、千万级吞吐性能达成
近日,EMQ与阿里云旗下飞天洛神云网络展开合作,与NLB产品合作构建了新一代支持「亿级并发、千万级吞吐」的物联网消息服务系统。
EMQ
457 0
EMQX+阿里云飞天洛神云网络 NLB:MQTT 消息亿级并发、千万级吞吐性能达成
|
新零售 运维 自动驾驶
稳定服务亿级连接,阿里云IoT物联网络新能力发布
阿里云发布的物联网络新能力,包括新平台、新网络和新生态,突出智能高效的特点。
440 0
稳定服务亿级连接,阿里云IoT物联网络新能力发布
EMQ
|
消息中间件 存储 缓存
车联网移动场景 MQTT 通信优化实践
本文将分析车联网移动场景下MQTT消息传输面临的问题及产生原因,并利用MQTT协议特性对其加以解决和优化,构建更稳定的车联网通信架构。
EMQ
320 0
车联网移动场景 MQTT 通信优化实践
EMQ
|
消息中间件 存储 安全
千万级车联网 MQTT 消息平台架构设计
本文我们将讨论车联网场景中的 MQTT 消息采集与传递,以及如何构建一个千万级车联网 MQTT 消息平台。
EMQ
936 0
千万级车联网 MQTT 消息平台架构设计
EMQ
|
消息中间件 存储 负载均衡
车联网平台百万级消息吞吐架构设计
本文将主要介绍如何针对百万级消息吞吐这一需求进行新一代车联网平台架构设计。
EMQ
558 0
车联网平台百万级消息吞吐架构设计
下一篇
无影云桌面