构建高可用、可扩展的Apache Airflow生产环境，核心在于实现元数据库的高可用、调度器的分布式锁机制以及日志的集中存储。Airflow集群安装并非简单的多节点部署，而是通过架构设计消除单点故障，确保调度任务在节点宕机时自动转移，从而保障数据管道的连续性。 生产环境推荐使用CeleryExecutor作为执行器，配合外部的PostgreSQL数据库和Redis消息队列,构建一个支持高并发的分布式调度系统。
架构规划与环境准备
在执行具体的安装步骤前，合理的架构规划是成功的基石,一个标准的Airflow集群架构通常包含以下核心组件：
- 元数据库： 推荐使用PostgreSQL或MySQL 8.0+，这是集群的“大脑”，存储所有DAG状态、任务实例和连接信息,必须配置主从复制或高可用组以保证数据安全。
- 消息队列： 推荐使用Redis，作为任务分发的高速通道，它连接Web Server、Scheduler和Worker,其性能直接影响任务调度的吞吐量。
- 调度器： 生产集群中通常部署2个Scheduler节点，利用数据库行级锁互为备份,解决单点故障问题。
- 工作节点： 负责执行具体的任务,可根据负载横向扩展。
- Web服务器： 提供可视化界面,建议部署多实例并通过Nginx做负载均衡。
基础环境配置与依赖安装
所有节点必须保持环境一致性，包括操作系统版本、Python版本以及网络配置。
- Python环境管理： 强烈建议使用Anaconda或Miniconda管理Python环境，确保Python版本在3.8及以上，这能有效隔离系统依赖,避免包冲突。
- 系统依赖安装： 在所有节点安装必要的系统库，如gcc、python3-devel、openldap-devel等,确保Python扩展包编译顺利。
- 网络与时间同步： 集群节点间必须配置NTP时间同步，时区建议统一设置为UTC或Asia/Shanghai,防止调度逻辑因时间偏差出现混乱。
核心组件安装与配置流程
airflow集群安装的核心在于配置文件的修改，而非简单的包安装，以下步骤需在所有节点执行,或在一个节点配置完成后分发。
-
安装核心包： 使用pip安装Airflow及特定版本的执行器依赖。
pip install apache-airflow[celery,postgres,redis]==2.x.x
此命令集成了Celery执行器、PostgreSQL支持和Redis客户端,确保版本号符合生产需求。
-
配置元数据库连接： 修改
$AIRFLOW_HOME/airflow.cfg文件。
sql_alchemy_conn 参数需指向高可用的PostgreSQL连接串，格式为：postgresql+psycopg2://user:password@host:port/dbname,这是集群数据一致性的关键。 -
配置执行器： 将
executor参数修改为CeleryExecutor，这是区分单机模式与集群模式的核心配置,决定了任务能否在分布式节点间流转。 -
配置消息队列：
broker_url 指向Redis连接串，格式如redis://:password@host:port/db_number。
result_backend 同样配置为Redis连接串,用于存储任务执行结果。
初始化与高可用部署策略
配置完成后，需按特定顺序启动服务,确保集群状态正确初始化。
- 数据库初始化： 在主节点运行
airflow db init，该命令会在元数据库中创建表结构，注意，只需运行一次，切勿在后续重启中重复执行,以免覆盖数据。 - 创建用户： 使用
airflow users create命令创建管理员账户，用于Web UI登录。 - 启动Scheduler服务： 在调度节点启动Scheduler，Airflow 2.0+版本支持多Scheduler运行，它们会通过数据库锁自动协调，只有一个处于活跃调度状态，另一个待命。这是实现调度层高可用的关键步骤。
- 启动Worker节点： 在工作节点运行
airflow celery worker，Worker启动后会自动注册到Redis队列中，等待调度指令,可根据业务量动态增减Worker数量。 - 启动Web服务： 启动
airflow webserver，建议配合Gunicorn和Nginx部署,提升并发访问能力。
生产环境优化与日志管理
默认配置无法满足生产级需求,必须进行深度优化。
- 远程日志存储： 集群环境下，任务可能运行在任意Worker节点，本地日志会导致查看困难。必须配置远程日志存储（如S3、OSS或NFS）。 在
airflow.cfg中开启remote_logging并配置远程存储路径，确保所有Worker将日志写入统一存储，Web Server能准确回溯。 - DAG文件分发： 保证所有节点的DAG文件一致是集群稳定的前提，推荐使用Git-Sync机制，让所有节点自动从Git仓库拉取最新DAG代码,避免手动分发带来的版本不一致风险。
- 资源隔离： 利用Kubernetes Pod Operator或Docker容器化运行任务,避免任务间资源争抢导致节点崩溃。
验证与监控
部署完成后,需进行严格的验证测试。
- 故障模拟： 手动停止活跃的Scheduler节点，观察备用节点是否在秒级接管调度工作；停止一个Worker,观察任务是否自动重试或分配给其他节点。
- 性能监控： 集成Prometheus和Grafana，监控关键指标如
scheduler_heartbeat、celery_queue_length及task_instance_duration,及时发现集群瓶颈。
相关问答
问：Airflow集群中Scheduler节点宕机，任务还会继续调度吗？
答：会的，在Airflow 2.0及以上版本中，支持多Scheduler部署模式，当配置了两个或更多Scheduler实例时，它们共享同一个元数据库，活跃的Scheduler会持有数据库锁，一旦其宕机，锁会释放，备用Scheduler会立即获取锁并接管调度工作,确保数据管道不中断。
问：为什么Worker节点执行任务后，Web界面看不到日志？
答：这是因为集群环境下的日志分散在各个Worker本地，Web Server运行在不同的机器上，无法访问Worker的本地文件系统，解决方案是开启Airflow的远程日志功能，将日志统一存储在S3、HDFS或NFS等共享存储中，并在配置文件中正确设置remote_base_log_folder和remote_log_conn_id。
如果您在搭建Airflow集群的过程中遇到配置难题或有独特的优化技巧,欢迎在评论区留言交流。
首发原创文章，作者：世雄 - 原生数据库架构专家，如若转载，请注明出处：https://idctop.com/article/86162.html
