EMR Serverless Doris 高可用最佳实践--E-MapReduce-火山引擎

文档中心

立即注册

E-MapReduce

稳定性建设

EMR Serverless Doris 高可用最佳实践

本文介绍 Doris 核心组件——FE 节点与 BE 节点的高可用实现，分别梳理 FE 多场景下的负载均衡方案，以及 BE 基于存算一体架构的高可用能力，为集群稳定运行提供参考。

FE 高可用实践：多场景负载均衡方案

FE 作为 Doris 集群的“入口与调度核心”，高可用需通过负载均衡+故障自动转移实现，具体分为以下三类场景，覆盖从 Serverless 到自定义开发的不同需求：

EMR Serverless Doris 实例：开箱即用的高可用

适用于使用 EMR Serverless 版本 Doris 的场景，无需额外配置，直接依托平台能力实现高可用：

配置方式：在创建 EMR Serverless Doris 实例时，直接勾选高可用选项，平台会自动部署多 FE 节点并关联负载均衡组件（PLB）；
访问方式：实例创建完成后，用户只需访问实例对应的内网地址，即可自动连接到开启负载均衡的 PLB；
高可用原理：PLB 会实时监测后端所有 FE 节点的运行状态，采用“轮询”策略分发请求——当某一 FE 节点故障时，PLB 会自动跳过故障节点，将请求转发至正常节点，保障服务不中断。

应用层代码：自定义重试与负载均衡

适用于需要自主控制负载均衡逻辑的场景（如定制化业务系统），需在代码层实现故障检测与重试：

核心逻辑：在应用代码中嵌入“负载均衡+故障重试”机制，当某一 FE 节点连接宕机时，系统自动切换至其他已配置的 FE 节点；
关键操作：需提前在代码配置中录入多个 Doris 前端节点地址（至少 2 个，避免单点依赖），确保故障时存在可切换的备用节点；
优势：灵活性高，可根据业务场景调整重试次数、切换策略（如轮询、随机、权重等），适配个性化需求。

MySQL JDBC Connector：依托驱动的自动重试

适用于通过 MySQL JDBC Connector 连接 Doris 的场景（如 Java 应用），直接借助 JDBC 驱动原生能力实现高可用：

配置方式：在 JDBC 连接地址中加入“loadbalance”标识，指定多个 FE 节点地址，驱动会自动处理负载均衡与重试；
标准连接格式：

jdbc:mysql:loadbalance://[host1][:port],[host2][:port][,[host3][:port]]...[/[database]][?propertyName1=propertyValue1[&propertyName2=propertyValue2]...]

核心原理：JDBC 驱动会定期检测各 FE 节点的可用性，采用内置轮询策略分发请求；当某一节点故障时，驱动自动重试其他正常节点，无需业务代码额外处理。

BE 高可用实践：基于存算一体的架构设计

BE 作为 Doris 集群的“数据存储与计算核心”，高可用依托多副本存储+节点变化自动适配实现，默认基于存算一体架构，具体分为“基础能力”“节点适配”“架构局限”三部分：

基础高可用能力：多副本保障数据与服务双可靠

Doris 默认集群（存算一体模式）已具备高可用基础，核心依赖“3 节点 BE + Tablet 三副本”架构：

节点部署要求：默认需部署至少 3 个 BE 节点，形成集群化部署，避免单点故障；
数据存储逻辑：Doris 将数据划分为“Tablet”（数据分片），每个 Tablet 默认存储3 个副本，且 3 个副本会分散存储在不同 BE 节点上；
高可用保障：
1. 数据可靠：即使某一 BE 节点故障，其存储的 Tablet 副本可通过其他节点的副本恢复，无数据丢失风险；
2. 服务可用：三副本模式下，单个 BE 节点异常（如宕机、断连）时，集群仍有 2 个正常副本提供读写服务，不影响业务查询；
3. 性能增益：增加 Tablet 副本数（如从 3 个扩至 4 个），还可提升系统的高并发查询能力——多副本可同时响应不同请求，分散计算压力。

节点变化适配：扩缩容时自动保障高可用

当 BE 节点数量发生变化（如业务增长需扩容、资源冗余需缩容）时，Doris 可自动完成适配，无需停止服务，保障扩缩容过程中高可用不中断：

核心机制：Tablet 自动迁移：节点变化会触发集群的“Tablet 均衡调度”，系统根据节点数量动态调整 Tablet 副本分布：
- 扩容场景：新增 BE 节点后，集群会自动将部分原有节点的 Tablet 副本迁移至新增节点，确保所有 BE 节点的存储与计算压力均衡；
- 缩容场景：待下线 BE 节点前，集群会先将该节点上的所有 Tablet 副本迁移至其他正常 BE 节点，迁移完成后再下线节点，确保每个 Tablet 的副本数始终维持在默认的 3 个（或用户配置的数量），不影响数据可靠性；
管理员操作优势：无需手动执行“数据重分布”“副本迁移”等复杂操作，只需发起扩缩容指令，集群自动完成后续适配，降低运维成本。

存算一体架构的局限性

存算一体架构虽能保障高可用与查询性能，但在成本、复杂度与弹性方面存在明显局限，需结合业务场景权衡使用：

成本较高：为保障数据可靠性，需维持至少 3 个数据副本，导致存储资源占用量为“实际数据量的 3 倍”；且随着数据量增长，需同步扩容存储与计算资源（存算绑定），可能造成计算资源冗余（如存储不足但计算仍有剩余）；
架构复杂度高：需维护多副本间的数据一致性（如副本同步、故障恢复时的副本补全），增加了集群底层调度与监控的复杂度；
弹性体验不佳：扩缩容触发 Tablet 自动迁移，迁移过程消耗集群资源（如网络带宽、IO），且数据量越大迁移耗时越长，期间集群查询性能可能受影响。

最近更新时间：2025.12.26 16:12:32

这个页面对您有帮助吗？

有用

无用