一、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

前言无意间搜到一篇知乎技术团队一个月前（2019年5月24日）发表的《知乎千万级高性能长连接网关揭秘》，浏览了内容和评论后兴奋了起来，这感觉就像考试之后对答案发现另一个同学的解题思路跟你一模一样而且别人已经考了150分。分布式服务器最头疼的就是长连接了，下面结合知乎的做法，具体说一说长连接网关的设计难点和解决思路。一、长连接网关的需求分析对于安卓APP的应用，长连接能提供推送消息、即时通讯、游戏、共享定位等等功能，也就是适用于需要服务器主动往客户端“推”的业务场景。随着业务规模的扩大，不同的业务可能都会需要长连接，所以现在几乎每个互联网公司都会将长连接系统做成一个基础服务供后面的业务使用。知乎团队称自己的这套长连接网关设计方案“经过一年多开发和演进，面向数个APP，数百万设备同时在线，经历了

前言百度IoT的Broker设计我特别想参考的但是技术能力和时间不够去实现……网上只有一篇百度工程师的总结《共享行业的分布式MQTT设计》，这里将围绕这篇文章去讲解。一、Broker集群架构单机版MQTTBroker有连接数量和并发处理能力的限制，因此分布式必不可少。百度IoT采用的AkkaCluster来做集群管理，每个节点对等，不存在像Mosquitto这种用一台机器“桥接”做分布式产生的单点故障隐患。每个节点监听MemberUp、MemberDown、MemberUnreachable、ClusterMemberState等事件来感知其他节点的上下线，用AkkaActor实现节点间的消息通信。二、Broker服务框架百度Broker抽象了很多服务包括：（1）Authentication

一、物联网和MQTT随着各家嵌入式产品越来越多，技术也越来越成熟，大家都开始想要随便搭载一个AI算法，然后声称为人工智能产品去售卖，像天猫精灵、小米智能音箱之类。这些产品大多都是嵌入式设备，例如小米出了很多传感器，可以用手机APP控制。这就是万物联结的网络，称为物联网（InternetofThings，IoT）。一个很重要的功能当然是通信了，以前的想法就是，要么用Wifi连上家里的路由器，然后搭建一台HTTP服务器来提供服务就好；要么直接用蓝牙等近场通信方式，手机直接和设备交换数据。无论哪种，对嵌入式设备的电量消耗都是巨大的，而且操作的体验并不好，就好像你用蓝牙还得凑近它10米以内。于是人们开始寻找更好的替代方式，1999年IBM开发的MQTT协议重新出现在舞台上。MQTT全称是消息队列遥测