Flower识别Celery worker工作节点的具体实现机制是什么？

背景命令参考 #

Celery worker 启动命令：

celery -A backend worker --broker=$REDIS_URL

Flower 启动命令：

celery -A backend flower --broker=$REDIS_URL

Flower 自动识别 Celery worker 的实现原理 #

Celery 原生自带事件广播机制支撑节点状态同步，Flower 的自动识别能力完全基于这套机制实现，核心逻辑如下：

• 每个 Celery worker 启动成功后，第一时间会向 broker 的全局广播队列推送 worker-online 事件，事件中携带当前 worker 的节点ID、主机名、监听队列、并发数、启动配置等完整元信息；运行过程中还会按固定间隔推送心跳事件，退出时推送 worker-offline 事件。
• Flower 启动后会作为专属消费者订阅 broker 上的 Celery 全局广播队列，实时消费所有 worker 推送的事件。
• Flower 接收到 worker-online 事件后，会自动解析事件中的 worker 元信息，更新本地维护的在线节点列表，就完成了新节点的自动识别；接收到 worker-offline 或长时间没收到某个 worker 的心跳事件时，也会自动标记对应节点离线。
• 针对 Flower 启动前已经在运行的 worker，Flower 会主动向广播队列发送状态探测请求，所有在线 worker 收到请求后都会返回自身的状态信息，Flower 可一次性拉取到全量在线节点数据。

Redis 类 broker 的相关存储说明 #

Redis 作为 broker 时不会持久化存储 Celery worker 的相关信息，仅作为事件的临时传输载体：

• 所有 worker 推送的事件都是临时消息，广播队列的消息默认消费后即删除，没有消费者在线时消息到期也会自动销毁，不会长期存储在 Redis 中。
• Redis 作为 broker 仅会存储 Celery 运行必需的待执行任务消息、任务队列元数据，不会单独维护在线 worker 列表。
• 如果你额外配置了 Redis 作为 Celery 结果后端，部分 worker 的运行统计数据可能会存储在结果后端中，但这属于结果后端的能力，不是 broker 层面的默认行为。

内容的提问来源于stack exchange，提问作者Альберт Александров