集群部署

FlowMQ Enterprise 采用 无状态 Broker + 对象存储持久化 的架构。在集群层面，这带来与传统有状态分区系统显著不同的特性：扩缩容更快、恢复更可控、无需 Rebalance。

集群目标

• 高可用：节点故障不影响整体服务
• 弹性扩展：随业务增长平滑提升吞吐与连接能力
• 多租户治理：资源隔离与配额边界清晰
• 可运维：升级、回滚与故障处置流程标准化

典型架构建议

1) 计算层：无状态 Broker

• 部署多个 Broker 实例，前置负载均衡（L4/L7 视协议而定）
• 使用健康检查与自动替换实现自愈
• 扩容即增加实例，缩容即减少实例（配合连接迁移/重连策略）

2) 存储层：对象存储（S3）

• 对象存储承载持久化数据与保留
• 合理设置 Bucket、权限、生命周期与访问策略

3) 控制面与元数据

• 多租户（Namespace）、主题、ACL、配额等属于平台元数据
• 建议将元数据管理纳入备份与审计体系

多 AZ / 多机房考虑

FlowMQ 在成本上的一个重要优势来自：

• 避免不必要的跨 AZ 复制流量
• 降低客户端与 Broker 的跨 AZ 访问

在设计多 AZ 时建议：

• 将入口（LB）与 Broker 在同一 AZ 就近调度
• 对象存储使用区域级服务
• 以业务 SLA 为导向设定故障域与演练策略

扩缩容与升级

• 扩缩容：无状态 Broker 可实现秒级扩缩容；无需等待分区再平衡
• 升级：推荐滚动升级，逐批替换 Broker 实例

延迟权衡

基于对象存储持久化带来的典型权衡是更高的延迟：

• 发布平均延迟约 500ms，P99 约 1s
• 端到端平均约 700ms，P99 约 1.5s

如果业务可接受约 1 秒级延迟，FlowMQ 在成本与运维上通常“全是优势”。如需更低延迟，可优先使用 MQTT 等协议通道并结合业务侧优化。