关于celery的一些记录（依托答辩）

本文记录一下日常工作中在使用celery的一些经验和自己的感悟，希望能帮助到一些开始接触或者准备接触celery的兄弟们。本文参考并搬运了以下文章中的内容，强烈推荐对celery工作原理感兴趣或者对celery源码感兴趣的兄弟们，一定要阅读一下：

https://blog.csdn.net/weixin_47364682/article/details/114160304?spm=1001.2014.3001.5501该作者先从kombu包进行介绍，然后再对celery进行剖析，可谓是非常详细了。

1. celery介绍

官网介绍：Celery is a simple, flexible, and reliable distributed system to process vast amounts of messages, while providing operations with the tools required to maintain such a system.

It’s a task queue with focus on real-time processing, while also supporting task scheduling.

（Celery 是一个简单、灵活且可靠的分布式系统，可以处理大量消息，同时为操作提供维护此类系统所需的工具。它是一个专注于实时处理的任务队列，同时也支持任务调度。）

本人使用后感受: 本人日常进行一些微服务间的开发维护。在使用celery时，它对于微服务而已，还是比较契合的（毕竟遵循AMQP协议，做成分布式也不难）。在处理一些简单的任务时，可以选择celery，上手很快，但是深度使用还是比较难的事情，本人在正式接入业务系统时也踩了很多坑。同时基于kombu包进行开发，性能上也堪忧。

ps：全是主观，不喜轻喷

2. 了解celery的前置内容

在了解celery的工作流程前，得先知道celery中的基本概念：

2.1 AMQP协议

2.1.1 基本概念

上面说了celery遵循AMQP协议，更准确的说Kombu是对AMQP协议在python中的封装（可以理解为Kombu遵循了AMQP协议）

• 生产者和消费者：生产者创建消息，然后发布到代理服务器的队列中，代理服务器会把消息发送给感兴趣的接受方。消费者连接到代理服务器，并订阅到队列上，从而接收消息。

• 通道 channel：信道是 “真实的” TCP连接内的虚拟连接，AMQP的命令都是通过通道发送的。在一条TCP连接上可以创建多条信道。

• 有些应用需要与 AMQP 代理建立多个连接。同时开启多个 TCP 连接不合适，因为会消耗掉过多的系统资源并且使得防火墙的配置更加困难。AMQP 0-9-1 提供了通道（channels）来处理多连接，可以把通道理解成共享一个 TCP 连接的多个轻量化连接。

• 在涉及多线程 / 进程的应用中，为每个线程 / 进程开启一个通道（channel）是很常见的，并且这些通道不能被线程 / 进程共享。

• 一个特定通道上的通讯与其他通道上的通讯是完全隔离的，因此每个 AMQP 方法都需要携带一个通道号，这样客户端就可以指定此方法是为哪个通道准备的。