复现版本
celery <= 5.5.3
背景
使用pycharm配置启动celery得不到预期
现在剩下qwe
然后强制关闭然后他重放队列
结论
跟solo有关 这个代码kombu会将一个"发送 ACK"的命令放入其内部的发送缓冲区，不会马上发送
solo的工作模式：
- 从消息队列（MQ）获取消息。
- 处理任务的元数据。
- 执行任务函数本身。
- 与 MQ 进行通信（如发送 ACK）
当使用 acks_late=False (默认设置) 时，Celery 的内部流程：
- 获取消息：Solo Worker 的主循环从 MQ (如 RabbitMQ) 获取了一条消息。
- 准备执行：Worker 解析消息，准备调用您的任务函数。
- 调用 early ack：代码执行到 if not self.task.acks_late: self.acknowledge()。此时，Celery 的网络库（ kombu）会将一个"发送 ACK"的命令放入其内部的发送缓冲区。
- 执行任务代码：Worker 立即开始执行您的任务代码。假设您的任务里有 time.sleep(100)。
- 关键点：线程阻塞：time.sleep(100) 是一个同步阻塞操作。因为它运行在 Worker 唯一的主线程中，所以它会冻结整个 Worker。在这个时候，主线程被 sleep 占据，完全无法去做其他任何事情，包括处理网络I/O缓冲区、发送之前准备好的 ACK 命令。
- MQ 等待 ACK：在 RabbitMQ 的视角里，它已经将消息投递给了消费者，但迟迟没有收到 ACK 回复。因此，它正确地将这条消息保持在 unacked 状态。
- 任务结束：100 秒后，time.sleep(100) 结束，您的任务函数返回。
- 恢复 I/O：现在，主线程的控制权回到了 Celery Worker 的主循环中。它终于有空去处理它的网络I/O缓冲区了。
- 发送 ACK：Worker 这时才真正地通过网络连接，将第 3 步中准备好的 ACK 命令发送给 RabbitMQ。
- MQ 确认消息：RabbitMQ 收到 ACK，于是从 unacked 状态中移除该消息。
在处理任务函数时被阻塞住了所以不发送ack，直到执行结束才发送ack
这个时候又分为2个得不到预期的情况：
- 终端直接使用命令启动：非正常结束不管配置acks_late是什么消息都丢失 如果worker正在消费，然后连续ctrl+c会报错，因为solo没有实现关闭任务
NotImplementedError: <class 'celery.concurrency.solo.TaskPool'> does not implement kill_job - 使用pycharm配置命令启动：非正常结束不管配置acks_late是什么消息都塞回队列可以重新消费
prefork工作模式：
- 主进程：负责从 MQ 获取消息和处理网络 I/O（包括发送 ACK）。
- 子进程池：负责真正执行任务代码。
流程会变成：
- 主进程从 MQ 获取消息。
- 主进程看到 acks_late=False，于是立即通过自己的网络连接发送 ACK 给 MQ。由于主进程不执行任务代码，它不会被阻塞。
- MQ 几乎瞬间收到 ACK，并将消息从 unacked 队列移除。
- 主进程将任务的执行工作分派给一个空闲的子进程。
- 子进程开始执行 time.sleep(100)。这只会阻塞子进程自己，完全不影响主进程继续从 MQ 获取新任务和发送 ACK。
所以及时在-c 1也可以处理其他信息，包括celery -A config inspect reserved等在使用solo进程worker在消费时无法执行其他命令
相关issue：
从工作模式看我觉得是可以接受的，但是celery的开发者好像觉得是个bug等待有缘人修复
https://github.com/celery/celery/issues/5935