StarRocks FE如何发现并管理BE节点？

Question

在StarRocks集群中，FE（Frontend）如何自动发现并管理BE（Backend）节点？当BE节点启动后，如何注册到FE？FE通过何种机制感知BE的存活状态？心跳机制的频率与超时策略是怎样的？若BE宕机，FE如何判断并将其标记为不可用？又如何在BE恢复后重新纳入管理？这些问题涉及元数据同步、心跳检测、集群扩容与容错机制，是运维和调优StarRocks集群的关键所在。

Answer 1

一、FE与BE节点的自动发现与注册机制

在StarRocks集群架构中，Frontend（FE）作为元数据管理与查询调度的核心组件，负责协调Backend（BE）节点的工作。BE节点的加入并非依赖静态配置文件硬编码，而是通过动态注册机制完成。

1. 当一个BE节点启动时，它会读取配置文件中的fe_host参数，该参数指定了至少一个FE Leader或Follower的地址。
2. BE通过HTTP协议向指定的FE节点发送注册请求（Register Request），携带自身IP、端口、硬件信息（如磁盘容量、内存）、版本号等元数据。
3. FE接收到请求后，验证BE身份合法性（例如检查是否已存在相同HostPort的BE），并通过元数据日志（Journal）持久化该BE信息。
4. 注册成功后，FE将BE纳入集群拓扑结构，并广播给其他FE节点以实现元数据同步。
5. 此过程支持多FE高可用场景下的任意节点接入，确保集群具备良好的弹性扩展能力。

值得注意的是，BE并不需要预先在FE侧手动添加；只要网络可达且认证通过，即可实现“即插即用”式扩容。

步骤	通信方式	关键参数	失败处理
1. 启动BE	TCP + HTTP	fe_host, heartbeat_port	重试3次，间隔5秒
2. 发送注册请求	HTTP POST /api/heartbeat	host, port, capacity, version	记录日志并退出进程
3. FE持久化元数据	BDBJE Journal	edit log写入	拒绝注册并返回错误码
4. 广播至其他FE	BDBJE复制	Image + Log Apply	异步重传机制

二、心跳检测机制与存活状态感知

为持续监控BE健康状态，FE与BE之间建立双向心跳通道。该机制是保障集群容错性的核心。

BE节点每隔固定周期向所有FE节点发送心跳包（Heartbeat），默认频率为每1秒一次。心跳内容包括：

• 当前负载（Query数量、IO压力）
• 磁盘使用率
• 内存利用率
• 最后一次GC时间
• 服务端口状态

FE端维护每个BE的最后心跳时间戳。若超过设定阈值未收到心跳，则触发宕机判定逻辑。

// 伪代码：心跳超时判断逻辑
for (Backend be : cluster.getBackends()) {
    long now = System.currentTimeMillis();
    if (now - be.getLastHeartbeatTime() > HEARTBEAT_TIMEOUT_MS) {
        markBackendAsDead(be);
    }
}
    

默认超时时间为5秒（可配置），即连续丢失5个心跳包即视为不可达。

三、宕机识别与恢复再纳管流程

当FE检测到某BE长时间无心跳响应，进入如下判定流程：

1. FE将其状态标记为DEAD，不再参与查询计划分片分配。
2. 元数据更新操作被记录至Journal，确保其他FE节点同步状态变更。
3. 正在运行的查询任务若涉及该BE，由Coordinator触发重试或降级策略。
4. 副本管理系统启动补副本流程，在其他存活BE上重建缺失副本。

一旦原BE节点修复重启，其再次发起注册请求。FE根据以下规则决定是否接受：

判定项	条件	动作
UUID匹配	与历史记录一致	允许重新加入
IP:Port冲突	已被其他BE占用	拒绝注册
版本不兼容	低于最小支持版本	提示升级
磁盘数据校验	元数据损坏	清空本地数据目录

重新注册成功后，FE下发全量或增量元数据同步指令，BE开始加载表副本信息，并逐步参与查询执行。

四、元数据同步与集群一致性保障

FE间的元数据一致性依赖于Berkeley DB Java Edition（BDBJE）构建的Paxos协议组。所有BE注册、心跳、状态变更事件均作为EditLog条目提交至BDBJE。

主要流程如下：

graph TD A[BE启动] --> B{连接FE} B --> C[发送RegisterRequest] C --> D[FE写入EditLog] D --> E[BDBJE复制到多数FE] E --> F[Apply到内存元数据] F --> G[广播心跳接收器列表] G --> H[BE开始发送心跳] H --> I[FE更新last_heartbeat_ms] I --> J{超时?} J -- 是 --> K[标记DEAD] J -- 否 --> H

这种基于Paxos的日志复制机制确保了即使部分FE宕机，集群仍能维持元数据强一致性。

五、运维调优建议与高级配置

针对大规模生产环境，可通过调整以下参数优化BE管理行为：

• heartbeat_interval_seconds：控制BE心跳发送频率，默认1s，过高增加网络开销，过低影响故障发现速度。
• tablet_report_interval_seconds：控制BE上报分片信息周期，影响元数据同步精度。
• dead_backend_err_second：定义心跳超时时长，通常设置为5~10秒。
• max_backend_down_time：容忍宕机最长时间，超过则自动删除该BE及其数据副本。

此外，建议启用Prometheus+Grafana监控体系，采集BE心跳延迟、注册失败率、副本漂移等关键指标，实现可视化告警。