Celery原理使用介绍
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
因为队列只允许在后端插入，在前端移除，所以只有最早进 入队列的元素才能最先从队列中移除，故队列又称为先进先 出（FIFO—first in first out）线性表。
02
消息队列中的“消息”即指同一台计算机的进程间，或不同 计算机的进程间传送的数据；
“消息队列”即指的是在消息的传输过程中保存消息的“队 列”。
Broker Settings ➢CELERY_ACCEPT_CONTENT ➢BROKER_URL ➢BROKER_CONNECTION_TIMEOUT ➢BROKER_CONNECTION_RETRY ➢BROKER_CONNECTION_MAX_RETRIES
Worker Settings ➢CELERY_IMPORTS
保证消息的可靠传递。如果发送消息时接收者不可用，消息 队列会保留消息，直到成功地传递它；
提供异步的通信协议。消息的发送者将消息发送到消息队列 后可以立即返回，不用等待接收者的响应，消息会被保存在 队列中，直到接收者取出它；
03
即Advanced Message Queuing Protocol,一个提供统一消息服务的应用层标 准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设 计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不 同产品，不同开发语言等条件的限制。
➢binding key中可以存在两种特殊字符“*”与“#”，用于做模糊匹配， 其中“*”用于匹配一个单词，“#”用于匹配多个单词（可以是零个）
➢当消息的routing key与某个Queue绑定的binding key匹配时，则可路由 到该Queue
fanout类型最简单，这种类型会无视binding key，将消息路由到每个与之 绑定的Queue：
0４
Celery是一个处理大量消息的分布式系统，并且提供维护这 样一个系统的必需工具。
专注于实时处理的任务队列，同时也支持任务调度。
Producer端：只要某个任务（函数）是Celery实例的task方 法修饰过的，调用时就会自动投递到Celery的任务队列中。
Broker端（MQ服务器端）：Celery本身并不提供MQ服务，因 此Celery需要一个MQ的解决方案，其通常以独立服务形式出 现，称为“Broker”。
➢CELERY_INCLUDE
➢CELERYD_TASK_TIME_LIMIT
Message Routing ➢CELERY_QUEUES ➢CELERY_ROUTES ➢CELERY_CREATE_MISSING_QUEUES ➢CELERY_DEFAULT_QUEUE ➢CELERY_DEFAULT_EXCHANGE ➢CELERY_DEFAULT_EXCHANGE_TYPE ➢CELERY_DEFAULT_ROUTING_KEY
消息队列的产品及协议标准不一致，使应用与消息队列之间 的耦合加大。
各种消息队列的开发都基于各自的开发语言，使用上受限。
生产者
消费者
如果每个消息的处理时间不同，就有可能会导致某些Consumer一直在忙，而 另外一些Consumer很快就处理完手头工作并一直空闲的情况
这种情况下，可以限制Queue每次给每个Consumer只发送一条消息；某个 Consumer处理完这条消息后Queue再给该Consumer发送一条消息。
01 队列（Queue） 消息队列（MQ）
02
03 高级消息队列协议 （AMQP） Ｃｅｌｅｒｙ的使用
04
01
队列是一种特殊的线性表，特殊之处在于它只允许在表的前 端（front）进行移除操作，而在表的后端（rear）进行插 入操作。
队列的数据元素又称为队列元素。在队列中插入一个队列元 素称为入队，从队列中移除一个队列元素成为出队。
Consumer端：Celery中的Consumer，称之为“Worker”。其 除了订阅并处理任务外，还附加一些丰富的配置和管理功能。
Backend端：用于保存任务执行的结果（可选组件）。
官方推荐rabbitMQ及Redis两种Broker方案，其他Broker方 案均只是作为实验性质的，不推荐用在Deployment环境。
另外需要单独安装Redis服务端（独立运行软件，非ຫໍສະໝຸດ Baiduython 包），Windows和Linux需要分别下载。
在上述的演示实例中，有很多细节是没有涉及到的，比如： Celery构建了几个Queue？Worker怎么订阅到这些Queue上的？ Queue是按轮询分发还是公平分发？
如上提及的这些配置，在使用Celery时实际都是需要明确的， 但是上述的演示实例中却几乎没有配置过，这是因为Celery 本身有一套默认配置，能胜任大部分的使用环境（虽然效率 可能不是最优的）
Redis比较小巧（0.5MB），功能完备性比不上rabbitMQ，但 经过Celery的一番构造，使其也具备了AMQP模型的各种功能， 已能胜任绝大部分应用场景。
推荐使用Redis
Celery的依赖库极其多（虽然大部分是可选的），因此推荐 使用pip安装
pip install -U celery[redis]==3.1.19
该方式称之为Fair dispatch（公平分发）
topic类型与direct类型很相似，主要是扩展了模糊匹配，它约定：
➢binding key与routing key均可设置为以“.”相连的字符串，例如： “quick.orange.rabbit”，每个以“.”分隔开的字符串视作一个“单 词”，比如上例的单词为“quick”、“orange”、“rabbit”
rabbitMQ是一个使用Erlang语言编写的，完整实现AMQP的服 务端，支持多种语言的client进行访问。
Redis是一个可内存亦可持久化的日志型、Key-Value数据库。 由于其支持list类型的数据，以及支持push/pop操作的特性， 使其在很多领域被用作了高速队列来使用。
rabbitMQ一般用于企业级环境，比较庞大（约90MB左右）， 另外还必须先安装Erlang才能用。
02
消息队列中的“消息”即指同一台计算机的进程间，或不同 计算机的进程间传送的数据；
“消息队列”即指的是在消息的传输过程中保存消息的“队 列”。
Broker Settings ➢CELERY_ACCEPT_CONTENT ➢BROKER_URL ➢BROKER_CONNECTION_TIMEOUT ➢BROKER_CONNECTION_RETRY ➢BROKER_CONNECTION_MAX_RETRIES
Worker Settings ➢CELERY_IMPORTS
保证消息的可靠传递。如果发送消息时接收者不可用，消息 队列会保留消息，直到成功地传递它；
提供异步的通信协议。消息的发送者将消息发送到消息队列 后可以立即返回，不用等待接收者的响应，消息会被保存在 队列中，直到接收者取出它；
03
即Advanced Message Queuing Protocol,一个提供统一消息服务的应用层标 准高级消息队列协议,是应用层协议的一个开放标准,为面向消息的中间件设 计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不 同产品，不同开发语言等条件的限制。
➢binding key中可以存在两种特殊字符“*”与“#”，用于做模糊匹配， 其中“*”用于匹配一个单词，“#”用于匹配多个单词（可以是零个）
➢当消息的routing key与某个Queue绑定的binding key匹配时，则可路由 到该Queue
fanout类型最简单，这种类型会无视binding key，将消息路由到每个与之 绑定的Queue：
0４
Celery是一个处理大量消息的分布式系统，并且提供维护这 样一个系统的必需工具。
专注于实时处理的任务队列，同时也支持任务调度。
Producer端：只要某个任务（函数）是Celery实例的task方 法修饰过的，调用时就会自动投递到Celery的任务队列中。
Broker端（MQ服务器端）：Celery本身并不提供MQ服务，因 此Celery需要一个MQ的解决方案，其通常以独立服务形式出 现，称为“Broker”。
➢CELERY_INCLUDE
➢CELERYD_TASK_TIME_LIMIT
Message Routing ➢CELERY_QUEUES ➢CELERY_ROUTES ➢CELERY_CREATE_MISSING_QUEUES ➢CELERY_DEFAULT_QUEUE ➢CELERY_DEFAULT_EXCHANGE ➢CELERY_DEFAULT_EXCHANGE_TYPE ➢CELERY_DEFAULT_ROUTING_KEY
消息队列的产品及协议标准不一致，使应用与消息队列之间 的耦合加大。
各种消息队列的开发都基于各自的开发语言，使用上受限。
生产者
消费者
如果每个消息的处理时间不同，就有可能会导致某些Consumer一直在忙，而 另外一些Consumer很快就处理完手头工作并一直空闲的情况
这种情况下，可以限制Queue每次给每个Consumer只发送一条消息；某个 Consumer处理完这条消息后Queue再给该Consumer发送一条消息。
01 队列（Queue） 消息队列（MQ）
02
03 高级消息队列协议 （AMQP） Ｃｅｌｅｒｙ的使用
04
01
队列是一种特殊的线性表，特殊之处在于它只允许在表的前 端（front）进行移除操作，而在表的后端（rear）进行插 入操作。
队列的数据元素又称为队列元素。在队列中插入一个队列元 素称为入队，从队列中移除一个队列元素成为出队。
Consumer端：Celery中的Consumer，称之为“Worker”。其 除了订阅并处理任务外，还附加一些丰富的配置和管理功能。
Backend端：用于保存任务执行的结果（可选组件）。
官方推荐rabbitMQ及Redis两种Broker方案，其他Broker方 案均只是作为实验性质的，不推荐用在Deployment环境。
另外需要单独安装Redis服务端（独立运行软件，非ຫໍສະໝຸດ Baiduython 包），Windows和Linux需要分别下载。
在上述的演示实例中，有很多细节是没有涉及到的，比如： Celery构建了几个Queue？Worker怎么订阅到这些Queue上的？ Queue是按轮询分发还是公平分发？
如上提及的这些配置，在使用Celery时实际都是需要明确的， 但是上述的演示实例中却几乎没有配置过，这是因为Celery 本身有一套默认配置，能胜任大部分的使用环境（虽然效率 可能不是最优的）
Redis比较小巧（0.5MB），功能完备性比不上rabbitMQ，但 经过Celery的一番构造，使其也具备了AMQP模型的各种功能， 已能胜任绝大部分应用场景。
推荐使用Redis
Celery的依赖库极其多（虽然大部分是可选的），因此推荐 使用pip安装
pip install -U celery[redis]==3.1.19
该方式称之为Fair dispatch（公平分发）
topic类型与direct类型很相似，主要是扩展了模糊匹配，它约定：
➢binding key与routing key均可设置为以“.”相连的字符串，例如： “quick.orange.rabbit”，每个以“.”分隔开的字符串视作一个“单 词”，比如上例的单词为“quick”、“orange”、“rabbit”
rabbitMQ是一个使用Erlang语言编写的，完整实现AMQP的服 务端，支持多种语言的client进行访问。
Redis是一个可内存亦可持久化的日志型、Key-Value数据库。 由于其支持list类型的数据，以及支持push/pop操作的特性， 使其在很多领域被用作了高速队列来使用。
rabbitMQ一般用于企业级环境，比较庞大（约90MB左右）， 另外还必须先安装Erlang才能用。