Apache Airflow 的调度能力建立在多组件协作之上，单节点部署虽然简单，但一旦 Webserver 或 Scheduler 进程异常退出，整个调度链路就会中断。要让 Airflow 真正承担生产级任务，必须从架构层面消除单点故障，将元数据数据库、消息队列、Web 服务、调度器和执行器分别进行高可用设计。
一、Airflow 高可用架构的核心组件与职责划分
Airflow 的集群架构通常包含五个关键角色：Webserver 负责提供 UI 和 REST API，Scheduler 负责解析 DAG 并生成任务实例，Worker 负责执行具体任务，Metadata Database 存储所有状态信息，Message Broker 则负责在 Scheduler 和 Worker 之间传递任务指令。其中 Metadata Database 和 Message Broker 是共享状态中心，所有节点都要依赖它们，因此这两部分的高可用是整体方案的前提。
在单机模式下，这些组件运行在同一进程中，资源竞争和单点风险都比较突出。切换到集群模式后，Webserver 和 Scheduler 可以部署在多个节点上，通过负载均衡对外提供服务；Worker 则根据任务量动态增减，天然具备水平扩展能力。关键在于让 Scheduler 多实例能够协同工作，而不是互相冲突，这需要依赖数据库的行级锁机制和消息队列的可靠投递。
从部署形态上看，比较推荐的做法是将数据库和消息队列独立到专门的服务器或云服务上，Airflow 节点只负责运行无状态组件。这样即使某个 Airflow 节点宕机，只要重新拉起一个新节点并指向同一个数据库和消息队列，就能快速恢复，不会丢失任务状态。
二、搭建高可用的 PostgreSQL 与 Redis 基础组件
Metadata Database 建议使用 PostgreSQL，因为它对并发和事务的支持比 MySQL 更完善，尤其适合多个 Scheduler 同时操作数据库的场景。生产环境中至少配置一主一从，主库负责写入，从库可以用来做备份或读扩展。如果使用云数据库，直接开启高可用版本即可；如果自建，可以通过流复制搭建主从，并配合 keepalived 或 Patroni 实现自动故障切换。
Message Broker 推荐 Redis 或 RabbitMQ。Redis 配置简单，性能高，但需要开启持久化并部署哨兵模式或集群模式来保证高可用。RabbitMQ 的功能更丰富，支持更细粒度的消息确认和路由策略，适合对消息可靠性要求极高的场景。无论选哪种，都要确保 broker 地址在 Airflow 配置中使用高可用入口，而不是单个节点 IP。
下面给出一个基于 Redis 哨兵模式的连接串示例，配置在 Airflow 的 airflow.cfg 中：
broker_url = redis://:password@sentinel1:26379,sentinel2:26379,sentinel3:26379/0 result_backend = db+postgresql://airflow:airflow@postgres-ha:5432/airflow
这里 broker_url 使用了哨兵地址列表，Redis 客户端会自动发现主节点，当主节点故障时自动切换到从节点，从而避免消息队列中断。result_backend 则直接指向高可用数据库入口，保证任务结果能够持久化。
三、安装与配置 Airflow 集群节点
所有 Airflow 节点需要安装相同版本的 Apache Airflow，并确保 Python 环境一致。推荐使用虚拟环境或容器化部署，以便快速复制节点。执行初始化数据库和创建管理员用户的命令只需在任意一个节点上运行一次，其他节点共享同一个数据库即可。
airflow db init airflow users create --role Admin --username admin --email admin@ipipp.com --firstname admin --lastname user --password admin
随后修改每个节点的 airflow.cfg，核心配置项如下：
[core] executor = CeleryExecutor sql_alchemy_conn = postgresql+psycopg2://airflow:airflow@postgres-ha:5432/airflow [celery] broker_url = redis://:password@sentinel1:26379,sentinel2:26379,sentinel3:26379/0 result_backend = db+postgresql://airflow:airflow@postgres-ha:5432/airflow [scheduler] scheduler_heartbeat_sec = 5 scheduler_health_check_threshold = 10
在 CeleryExecutor 模式下，Scheduler 只负责调度和派发任务，真正执行任务的是独立的 Worker 进程。因此需要专门启动 Worker 节点，命令如下：
airflow celery worker -H worker01
如果一个节点同时承担多个角色，可以用 systemd 管理多个服务单元。例如在节点一上同时运行 Webserver 和 Scheduler，节点二和三只运行 Worker。这种做法便于快速扩容和故障隔离。
四、Webserver 负载均衡与 Scheduler 多实例高可用
Webserver 本身是无状态的，可以启动多个实例，前面用 Nginx 做反向代理实现负载均衡。Nginx 会检测后端健康状态，如果某个 Webserver 实例停止响应，会自动把流量切到其他实例。下面是一段 Nginx 配置示例：
upstream airflow_webserver {
server 192.168.1.11:8080;
server 192.168.1.12:8080;
}
server {
listen 80;
location / {
proxy_pass http://airflow_webserver;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Scheduler 的高可用相对复杂一些。Airflow 2.x 版本支持多个 Scheduler 实例同时运行，它们会通过数据库中的行级锁来协调任务调度，避免重复调度同一个 DAG 实例。当其中一个 Scheduler 宕机时，其他实例会接管它的工作，这个过程通常只需要几秒钟。为了保证心跳和健康检查有效，需要确保所有 Scheduler 的时钟同步，并且数据库连接池配置合理。
在实际部署中，建议至少运行两个 Scheduler 实例，分别放在不同的物理机或虚拟机上。如果资源有限，也可以让一个节点同时运行 Webserver 和 Scheduler，另一个节点运行 Scheduler 和 Worker，这样即使第一个节点故障，第二个节点的 Scheduler 仍能维持调度。
五、部署验证与常见故障排查
完成上述配置后，需要验证集群是否真正具备高可用能力。首先在 Webserver 界面确认所有 DAG 能够正常加载，然后通过命令行查看 Scheduler 和 Worker 的运行状态：
airflow dags list airflow scheduler --help | grep health
进行故障切换测试时，可以手动 kill 掉一个 Scheduler 进程，观察任务调度是否在短时间内恢复。同样地，停止一个 Webserver 实例，验证 Nginx 是否自动将请求转移到其他实例。对于消息队列，可以模拟 Redis 主节点重启，检查 Worker 是否能够继续接收任务并执行。
常见问题包括数据库连接数不足导致 Scheduler 无法获取锁，此时需要调整 PostgreSQL 的 max_connections 以及 Airflow 的 sql_alchemy_pool_size 参数。另外，如果 Worker 频繁超时或任务丢失，需要检查 broker 的持久化策略和 Worker 的并发配置。通过系统监控和日志聚合，可以在故障发生时快速定位到具体组件，从而保障整个 Airflow 集群的稳定运行。
Apache Airflow高可用部署集群架构修改时间：2026-08-22 19:35:11