FlowMQ 技术架构分析与推测

本文所有分析均为基于 FlowMQ 公开文档的技术推理和个人思考，不代表 FlowMQ 实际实现，不保证准确性，不构成对 EMQ 或 FlowMQ 的任何贬低。仅供技术交流和学习参考，欢迎指正。

背景

2026 年 3 月 20 日，EMQ 在 Tech Day 上正式发布了 FlowMQ，定位为"新一代融合消息流平台"。FlowMQ 在一个系统内提供 Subscription（实时推送）、Stream（数据流）和 Queue（队列）三种消息能力，原生支持 MQTT、Kafka、AMQP 多协议接入和跨协议互通。

关于 FlowMQ 的技术来源，有以下公开线索可供参考：

• HStreamDB 官网 hstream.io 已 301 重定向至 flowmq.io
• GitHub 上 flowmq-io 组织 fork 了 FoundationDB（C++）、Bento（Go）和 Paho MQTT Testing 等项目
• EMQ 创始人 Feng Lee 的 GitHub 上有一个名为 flowmq 的早期仓库，描述为 "An experimental MQTT broker written in C++"
• EMQ GitHub 上的 FlowSDK 描述为 "A safety-first, behavior-predictable MQTT 5.0 SDK written in Rust"

EMQ 官方未公开确认 FlowMQ 与 HStreamDB 的关系，也未公开 FlowMQ Broker 的实现语言。FlowMQ 可能继承了 HStreamDB 的部分架构理念，也可能是全新实现，具体细节无法从外部确认。

以下所有分析均基于 FlowMQ 公开文档和逻辑推理展开。

一、产品定位演变

HStreamDB 于 2021 年开源，用 Haskell 编写，定位为"流数据库"，主打流数据的存储与实时处理，以 SQL 为主要接口。项目停留在 v0.14，社区活跃度较低。

FlowMQ 的定位发生了根本转变：从"流数据库"转向"统一消息平台"。核心叙事变为用一个系统替代企业内部分散的 MQTT Broker、Kafka 集群和 RabbitMQ 实例，消除桥接程序和重复运维。

与此同时，EMQX 从 v5.9.0 开始将社区版和企业版合并，协议从 Apache 2.0 改为 BSL 1.1，EMQX 5.8 开源版已于 2026 年 2 月底停止维护。EMQ 全线产品不再是传统意义上的开源。

二、整体架构推测

根据公开文档，FlowMQ 的架构可以分为四层：协议适配层、路由引擎、Destination 层、存储层。以下是基于公开信息推测的整体架构图和路由引擎内部逻辑图。

整体架构图（推测）

路由引擎内部逻辑（推测）

2.1 协议适配层

每种协议对应一个独立适配器，负责将外部协议消息翻译为内部统一格式，并将协议中的地址映射为 FlowMQ 内部 Topic：

• MQTT topic 直接映射
• Kafka topic 的 . 自动转为 /
• AMQP 的 message key 映射为 Topic

适配器可插拔，新增协议只需新增适配器。部署配置支持按协议角色独立伸缩，通过 mqtt-num 和 kafka-num 分别控制实例数量，可在同一台机器混合部署不同角色。

2.2 路由引擎

路由引擎是架构的核心中枢，负责将消息的 Topic 与所有 Destination 注册的 Topic Filter 进行匹配（支持 + 和 # 通配符），命中则投递。

路由引擎完全协议无关，不区分消息来源协议。跨协议互通在这一层自然发生。

如果一条消息同时命中多个 Destination（例如同时命中一个 Subscription 和一个 Stream），消息会被复制分发到每一个，产生写放大。

2.3 Destination 层

三种 Destination 类型对应三种消息语义：

Subscription：消息到达后立即推送给在线订阅者，不经过持久化。从监控指标看，Subscription 走内存直推，延迟最低。

Stream：消息以 append-only log 形式持久化到 S3 对象存储，支持分区、offset 消费和历史回放，完全兼容 Kafka 协议。Stream 支持绑定 Topic Filter 自动捕获匹配消息。从监控指标的 kas3_ 前缀推测，底层有 KaS3 模块专门管理 page cache、segment、compaction 和 retention。

Queue：竞争消费，ACK 确认后删除。Queue 的数据存储细节文档未明确，推测存储在 FoundationDB 中。

文档提到 Destination 设计支持扩展，未来会引入 Table 等新类型。

2.4 集群管理

从监控指标确认，FlowMQ 使用 Gossip 协议做节点发现和事件广播，Anti-Entropy 机制做定期状态同步和修复：

• gossip_cluster_size：集群节点数
• gossip_events_originated_count：本节点产生的事件数
• gossip_event_propagation_hops_count：事件传播跳数
• anti_entropy_syncs_completed_count：同步成功次数
• anti_entropy_missing_events_detected_count：检测到的缺失事件数

Broker 节点无状态，可秒级扩缩容、快速故障替换，无需 rebalance。

2.5 元数据交互

推测 Broker 与 FoundationDB 的交互模式为：

• 启动时从 FoundationDB 拉取全量元数据（路由表、Destination 配置、Namespace 等），加载到本地内存
• 路由匹配全在内存完成，不会每条消息查询 FoundationDB
• 运行时元数据变更写入 FoundationDB 作为 source of truth，通过 Gossip 广播给所有节点更新内存缓存
• Anti-Entropy 定期全量对账，修复 Gossip 漏掉的变更
• Consumer offset 等高频更新在内存做 checkpoint，定期批量刷到 FoundationDB

2.6 存储层

FoundationDB：部署配置中直接使用 fdbserver、fdb.cluster、fdbcli 等原生工具，安装包名为 flowmq-meta。承担路由表、Destination 配置、订阅关系、Consumer Offset、Namespace 隔离等元数据存储，推测也存储 Queue 数据和 S3 索引数据。

S3 对象存储：部署配置中 S3 参数仅在 Kafka 功能开启时需要配置，说明 Stream 数据存 S3，Subscription 不经过 S3。支持 AWS S3、阿里云 OSS、Ceph、MinIO 等。

三、跨协议互通机制

以 MQTT → Kafka 为例：

1. IoT 设备通过 MQTT publish 消息到 sensors/device-001/telemetry
2. MQTT 适配器直接映射为 FlowMQ Topic
3. 路由引擎匹配到某个 Stream 绑定的 Topic Filter sensors/+/telemetry
4. 消息写入 Stream，持久化到 S3
5. Kafka consumer 从该 Stream 按 offset 消费，Topic 名自动映射为 sensors.device-001.telemetry

反向 Kafka → MQTT：

1. 后端通过 Kafka producer 写入 commands.broadcast
2. 适配器将 . 转 /，映射为 Topic commands/broadcast
3. 路由引擎匹配到 Subscription 的 Topic Filter commands/#
4. 消息直接内存推送给在线 MQTT 订阅者，不落盘

核心机制是路由引擎做分发，不是不同协议读写同一份数据。一条消息如果同时命中 Subscription 和 Stream，会被处理两次。

四、技术选型分析

FoundationDB 的选择

强一致性事务天然适合元数据管理，不需要自己实现 Raft/Paxos，Apple 大规模生产验证。代价是引入了需要独立运维的分布式集群。

S3 对象存储的选择

存储单价远低于块存储，容量按需扩展，持久性由云厂商保证。Broker 无状态可秒级扩缩容。与 AutoMQ、WarpStream 思路一致。

实现语言

无法确认。已知线索：创始人 GitHub 有早期 C++ 实验仓库，HStreamDB 为 Haskell，FlowSDK 为 Rust，FoundationDB 为 C++。正式产品代码未公开，不宜从早期信息下定论。

五、架构优缺点

优点

• 协议、路由、存储三层解耦彻底，扩展性好
• Broker 无状态 + 对象存储，弹性伸缩能力强
• MQTT 和 Kafka 实例可按角色独立伸缩
• 跨协议互通开箱即用，不需要桥接程序
• Gossip + Anti-Entropy 集群管理不依赖额外协调服务

缺点

• 一条消息命中多个 Destination 产生写放大
• 部署至少需要 FoundationDB 集群 + S3 + FlowMQ Broker 三套组件
• 强依赖 FoundationDB 和 S3，故障域扩大
• Kafka 的 . 和 MQTT 的 / 自动互转为硬编码规则，存在映射冲突风险
• 闭源商业产品，存在厂商锁定风险

六、进一步思考

以下为个人技术观点和推测，不代表对 FlowMQ 或 EMQ 的贬低。技术架构的取舍没有绝对对错，不同设计服务于不同约束和目标。欢迎技术交流讨论。以下观点都是基于我推论的架构来的。如果推论的前提错误，那么下面的观点也会是错误。

6.1 外部依赖与故障域

消息系统是基础设施的基础设施，自身依赖链越短、可控性越强越好。FlowMQ 强依赖 FoundationDB + S3，故障域从自身扩展到两个外部系统。Kafka 去 ZooKeeper、Pulsar 受困于 BookKeeper 的历史已经反复验证：消息系统的外部依赖是真实的架构风险，不仅仅是运维成本问题。

6.2 路由引擎与存储统一

路由引擎的存在说明 Subscription、Stream、Queue 底层并非同一份存储，才需要路由层做分发复制。如果底层是统一的存储模型，消息写一次就够了，不同消费者用不同读取视角消费同一份数据，不需要任何中间分发逻辑。

多协议统一的终极目标应该是"一份存储，多种消费视角"，而不是"一份消息，路由引擎复制成多份，再分别消费"。

6.3 前置规划与写放大

FlowMQ 要求用户提前规划 Destination 并绑定 Topic Filter。需求变化时新增 Destination 就多写一份，写放大随 Destination 数量增长。统一存储架构下，消费需求的变化不应影响写入链路，用户不需要提前做消费路径的规划。

6.4 组合式架构的天花板

FlowMQ 将核心存储交给 FoundationDB 和 S3，自身掌控的是协议适配和路由分发。随着产品演进（Queue 需要 ACK 删除和重试、未来 Table 需要查询更新），FoundationDB 大概率从纯元数据存储逐步承担更多业务数据，角色越来越重，系统对 FoundationDB 的依赖和性能压力都会加大。

消息系统的存储层是核心竞争力所在。用外部通用分布式 KV 做存储，工程上简单，但长期限制了针对消息场景的极致优化空间。基础软件领域的各种组件已经足够成熟，新一代消息引擎应该去解决更根本的问题——统一的存储模型，而不是再做一次组件组合。

七、总结

FlowMQ 的架构从工程交付的角度看是合理的。EMQ 有十年的 MQTT 经验和成熟的企业客户基础，这套架构能快速出产品、能跑起来、能卖钱。选这条路对他们来说是当前阶段的最优解。

但从个人技术理念的角度，有几点不同看法：

• 关于整体架构：架构分层清晰、解耦彻底，这些都是优点。但与我追求的高内聚理念不太一致。S3 作为存储选项之一是合理的，但不应该成为存储的主引擎。消息系统的存储层应该由自身掌控，对象存储可以作为冷数据归档或长期留存的补充手段，而不是核心数据路径的基座。

• 关于 FoundationDB 的选型：不好说是对还是错。FoundationDB 本身是优秀的分布式 KV 存储，用它做元数据管理在工程上省了大量工作。但我个人不希望在消息系统中引入一个新的外部分布式组件——核心存储层应该自己掌控，这样才有极致的优化空间和完全的可控性。

• 关于 Destination 设计：这是我最不认可的部分。路由引擎将消息复制分发到多个 Destination，本质上是多份数据。我认为更合理的方向是一份数据、多个消费视图——数据只写一次，不同协议的消费者用不同的读取语义消费同一份数据。消费需求的变化不应该影响写入链路，也不应该产生额外的存储成本。（这点也有可能是我理解错了，如果是一份数据，就没有这个问题）

• 关于 FoundationDB 的长期风险：FoundationDB 是否会成为 Kafka 的 ZooKeeper、Pulsar 的 ZooKeeper 和 BookKeeper 那样的历史包袱，目前犹未可知。但消息系统领域的历史经验已经反复证明，外部重依赖是一个需要长期警惕的架构风险。

以上均为个人技术观点，不代表对 FlowMQ 或 EMQ 的否定。不同的设计选择服务于不同的约束和目标，FlowMQ 的架构在 EMQ 的商业场景下完全说得通。技术路线没有绝对的对错，最终由市场和用户来检验。欢迎交流讨论。

• FlowMQ 产品概述
• FlowMQ 核心特性
• FlowMQ 基本概念
• FlowMQ 消息路由
• FlowMQ 跨协议互通
• FlowMQ 数据流
• FlowMQ 集群部署
• FlowMQ 指标监控
• FlowMQ 官网
• FlowMQ 发布博客
• EMQX 切换 BSL 公告
• HStreamDB GitHub
• flowmq-io GitHub
• EMQ 创始人 GitHub

免责声明

本文所有架构分析和技术推测均基于 FlowMQ 公开文档、官网信息、GitHub 公开仓库等公开信息进行的逻辑推理，不代表 EMQ 官方的技术实现细节，不保证与 FlowMQ 实际架构完全一致。FlowMQ 为闭源商业产品，内部实现细节无法从外部完全确认。本文仅供技术交流和学习参考，不构成对任何产品或团队的贬低。如有偏差，欢迎指正。