CentOS 上 Dolphin 的高可用与容错方案
先明确 Dolphin 的具体产品
- Apache DolphinScheduler：分布式工作流调度系统，组件为 APIServer、Master、Worker，通过数据库持久化元数据，支持横向扩展与故障转移。
- DolphinDB：分布式时序数据库，提供 数据多副本强一致、Controller Raft 元数据高可用 与 客户端自动重连/切换。
- Dolphin（KDE 文件管理器）/Dolphin 模拟器：桌面或娱乐软件，非典型 HA 场景，生产服务器不建议作为核心服务承载。若你指的是前两者之一，请按下方对应方案实施。
Apache DolphinScheduler 的高可用与容错
- 架构要点
- APIServer 无状态：多实例 + 前置于 Nginx/HAProxy 做负载均衡与 VIP 漂移，即可实现入口高可用与水平扩展。
- Master 高可用：多 Master 通过工作流 Command ID 分片并行消费，结合数据库事务保证同一 Command 仅被一个 Master 处理；节点上下线由注册中心通知，容错由 Master 集群协同完成。
- Worker 高可用：无状态执行器，横向扩容后注册到注册中心，Master 自动分发任务；宕机后由 Master 触发任务容错与重调度。
- 建议的 CentOS 落地
- 基础环境：时间同步（chrony）、主机名解析、防火墙放行、数据库高可用（主从/集群）。
- 入口层：部署 2+ APIServer + VIP/HAProxy，对外提供稳定接入；健康检查指向 APIServer 的健康端点。
- 核心层：部署 3+ Master（奇数为佳），避免单点；确保元数据库高可用，避免 Master 集体脑裂时无法恢复。
- 执行层：部署 多 Worker 分布在不同宿主机；按业务峰值与资源规划并发度与队列。
- 运维要点：开启任务失败重试与告警；定期演练 Master/Worker 宕机与网络分区的故障转移；备份数据库与配置文件。
DolphinDB 的高可用与容错
- 架构要点
- 数据高可用：多副本强一致，副本数由 dfsReplicationFactor 控制；为避免同机副本风险，设置 dfsReplicaReliabilityLevel=1 让副本分布到不同机器。
- 元数据高可用：多个 Controller 组成 Raft 组，容忍少于半数的节点故障；建议 3/5 个 Controller 跨机部署，数据节点只与 Leader Controller 交互。
- 客户端高可用：API 支持自动重连与切换至可用数据节点，对业务透明。
- 建议的 CentOS 落地
- 拓扑规划：至少 3 台以上数据节点，并配置 副本数 ≥ 2；Controller 跨机部署并启用 Raft。
- 关键配置（示例）：
- controller.cfg：设置 dfsReplicationFactor=2、dfsReplicaReliabilityLevel=1、dfsHAMode=Raft。
- cluster.nodes：列出所有 Controller/DataNode/Agent 节点信息，保证跨机分布。
- 升级与迁移：从“单机/伪高可用”升级为“真正高可用”时，务必将 Controller 分布到不同物理机，避免“伪高可用”带来的集中故障风险。
通用增强与最佳实践（适用于 DolphinScheduler 与 DolphinDB）
- 基础设施
- Pacemaker + Corosync 管理关键浮动资源（如 VIP、负载均衡器、网关），实现节点故障时的自动切换；生产环境配置 STONITH/fencing 防止脑裂。
- 分布式/共享存储（如 GlusterFS/Ceph/DRBD）用于日志、临时文件或共享目录，避免单磁盘/单机故障影响服务。
- 监控与告警：主机、进程、JVM（如 DolphinScheduler Master/APIServer）、数据库/存储、网络延迟与丢包；结合 Prometheus/Grafana 与日志平台做可视化与阈值告警。
- 备份恢复：定期备份 数据库/元数据/配置文件 与关键脚本；演练恢复流程，验证 RPO/RTO 指标。
