这是基本文档，没有给我们太多信息
心跳
与工作人员和代理之间的通信有关（在您的情况下，代理是 CloudAMQP）。见说明
工作--without-heartbeat人员不会发送心跳事件
交融
它只在启动时向其他工作人员询问“逻辑时钟”和“撤销的任务”。
工作人员现在将尝试与同一集群中的其他工作人员同步。
同步数据目前包括撤销的任务和逻辑时钟。
这仅在启动时发生，并导致一秒钟的启动延迟以收集其他工作人员的广播响应。
您可以使用 --without-mingle 参数禁用此引导步骤。
另请参阅文档
八卦
工作人员向所有其他工作人员发送事件，这目前用于“时钟同步”，但也可以在事件上编写自己的处理程序，例如on_node_join，参见docs
工人现在被动地订阅与工人相关的事件，如心跳。
这意味着一个工作人员知道其他工作人员在做什么，并且可以检测他们是否下线。目前这仅用于时钟同步，但未来添加的可能性很多，您可以编写利用这一点的扩展。
一些想法包括共识协议、将任务重新路由到最佳工作人员（基于资源使用或数据位置）或在工作人员崩溃时重新启动工作人员。
我们相信，虽然这是一个小小的补充，但它开启了惊人的可能性。
您可以使用 --without-gossip 参数禁用此引导步骤。
Celery 工作人员启动时使用该--without-mingle选项，如上面提到的@ofirule，将不会接收来自其他工作人员的同步数据，尤其是撤销的任务。因此，如果您撤销一项任务，当前运行的所有工作人员都会收到该广播并将其存储在内存中，这样当其中一个工作人员最终从队列中提取任务时，它就不会执行它：
https://docs.celeryproject.org/en/stable/userguide/workers.html#persistent-revokes
但是，如果一个新的工作人员在该任务被接收到广播的工作人员出队之前启动，它不知道撤销该任务。如果它最终接受了任务，则执行该任务。如果您在不断动态扩展和缩减 celery 工作者的环境中运行，您将看到这种行为。
我想知道该--without-heartbeat标志是否会影响工作人员检测代理断开连接和尝试重新连接的能力。上面引用的文档仅不透明地提及这些心跳作用于应用程序层而不是 TCP/IP 层。好的——我真正想知道的是，消除这些消息是否会影响我的工作人员的工作能力——特别是检测代理断开连接然后尝试适当地重新连接？
我自己进行了一些快速测试，发现通过--without-heartbeat标志后，工作人员仍然很快检测到代理断开连接（由我关闭 RabbitMQ 实例启动），并且当我重新启动 RabbitMQ 时，他们尝试重新连接到代理并成功连接实例。所以我的基本测试表明，基本的健康检查和功能不需要心跳。无论如何，它们有什么意义？我不清楚，但它们似乎对工作人员的功能没有影响。