前言
百度IoT的Broker设计我特别想参考的但是技术能力和时间不够去实现……网上只有一篇百度工程师的总结《共享行业的分布式MQTT设计》,这里将围绕这篇文章去讲解。
一、Broker集群架构
单机版MQTT Broker有连接数量和并发处理能力的限制,因此分布式必不可少。百度IoT采用的Akka Cluster来做集群管理,每个节点对等,不存在像Mosquitto这种用一台机器“桥接”做分布式产生的单点故障隐患。每个节点监听MemberUp、MemberDown、MemberUnreachable、ClusterMemberState等事件来感知其他节点的上下线,用Akka Actor实现节点间的消息通信。
二、Broker服务框架
百度Broker抽象了很多服务包括:
(1)Authentication Service、Authorization Service
MQTT的CONNECT阶段提供username和password,Broker可以用这些数据对客户端身份进行校验,我们称为验证(Authentication,AE);MQTT的PUBLISH、SUBSCRIBE阶段,需要对客户端订阅主题、发布主题进行权限控制,比如只能订阅含有自己DeviceID的主题,避免客户端订阅他人的主题窃听信息,我们称为鉴权(Authorization,AO)。
百度Broker提供用户名、密码的认证,以及每个客户端对哪些主题可读、可写。实现上,数据全保存在Mysql,通过内存或Redis做Cache加速,Cache回收策略为LRU。
百度这样的做法只适合于固定权限的控制,比如设备拥有的权限几乎相同,而且都是订阅格式相似的主题,只有其中的clientID不同而已,就可以做。如果有权限动态变化、设备粒度划分更细致的情况,采用Mysql+Redis就行不通了。
(2)Session Manager
MQTT定义了两种会话:持久会话(Persistent Session)、非持久会话(Transient Session)。持久会话在客户端断开重连后,之前的订阅数据、离线期间接收的消息依然存在;非持久会话断开连接就清空所有数据。对分布式Broker而言,如何实现持久会话就是一个难点。百度Broker的策略是,持久会话每个Broker都会同步一份,即使Broker宕机,其他Broker上也有相应的信息,以解决高可用问题;非持久会话放在内存里,只在连接的Broker上存在,连接断开或Broker崩溃后清空。
文中没有提到如何解决跨区问题(跨区时延高容易掉线,最好不做集群而是做数据同步,多个区域的Broker Session应该如何同步),以及Session每个节点都同步一份导致内存随设备数量线性增长的问题。
(3)Event Service
负责将每个Broker上发生的连接事件、断开连接事件、订阅事件、取消订阅事件通过Event Service发送给每个Broker,以达到同步的目的,类似于消息总线。实现上采用的Kafka,没有采用Akka通信的原因是这些事件需要持久化,比如Broker崩溃、网络波动后之前发送的未被消费的事件还存在。
文中没有提到订阅事件、取消订阅事件如何处理顺序消费的问题,因为订阅和取消订阅先后顺序会影响Session的同步,比如同一个主题,客户端取消订阅事件先于订阅事件被消费,会导致一直订阅着某个主题;相反订阅事件先于取消订阅事件,会导致订阅丢失。通过kafka的方式,如果用了重试策略保证可靠性,就可能导致这些问题。虽然客户端订阅后马上取消订阅这种情况几乎不存在,都是上线后订阅、下线前取消订阅。
(4)Session State Metadata Service
负责持久化Session元数据,它从Event Service接收数据,然后决定哪些数据需要持久化到Hbase存储,比如持久会话的订阅、取消订阅数据。
(5)Queue Service
管理和分配Queue。根据Session类型不同,分为持久队列(Persistent Queue)、非持久队列(Transient Queue),用于消息下发和离线消息存储。Persistent Queue基于Hbase实现,Transient Queue是内存实现。
(6)Quota Service
管理并发连接数、上行带宽、下行带宽限制。
(7)Metric Service
监控并发连接数、并发消息数、当前流量、服务运行指标(CPU、内存、网络吞吐)
三、连接层
百度的连接层编解码架构如下:
百度Broker连接层采用Netty NIO框架,目前大多数MQTT Broker也都是这样做的,没有任何问题。提供四种基本方式:MQTT TCP、MQTT TCP+TLS、MQTT Websocket、MQTT Websocket+TLS。现在SSL大多指代TLS,SSL是早期版本(现在很多组件已经弃用),后来都升级到TLS了,TLSv1/1.1/1.2/1.3是目前最常用的版本,很多组件原生支持TLS全版本,所以开发很简单不必担心,可以参考开源Broker Moquette。而且我们经常会使用负载均衡器LB来终结SSL,终结的意思是LB对外提供SSL的接口,转发进来的数据都是TCP了,EMQ也推荐使用这种方式,经历过云平台搭建的大佬们也都推荐使用这种方式,因为SSL编解码会消耗CPU,由LB来做完SSL处理,前端连接机器负载会小很多,连接就会更稳定不容易崩溃。所以最后只要做TCP、Websocket两种方式就好了。MQTT Websocket指的是,将MQTT协议作为subprotocol,利用Websocket来透传MQTT协议数据。
四、持久化Session的处理方式
持久化Session,需要同步Session信息到每台机器,每台机器都有全局Session(相当于无状态)。当Broker宕机时,Session中的订阅数据依然存在,所以可以由其他Broker将Publish消息作为离线消息存入客户端在HBase对应的队列中去;当客户端从其他Broker重连时,Session的数据还在、HBase保留了掉线期间的全部消息并会在CONNECT阶段下发给客户端,客户端不会丢失任何信息。
4.1 连接阶段和虚拟队列
连接阶段没有相应的描述,这一段只是推测,流程图如下:
(1)客户端以持久Session向连接节点Broker1发起MQTT-CONNECT请求,请求连接
(2)Broker1接收请求,产生连接事件,发往Event Service
(3)Event Service(Broker1上的)将订阅事件发布到Kafka
(4)Event Service(多个Broker上的)从Kafka消费订阅事件消息
(5)Event Service(多个Broker上的)将消息分发给各自的Broker
(6)每个Broker都会创建对应的Session,包含了连接信息
(7)其他节点往连接节点Broker1发一个内部通信消息,表明连接结果
(8)连接节点Broker1综合连接结果,下发CONNACK给客户端,连接阶段结束
4.2 订阅消息流程
订阅主题的事件消息会发往Event Service,每个Broker都会订阅Event Service的数据,对于持久化Session,在接收到订阅事件后,会创建对应Session的订阅信息。也就是说,每个客户端产生的订阅、取消订阅操作,会被广播给所有Broker节点,Broker接收到后对内部的订阅树、Session等数据结构进行增删,保持订阅信息的一致性。
订阅的流程图如下:
(1)客户端以持久Session向连接节点Broker1发起MQTT-SUBSCRIBE请求,请求订阅主题
(2)Broker1接收请求,产生订阅事件,发往Event Service
(3)Event Service将订阅事件发布到Kafka
(4)Event Service(多个Broker上的)从Kafka消费订阅事件消息
(5)Event Service(多个Broker上的)将消息分发给Broker
(6)每个Broker都会创建对应的Session,记录这个客户端的订阅信息
(7)其他节点往连接节点Broker1发一个内部通信消息,表明订阅结果
(8)连接节点Broker1综合订阅结果,下发SUBACK给客户端,订阅结束
这里提到了一个虚拟队列(Virtual Queue)的概念。我们都知道MQTT要求持久化Session要缓存离线消息和未确认的QoS1消息,常用的做法就是把这些消息放到一个队列里面。对于单点而言,只需要放到内存就可以了,因为客户端只会连接一个节点;对于分布式而言,由于客户端可能会切换节点,放到一台机器的内存里在另一台机器上就无法访问了,百度采用了通用的分布式系统处理数据一致性的方案:计算和存储分离——将存储层单独做成一个集群,计算层做一个“虚拟队列”,只记录队列的状态,当需要获取数据时就利用这些“队列元数据”去存储层获取,保证无论在哪个节点上线,都可以获取到数据。
做队列存储的难点在于,目前并没有组件直接提供所需队列功能。第一个肯定会想到使用消息队列(Message Queue, MQ),但是分析下需求,我们需要海量的(和客户端同数量级)、较小的(每个队列可能最多100条消息)队列,目前类似Kafka这样的MQ,都是少量的(Kafka上百个Topic就会速度慢下来)、海量的(囤积大量待消费消息)队列,所以根本不符合需求。第二个想到的就是Redis,像Redisson这样的工具提供了队列的功能,实现上是将Lua脚本发送给Redis执行来实现队列的功能,但Redis用的是内存比较贵,并且Redis更适合做缓存而不是持久化存储。第三个就是自己研发了,有大佬自己基于RocketMQ研发了海量小消息队列,而百度是基于HBase数据库做的海量小消息队列,阿里也有一个基于HBase制作的HQueue,不过是收费的不开源。有关百度HBase队列实现细节将在后面叙述。
4.3 接收消息流程
接收消息的流程图如下:
(1)客户端2发布一条消息给Broker2(不考虑QoS,因为QoS0也是可以这样操作的)
(2)Broker2拥有全局Session,发现客户端1订阅了这个主题,因此将消息写入客户端1的虚拟队列
(3)Broker2向Broker1发送一个通知(Notification)消息,告诉它有新消息可以消费了
(4)Broker2从虚拟队列读出数据,然后发布给客户端1,发布-接收流程结束
我们分析一下宕机高可用的原理。当Broker2因为进程挂掉、掉电、网络波动等等宕机了造成客户端1掉线,Broker2会继续往HBase写客户端1待消费消息,HBase是集群因此高可用;等到客户端1从Broker3重新连接,然后在CONNECT阶段触发离线消息推送,一样可以接收到全集信息,本应该收到的数据并不会减少,如下图所示。
同时我们可以推测百度QoS1的收发实现,一定是写入HBase成功以后,再回复PUBACK;一定是下发消息成功(收到PUBACK)以后,再删除HBase的数据。
五、非持久化Session的处理方式
5.1 连接阶段
连接阶段没有相应描述,推测会在连接节点Broker上创建连接信息,但并不会同步给其他节点:
5.2 订阅消息流程
订阅消息没有相应描述,推测:同样会利用Kafka进行订阅事件分发消费(更新订阅树),因为其他节点需要知道这个Broker上有客户端订阅了某个主题
但只在连接节点Broker上创建Session记录订阅信息和虚拟队列(更新Session),并且虚拟队列直接用内存来做,因为非持久化Session离线后不需要保存
5.3 发送消息流程
订阅消息描述不清晰,推测流程图如下:
(1)客户端2发送一条消息给Broker2
(2)Broker2发现Broker1上有订阅者,因此将消息直接发给Broker1
(3)Broker1发现客户端1订阅了这个主题,将数据写入对应内存队列
(4)Broker1向Broker2回送一个Event,表明自己成功收到了数据并处理完毕
(5)Broker1从内存队列读取数据,然后将数据下发给客户端1
六、Event Service的数据压缩
Event Service会将持久化Session相关的数据(连接/断开连接事件、订阅/取消订阅事件)放入Kafka,当一个新的Broker加入集群,首先就要将持久化的Session信息全部加载。如果都是从Kafka主题头部开始消费数据的话,可能会花费很久的时间,因此需要对数据进行压缩。压缩做的事情就是保存这些事件消费后产生的最终效果,举个例子,比如订阅我们用订阅树来存储,如果从头消费,需要一根一根分支去插入、删除,模拟客户端做的操作;如果直接保存最后的订阅树在内存中的结果,这些操作就都可以不做了。消费流程解释得不详细,这里按我的理解和推测来描述,流程图如下:
(1)Broker新上线,从HBase取出压缩的数据,构建初始数据结构
(2)从检查点开始消费Kafka的数据
(3)消费到最新一条后,上线完成,新的Broker和其他Broker没有任何区别
原文中只描述了SUBSCRIBE/UNSUBSCRIBE事件的压缩,我认为CONNECT/DISCCONECT事件的数据也需要进行压缩,压缩原理一致。
七、基于HBase的分布式消息队列
HBase本身不提供Queue的功能,但我们可以利用HBase的特性来实现Virtual Queue的概念。
整体描述:如图所示,有4个客户端,每个客户端对应一个虚拟队列Virtual Queue。我们为每个客户端分配一个唯一的(unique)QueueID,这样每个队列可以用QueueID+单调递增ID来组合成一个唯一的RowKey。为了保证写入的均匀性,避免热点问题,我们设计合理的唯一ID前缀(Prefix)来将这些RowKey均匀地分布到不同的Region。为了实现Queue的功能,我们在HBase上定义一个协处理器(CoProcessor),用作创建Queue、管理Queue的入队出队等操作、删除Queue、修改Queue的配额等等,HBase的Coprocessor类似于Redis的Lua脚本。
7.1 Region Split算法
作用
我们希望所有的Queue能够均匀地分布到各个Region里面去,需要设计一个特殊的前缀作为分割条件(PatitionKey → Region)
名词解释TenantID:百度IoT采用的多租户架构(将在后面叙述),所以有一个TenantID,对于一个企业而言这个ID是常量。
clientID:MQTT协议的clientID,百度用的是单调递增的64bit Long
QueueID:前文提到的一个客户端对应一个队列,用于唯一标记客户端队列的ID
算法流程
(1)定义客户端的QueueID为reverse{clientID}_TenantID,其中reverse的含义是字符串反转。
(2)PartitionKey设定为log2(REGION_NUM),其中REGION_NUM是预期的region数量
算法解析
百度的clientID是系统生成的、单调递增的64位长整型,加入预期region数量为128个的话,可以用前log2(128)=7比特的变化来映射到对应region。但由于数字的前面高位部分变化幅度低(要增长1W个数字万位才会进1),而后面低位数字变化剧烈(每增长1个都会变),我们需要的只是0~127的剧烈变化,所以将clientID进行翻转,取前8bit来做映射。
7.2 保证写入消息的有序性
我们为每个客户端的每条消息都分配一个唯一ID,记为QueueID_ID,其中QueueID为队列ID(
reverse{clientID}_TenantID ),后面的ID为单调递增64位长整型ID。例如一个客户端的消息ID可能是:3134_BAIDU_234,代表BAIDU这个租户下的第3134个客户端的第234条消息。
消息都是批量(batch)写入的,当批量写入Coprocessor后,先获取该Queue的锁,然后分配ID,再将数据写入HBase,最后释放锁。这里的锁粒度是Queue级别(客户端级别),可以保证多个Broker并发写入一个客户端的Queue时不会发生冲突。
7.3 读取Queue数据
我们会为每个Queue保存该Queue在HBase的最小ID、最大ID,如果该Queue的最小最大ID在内存缓存中过期或丢失(比如很久没有读写队列消息了),就通过HBase的scan操作来重新获取一次最小最大ID,再缓存在Cache里。每一次读取特定长度的数据,保证每次数据的量级不会太大。读取的时候并不需要锁,因为读取只可能是客户端自己在读取,任何时刻读请求只可能来自一台机器的一个客户端。
7.4 删除Queue的数据
对于已经读取的数据,需要删除掉。由于我们的数据都是有序的,所以删除的时候只需要告诉Coprocessor删除多长的数据,然后根据最小ID、offset可以计算出要删除的RowKey,然后执行batch delete即可。删除同样不需要锁,任何时刻删除请求只可能来自一台机器的一个客户端。
7.5 HBase的使用考虑
由于HBase不存在官方的异步读写库(async library),目前只有openTSDB提供一个版本,而百度IoT利用coprocessor增加了一个新的endpoint,openTSDB的asnyc library却并不支持coprocessor,所以百度IoT自己扩展了async的库,最终用的自己研发的asnyc library的coprocessor库处理数据。
同时,MQTT的消息属于快速消费(short lived)的消息,基本上写入后会被立刻读出,所以百度做了2.0版本,做内存压缩(in memory compaction),不需要将数据写入HFile,只需要写WAL日志,这样可以极大的降低HDFS文件系统的IO,解决了HDFS文件系统瓶颈问题,不过这个版本还没有正式发布。
相关参考资料:
7.6 提供多种Queue的选择
基于HBase的这种Queue更适合小型客户端,比如APP、嵌入式IoT设备等等,对于大规模扇入场景,例如有一个后端服务需要统计数据,要求100W设备都往同一个主题发送消息,基于HBase的Queue只能有一个TCP来处理数据,后端服务肯定处理不过来会有大量消息堆积。所以百度还推荐使用Kafka来应对这种情况,将数据发往Kafka主题,然后利用Kafka的负载均衡客户端来并发消费消息。除了HBase、Kafka、内存,百度IoT还提供Redis做Queue。
八、多租户架构
百度是一个大平台,肯定不止为一家公司服务,所以用多租户架构来提供IoT Broker功能。
一个IoT Hub上会有很多租户的MQTT Broker, 每个Broker对应一个tenant,每个Broker都有自己的Authentication Service, Session manager, Queue Service,以及很多其他的公共服务,比如Unique Id Generator,Backend Sorage Service等等。当客户端通过MQTT/TCP建立连接,云端通过username来区分对应哪个tenant,因此要求username必须为{tenent Name}/{client Name},取出username、password之后,先算出对应client的tenant name,然后拿到该tanent对应的Broker实例,调用该Broker的Auth Service验证客户端身份。
九、Baidu IoT Hub vs EMQ官方测试结果
1、测试信息
(1)测试机配置:配置参数值
Vender IDGenuine Intel
CPU Family6
Model45
Model NameIntel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz
核心数12
内存大小132137288KB(约126GB)
(2)测试场景:一半PUBLISH和一半SUBSCRIBE,每一个pub对应一个sub,也就是说通过唯一主题关联起来,这种场景是对MQTT协议最严格的考验,其他场景相对来说CPU消耗会少一些
(3)消息Payload大小:1024B(1KB)
(4)Queue类型:内存Queue(因为EMQ只有内存Queue)
文中并没有提到EMQ的版本。
2、测试结果
MPS:message per seconds,每秒消息量。由于Pub和Sub是一一对应的,所以这里指的消息量是PUBLISH的QPS,总体QPS是这个值的2倍。产品连接数预期MPS实际MPS平均CPU IDEL平均时延(ms)丢失率
百度50万20K19.2K34%3830%
EMQ50万20K19.2K26%18210%
百度50万10K9.2K58%2890%
EMQ50万10K9.2K44%2810%
百度20万50K42.5K14%3810.0000314%
EMQ20万N/A测试未返回
百度20万40K39.7K19%4090%
EMQ20万40K38.4K10%174560.0349%
百度20万20K19.7K37%1520%
EMQ10万20K19.7K33%4490%
百度10万50K48.9K13%3150.000272%
EMQ10万50K31.7K11%80140%
百度10万40K39.7K19%2090%
EMQ10万40K31.7K11%80140%
百度10万30K29.9K26%1520%
EMQ10万30K29.9K19%27270%
百度10万30K19.8K37%1130%可用MPS对比(无丢包、时延小于0.5s)
连接数百度可用MPSEMQ可用MPS
10万40K(19%IDLE)20K(24%IDLE)
20万40K(19%IDLE)20K(33%IDLE)
50万20K10K
3、官方测试结论
同等连接数下,百度Broker的可用最大吞吐量在EMQ的1~2倍之间。
十、总结
目前很多公司产品经理提的需求动不动就要支持上千万的IoT设备,肯定是要采用类似百度Broker的设计架构。但百度IoT只有这一篇文章,其中的很多细节依然不清楚,并且有自研成分在里面,小公司的普通开发者根本无法参考,所以只是提供了一个思路。MQTT Broker的难点就在于,它有持久Session,前端的连接节点无法做到无状态,会产生两个核心问题:离线消息如何存储和分发、集群如何通信,百度给出的答案是,自研基于HBase的Queue存储离线消息,使用对等节点Akka Cluster做集群通信(然而没有考虑可用区分区的问题,也没有细讲订阅数据同步)。希望以后越来越多的大公司可以开源讲一讲MQTT Broker的思路。