BifroMQ-v2.0.0 发布:支持标准集群模式(StandardCluster)

百度天工 AIoT 团队在 2023 年 7 月正式宣布开源高性能分布式MQTT物联网消息中间件,并将其全新命名为 BifroMQ。历时三个月,BifroMQ-v2.0.0 版本现已发布。

新版本首次支持集群模式,官方将其称为标准集群 StandardCluster(简称 StandardCluster)。主要有以下特性:

StandardCluster 的整体结构

BifroMQ 将逻辑上的 MQTT 功能从负载的角度分解为若干子服务,每个子服务对应一类关键负载:

从部署的角度出发,BifroMQ StandardCluster是将这些独立负载的服务模块"封装"到一个节点服务进程的集群模式,从逻辑上来说,此为 Standalone 运行模式的抽象(BifroMQ Standalone 可以看作是单个节点的 BifroMQ StandardCluster)。与其他支持集群的 MQTT Broker 不同,BifroMQ 内置分布式持久化功能,因此单个 BifroMQ 节点是"有状态的"(Stateful)。

消息分发能力的水平扩展

在 StandardCluster 集群模式下,每个节点进程内的分发负载模块( 简称 Dist Service )构成逻辑上的负载子集群(Dist-SubCluster)。Dist Service 将订阅信息存储在内置的持久化引擎中,并通过持久化引擎的分布式功能在节点之间同步路由信息。公告称,在 StandardCluster 模式下,通过增加节点的方式,即可以实现消息分发能力的水平扩展,特别是在 CleanSession 为 True 的情况下。

离线消息队列的持久化、扩展性及高可靠性

与 Dist Service 模块类似,节点进程内负责 MQTT 持久会话中离线消息队列的 Inbox Service 模块构成了另一个逻辑上的负载子集群(以下简称Inbox-SubCluster)。Inbox Service 将离线队列消息持久化到内置的存储引擎中,可以极大程度地减少因节点故障导致的数据丢失。在存储方面,Inbox Service 利用内置存储引擎的分片功能,在实现存储规模和处理能力水平扩展的同时,通过静态配置或运行时策略动态增加分片的副本数,可以进一步提高离线消息数据的可靠性,这对某些对数据可靠性要求更高的应用场景尤为重要。

Inbox服务的基于负载的拆分策略

如前文所述,在StandardCluster 部署下,单个节点进程内的 Inbox Service 利用了内置存储引擎的分片功能来实现存储规模和处理能力的水平扩展。然而,分片策略对实际运行效果有着决定性的影响。在 BifroMQ StandardCluster 版本中,已内置开箱即用的基于负载的拆分策略(以下简称Load-based Splitting)。该策略通过统计最近一段时间内的负载情况来决定对KV Range的划分,可以视为一种"后验"拆分策略。当使用场景已经对离线消息负载的分布有提前规划和了解时,提前划分 Range 往往能在负载到来时带来更稳定的性能表现,而对于深度使用 BifroMQ 的用户,可以通过 SPI 机制实现此类"先验"拆分策略。

HTTP API 模块

BifroMQ StandardCluster 版本同时引入了 HTTP API 功能,每个集群节点均可通过配置开放 API 访问端口。BifroMQ HTTP API 作为无状态的全局接口,旨在支持业务层面的管理控制逻辑集成,访问任何一个节点的 API 都可以实现对整个集群的操作。

在 StandardCluster 部署下,单个节点具备完整的 MQTT 协议功能,承担各种类型的负载。因此,这种模式非常适用于以下两类企业级应用场景:

BifroMQ 集群建立在一套内置的去中心化技术之上(base-cluster),无需依赖外部节点注册和发现服务。因此,构建 BifroMQ StandardCluster 的部署过程非常简单,只需指定任何一个集群中的节点作为种子节点,即可完成新节点的加入。此外,BifroMQ 还内置了集群分裂后的自愈能力,可以极大地简化出现网络分区(Network Partition)等故障时的运维操作。