共计 2532 个字符，预计需要花费 7 分钟才能阅读完成。
简介： 本文整顿了一份 IoT 队列的干货常识，让物联网从业者更进一步理解 IoT 场景队列，一起探讨一个适宜于物联网零碎的音讯队列。
传统的音讯队列（（Kafka、RocketMQ 等）通过多年打磨，在高性能、海量沉积、音讯可靠性等诸多方面都曾经做得十分极致，但在物联网场景中，往往须要面临着海量的消息传递，传统的音讯队列体现的“力不从心”。
IoT 畛域中，从应用服务器到嵌入式芯片，都须要传递事件音讯，比方共享充电宝的开柜子、开灯指令从服务器发到设施、工业网关高频音讯流等，在这些信息传递的过程中，队列最大意义在于让整个音讯事件在不可控的环境因素变成一个安稳运行的零碎，因为 IoT 设施时不时会因为故障或网络抖动会导致大量音讯洪峰。
阿里云 AIoT 作为物联网畛域的引领者和创新者，在音讯队列畛域一直深耕与积淀，为了让物联网从业者更进一步理解 IoT 场景队列，阿里云技术专家吕建文，整顿了一份 IoT 队列的干货常识，与大家一起探讨一个适宜于物联网零碎的音讯队列。
一、IoT 队列和一般队列的差别点
1，上下行隔离拆分
在 IoT 场景中，咱们把须要队列分为两个场景，一个是上行队列，一个是上行队列。拆分之后，能够隔离上下行链路，管制一个设施，比方领取胜利要下发关上柜子等，上行出任何问题，千万不能影响到上行业务。另外，上下行两条链路的特点差别十分大。设施上行音讯，并发量十分高，但很多场景下对于可靠性和时延要求低，而设施上行音讯，并发量则比拟低，但上行音讯（个别是管制设施指令）要求达到成功率很高。
2，反对设施级的海量 topic
传统队列的外围诉求是，不管沉积多少不影响它的性能。kafka 的 topic 一多，本来音讯程序写文件劣势就会导致一个 broker 要进化到随机写，失去劣势，另外要 zookeeper 来协调这么多 topic 也是有局限，所以这些队列自身有提供一个外挂代理桥接器对外入口是多个设施 topic，再桥接映射到大量的理论 kafka topic，这计划有肯定可行性，但做不到隔离成果，治标不治本。
通过，图 1 和图 2 对比拟显著，一个队列拥塞尽量减少对其它设施影响。咱们须要的是“海量 topic 尽量互相隔离，并且不影响整体性能”，尽量做到设施 A 的音讯沉积 topic，不影响设施 B。
3，实时生成音讯优先发送
先举一个例子，一个快递柜业务的队列沉积，而后“此时此刻”在柜子旁边的用户死命的在旁边用手机点开柜子怎么也打不开（此时后端系统都复原了），问题就是队列外面还有几十万条的音讯，新来的音讯须要排队, 等着之前的那些音讯生产完，甭管这些音讯还有没有用。因而，实时生成音讯优先发送，沉积的音讯进入降级模式。
二、IoT 音讯队列诞生
1，IoT 队列的设计思路
设计指标是为了打造一个反对上下行隔离、实时优先、及海量 topic 的队列网关，设计准则如下：
- 齐全 follow 开源生态、和传统队列互补兼容
- 保序降级，实时优先，沉积进化；仅实时音讯绝对有序。
- 海量 topic，多租户隔离
- 连贯、计算、存储拆散
2，音讯模式
图片只是个片段，从这个模式能够看进去机制差异，大家都没有错，只是出发点不同。
3，连贯、计算、存储拆散
broker 不做连贯，连贯网关代理，broker 只做流转散发，无状态 + 程度扩大；存储交给 nosql DB，高吞吐写。
4，音讯策略 - 推拉联合
这个应该是队列的外围难点之一，和传统队列辨别在于，咱们思考为平台化模式，独享资源过于低廉。但带来问题是生产端不可控，所以应用联合模式，只有在消费者在线时会拉取沉积音讯，而拉取是由 AMQP 队列网关来做，给到用户接口始终是推送过来的 onMessage 回调。
- broker 不是间接让 consumer 来连贯，而是把队列网关剥离进去，这样会更灵便，甚至对于局部用户咱们的 queue 能够切换到 ons、kafka 等实现。kafka、rocketmq 做法是在连贯时会调配给客户端一个 broker 接入地址。
- broker 实时音讯优先推送给 consumer，失败才会落到 queue；这是一个残缺事件，如果没有实现则不给 producer commit。
- 异步 ACK
5，线性扩大 - 离线音讯局部
实时局部音讯采纳推形式，基本上不会成为瓶颈，生产不过去音讯进入沉积模式。因为底层依赖存储曾经帮咱们解决外围存储的扩大，剩下次要问题点在于如何打消写入热点和生产热点，这样 broker 能够齐全做到无状态。
三，一个思考——如何解决海量 topic 问题？
首先面对“大量”的问题个别都是思考分区，单元化，分组等隔离和拆分，这里海量 topic 咱们探讨针对一个单实例模式下如何尽可能做到更多 topic，齐全任意数量都能 100% 没问题必定是不事实的。
因为 broker 和存储曾经隔离，broker 和 topic 曾经没有什么关系，或者说任何 topic 数据生成，broker 做的事件就是写入和散发。
- 海量 topic，每个 topic 无限数量订阅：topic 和订阅者关系应用 redis 缓存或本地缓存，针对 mqtt topic 匹配有个 topic tree 的树算法，hivemq 有实现版本。
- 单个 topic 海量订阅：这个场景其实是组播和播送，咱们不会思考在队列自身下面去做这个事件，而是在下层封装播送组件来协调工作和批量发送。
四，阿里云 AIoT 音讯队列
目前阿里云 AIoT 队列，也叫服务端订阅，意思就是用户用服务端订阅他们设施音讯。为了升高接入老本，用户能够应用 AMQP1.0 协定接入，合乎开源生态。同时兼容传统队列和新队列，交给用户按场景来抉择，用户即可抉择应用 kafka、mq，也能够选用 iot 队列，甚至组合模式，比方按音讯特色规定来配置流转队列。
阿里云 AIoT 的场景队列实际，在现有 mq 队列、kafka 队列交融之外，加了种自有的实时优先队列实现，同时，退出了队列网关代理，既能让用户抉择一般音讯队列，也能够抉择轻便的 IoT 音讯队列。
版权申明： 本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。
