Meta Service 系统架构
Meta Service 是 RobustMQ 内置的元数据存储组件，其作用类似于 Zookeeper 之于 Kafka、NameServer 之于 RocketMQ。该组件负责 RobustMQ 集群的协调、节点发现、元数据存储以及部分 KV 型业务数据的存储。
从功能角度而言，Meta Service 涵盖以下几个方面的工作：
- 集群协调：负责集群组建、节点发现与探活、节点间数据分发等集群协调工作。
- 元数据存储：负责集群相关以及消息队列各种协议相关的元数据的持久化存储，例如 Broker 信息、Topic 信息、连接器信息等。
- KV 型业务数据存储：在消息队列运行过程中，存在部分运行相关的数据需要持久化存储，例如 MQTT 的 Session 数据、保留消息、遗嘱消息数据等。由于这些数据的规模可预见，Meta Service 同样负责这部分数据的存储。
- 控制器：负责集群间的调度工作，例如节点故障切换、Connector 任务调度等。
因此，Meta Service 在 RobustMQ 中承担了诸多职责。相比之下，Zookeeper 对于 Kafka 而言仅负责元数据存储和集群协调。采用这种设计的原因在于，Meta Service 作为自研内置组件，旨在实现计算、存储、协调三层完全分离的架构。
系统架构
如上图所示，从技术角度分析，Meta Service 的技术核心为：gRPC + Multi Raft + RocksDB。
Meta Node 之间通过 gRPC 协议进行通信，对外同样通过 gRPC 提供服务。节点间的数据一致性由 Raft 协议保证。为提升 Meta Service 的性能，系统采用 Multi Raft 架构，即在 Meta Service 集群内运行多个 Raft 状态机，根据不同需求使用相应的状态机。目前支持 Metadata RaftMachine、Offset RaftMachine、Data RaftMachine 三种状态机。
Meta Service 的数据通过 RocksDB 进行持久化存储。具体而言，当写入数据时，数据会通过 Raft Machine 分发到多个节点，节点接收数据后将其写入 RocksDB。此外，Raft 状态机的数据和日志同样持久化存储于 RocksDB 中。
当 Meta Service 启动时，系统会按照 Raft 协议规定的流程完成集群组建，并通过投票选举出 Leader。同时，在 Metadata RaftMachine 的 Leader 节点中启动控制器线程，执行集群调度和管理功能（例如 MQTT Connector 的调度和管理）。
关于性能
Meta Service 的核心要求是性能。业界部分元数据协调服务，例如 ZooKeeper、etcd 等，都会受限于性能和内存使用量，进而导致性能问题。ZooKeeper 主要受限于单 Leader 架构瓶颈，此外其将所有数据存储在内存中的设计也导致了数据容量的限制。同样地，etcd 也存在单 Raft 架构的瓶颈，虽然 etcd 的容量相比 ZooKeeper 更大，但仍存在限制。
从架构角度来看，Meta Service 长期将承载包括数据存储在内的多种功能，本质上它是一个元数据协调服务与 KV 存储引擎的结合体。因此，在设计上就避免了单 Raft 和内存容量限制的问题。
系统通过 Multi Raft 机制支持多个 Raft 状态机。虽然当前仅部署 3 个状态机，但从设计角度而言，可以根据需要扩展状态机的数量。例如，当元数据过多或 Offset 提交频繁时，可以将 Metadata RaftMachine 和 Offset RaftMachine 的数量从 1 个扩展到 2 个或更多，从而实现多个 Leader 并行提供服务，提升并行处理性能。
此外，系统通过 RocksDB 存储 KV 型数据，充分利用 RocksDB 的优势来提升读写性能。在这种设计下，系统会严格控制内存的使用，仅将部分热数据存储在内存中，部分数据甚至不经过内存缓存，直接读写 RocksDB。虽然这会牺牲部分性能，但可以有效应对百万甚至千万级 Topic 等元数据量激增的场景。在 MQTT 场景下，当存在亿级连接时，相应的亿级 Session 数据也不会占用大量内存。
由此可见，自定义实现内置的元数据协调服务具有显著优势，能够针对消息队列的特殊场景进行深度优化，在性能、功能、稳定性等方面实现极致优化，这是通用组件无法满足的。这也是当前众多组件去 ZooKeeper 化、去 etcd 化的原因，同样也是 RobustMQ 自定义实现 Meta Service 的核心动机。
关于网络层
从长期来看，Meta Service 的性能瓶颈可能出现在网络层。理论上 gRPC 协议性能表现优秀，但在某些极端场景下可能面临挑战。例如，当 MQTT 集群重启服务，上亿级连接同时发起连接时，Broker 可能对 Meta Service 发起高频访问，此时最容易出现 Meta Service 的性能瓶颈。为应对这种场景，系统采用以下两种优化思路：
- Batch 语义
- 替换 gRPC
Batch 语义是指在某些操作中支持批量处理，例如在创建/更新 Session 信息时，允许 Broker 调用 Meta Service 一次性创建/更新多个 Session，从而降低 Broker 调用 Meta Service 的频次。
从长期规划来看，如果 gRPC 确实成为瓶颈，则需要考虑替换协议，改用 TCP 或 QUIC。从技术角度分析，在内网稳定的数据传输链路中，TCP 的性能和表现优于 QUIC；而在跨分区、跨地域部署等网络条件较差的场景下，QUIC 的表现则优于 TCP。因此，长期来看存在替换 gRPC 的可能性，但短期内暂无此计划。
总结
综上所述，Meta Service 是一个通过 gRPC + Multi Raft + RocksDB + Batch 语义构建的、针对 RobustMQ 架构高度优化和适配的元数据存储服务与 KV 存储引擎。