python celery 学习（一）

最新推荐文章于 2024-12-30 14:46:11 发布

转载最新推荐文章于 2024-12-30 14:46:11 发布 · 275 阅读

文章标签：

#python

python-celery 专栏收录该内容

2 篇文章

订阅专栏

本文深入解析Celery——一个Python编写的分布式任务调度框架。介绍其架构，包括消息中间件、任务执行单元和任务结果存储，以及如何利用生产者消费者模式解决并发问题。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

学习celery先了解下生产者消费者模式

生产者消费者模式

生产者：
在实际的软件开发过程中，经常会碰到如下场景：某个模块负责产生数据，这些数据由另一个模块来负责处理（此处的模块是广义的，可以是类、函数、线程、进程等）。产生数据的模块，就形象地称为生产者；
消费者：
而处理数据的模块，就称为消费者。

缓冲区：
单单抽象出生产者和消费者，还够不上是生产者消费者模式。该模式还需要有一个缓冲区处于生产者和消费者之间，作为一个中介。生产者把数据放入缓冲区，而消费者从缓冲区取出数据，如下图所示：
在这里插入图片描述

生产者消费者模式是通过一个容器来解决生产者和消费者的强耦合问题。生产者和消费者彼此之间不直接通讯，而通过消息队列（缓冲区）来进行通讯，所以生产者生产完数据之后不用等待消费者处理，直接扔给消息队列，消费者不找生产者要数据，而是直接从消息队列里取，消息队列就相当于一个缓冲区，平衡了生产者和消费者的处理能力。这个消息队列就是用来给生产者和消费者解耦的。------------->这里又有一个问题，什么叫做解耦？

解耦：假设生产者和消费者分别是两个类。如果让生产者直接调用消费者的某个方法，那么生产者对于消费者就会产生依赖（也就是耦合）。将来如果消费者的代码发生变化，可能会影响到生产者。而如果两者都依赖于某个缓冲区，两者之间不直接依赖，耦合也就相应降低了。
生产者直接调用消费者的某个方法，还有另一个弊端。由于函数调用是同步的（或者叫阻塞的），在消费者的方法没有返回之前，生产者只好一直等在那边。万一消费者处理数据很慢，生产者就会白白糟蹋大好时光。缓冲区还有另一个好处。如果制造数据的速度时快时慢，缓冲区的好处就体现出来了。当数据制造快的时候，消费者来不及处理，未处理的数据可以暂时存在缓冲区中。等生产者的制造速度慢下来，消费者再慢慢处理掉。

这个模式，主要就是用来处理并发问题的
Celery就是一个用python写的并行分布式框架。

celery

Celery是一个简单、灵活且可靠的，处理大量消息的分布式系统，并且提供维护这样一个系统的必需工具
Celery支持使用任务队列的方式在分布的机器、进程、线程上执行任务调度。

任务队列：
任务队列是一种在线程或机器间分发任务的机制。
任务队列是一个逻辑上的概念，即将抽象的任务发送到执行的worker的组件，有的时候包含了后端的worker，有的时候不包含，并没有什么具体的形式，也没有什么规范。

消息队列：
理解为一个中间件提供一个平台供不同的平台、不同的语言之间的可靠的、持久的异步通信机制

消息队列的输入是工作的一个单元，称为任务，独立的职程（Worker）进程持续监视队列中是否有需要处理的新任务。

Celery 用消息通信，通常使用中间人（Broker）在客户端和职程间斡旋。这个过程从客户端向队列添加消息开始，之后中间人把消息派送给职程，职程对消息进行处理。如下图所示：

在这里插入图片描述
Celery 系统可包含多个职程和中间人，以此获得高可用性和横向扩展能力。

Celery的架构

Celery的架构由三部分组成，消息中间件（message broker），任务执行单元（worker）和任务执行结果存储（task result store）组成。

消息中间件：Celery本身不提供消息服务，但是可以方便的和第三方提供的消息中间件集成，包括，RabbitMQ,Redis,MongoDB等，相当于生产者模式中的缓存曲。

任务执行单元（worker）：Worker是Celery提供的任务执行的单元，worker并发的运行在分布式的系统节点中。生产者模式中的消费者

任务结果存储：Task result store用来存储Worker执行的任务的结果，Celery支持以不同方式存储任务的结果，包括Redis，MongoDB，Django ORM，AMQP等，这里我先不去看它是如何存储的，就先选用Redis来存储任务执行结果。