新年10个Flag实现中~
访问量
551.7K
文章数
120
运行天
711
一、M12简介Moquette0.12(以下简称M12)的订阅树实现在moquette-0.12/broker/src/main/java/io/moquette/broker/subscriptions,包括:订阅树版本 M10 M12  订阅树增删改查SubscriptionDirectory CTrieSubscriptionDirectory 订阅树 - CTrie 片段 Token Token 主题 Topic Topic 订阅信息 Subscription Subscription 普通节点 
一、M10简介Moquette0.10(以下简称M10)的订阅树实现在moquette-0.10/broker/src/main/java/io/moquette/spi/impl/subscriptions,包括:SubscriptionsDirectory:订阅树的增删改查Token:片段,由topicFilter按“/”分割而成的最小字符串单位Topic:主题/主题过滤器,包含一系列方法,比如比较主题和主题过滤器是否匹配Subscription:订阅信息,{clientId,topicFilter,qos,active}TreeNode:树节点查看源码的时候应该从SubscriptionsDirectory开始阅读。二、M10订阅树表示假设有如下订阅信息: 节点编号 
一、MQTT主题和主题过滤器匹配需求MQTT协议规定,客户端可以订阅(Subscribe)主题过滤器(TopicFilter),主题过滤器可能为:完全精确的主题过滤器。例如:abc/def/123含有单层通配符(+,SINGLE)的主题过滤器。例如:abc/+/123含有多层通配符(#,MULTI)的主题过滤器。例如:abc/#同时,客户端还可以向某个主题(Topic)发布(Publish)消息,比如abc/def/123,主题不能含有通配符。MQTTBroker需要查询有哪些客户端订阅了匹配这个主题的主题过滤器,并将消息发送给它们。例如下图所示情况:客户端X是发布者,将数据发布到主题"abc/def/123";客户端A、B、C、D都是订阅者,但只有A、B、C订阅的主题过滤器和该主题匹配:A
前言在接触到MQTT之后,总是会有疑问,为什么用MQTT不用TCP长连接透传?看起来【TCP长连接+私有协议透传】和【MQTT+业务主题】似乎都能达到同样的目的,甚至用MQTT会使得设备端逻辑实现、APP端逻辑实现、云端架构实现更加复杂。那么为什么物联网还要使用MQTT协议呢?一、MQTT相比于TCP长连接的优势1、协议更标准MQTT是标准的RFC协议,相比于私有协议而言更加标准。好处在于:(1)协议非常完整,能够马上用于生产。各端实现同一套协议之后,就能进行通信;私有协议还需要进行大量的验证,看有无缺陷或欠考虑的地方等。(2)协议的标准化带来大量的开源组件,降低开发难度。随着物联网+5G生态越来越好,开源组件越来越多,可以减少重复编码量。(3)标准协议利于第三方接入。当第三方设备、平台想要
前言经常会遇到在windows上上传文件到AWSS3的需求,由于某些原因不方便直接使用AWS提供的HTTP界面去上传文件,只好用脚本上传。在windows上更多的是编译好了一个程序想放到AWS的机器跑一跑,用S3做文件中转。直接用脚本的话,每次都要输入对应的文件路径,比较麻烦,更想有个GUI界面选择文件后自动把路径填上去,AWS提供了boto3这个库,支持java、python等等,我们用python3来做这件事。一、前期准备(1)IDE:推荐使用PyCharm,方便的是当有库没有安装时会提示你Alt+Enter快速安装(2)Python:3.6+(3)python库安装:用pip3install提前安装好所有的库aws库:boto3,官方文档和示例python打包成EXE库:pyinsta
一、top经典界面参数含义1、系统状态top-21:36:59up13days,45min,1user,loadaverage:0.35,0.12,0.04现在的系统时间:21:36:59系统已经启动了:13天45分钟用户数量:1个系统平均负载1分钟、5分钟、15分钟:0.35、0.12、0.04系统平均负载指的是,在特定时间间隔内运行队列中的平均进程数。一个进程通常会在没有等待I/O操作、没有主动进入等待状态、没有被中止的情况下处于运行态。Top的这个系统平均负载是每隔5秒检查一次活跃进程数计算得到的,如果这个数值除以逻辑CPU的数量:<0.70:正常0.70~1.00:有一些负荷了,需要检查1.00~5.00:刚好1个CPU处理1个进程,但占用了全部的CPU资源,应该马上检查进程是
前言无意间搜到一篇知乎技术团队一个月前(2019年5月24日)发表的《知乎千万级高性能长连接网关揭秘》,浏览了内容和评论后兴奋了起来,这感觉就像考试之后对答案发现另一个同学的解题思路跟你一模一样而且别人已经考了150分。分布式服务器最头疼的就是长连接了,下面结合知乎的做法,具体说一说长连接网关的设计难点和解决思路。一、长连接网关的需求分析对于安卓APP的应用,长连接能提供推送消息、即时通讯、游戏、共享定位等等功能,也就是适用于需要服务器主动往客户端“推”的业务场景。随着业务规模的扩大,不同的业务可能都会需要长连接,所以现在几乎每个互联网公司都会将长连接系统做成一个基础服务供后面的业务使用。知乎团队称自己的这套长连接网关设计方案“经过一年多开发和演进,面向数个APP,数百万设备同时在线,经历了
前言百度IoT的Broker设计我特别想参考的但是技术能力和时间不够去实现……网上只有一篇百度工程师的总结《共享行业的分布式MQTT设计》,这里将围绕这篇文章去讲解。一、Broker集群架构单机版MQTTBroker有连接数量和并发处理能力的限制,因此分布式必不可少。百度IoT采用的AkkaCluster来做集群管理,每个节点对等,不存在像Mosquitto这种用一台机器“桥接”做分布式产生的单点故障隐患。每个节点监听MemberUp、MemberDown、MemberUnreachable、ClusterMemberState等事件来感知其他节点的上下线,用AkkaActor实现节点间的消息通信。二、Broker服务框架百度Broker抽象了很多服务包括:(1)Authentication
12345... 14下一页