celery

Celery 是一个 基于python开发的分布式异步消息任务队列，通过它可以轻松的实现任务的异步处理， 如果你的业务场景中需要用到异步任务，就可以考虑使用celery， 举几个实例场景中可用的例子: 你想对100台机器执行一条批量命令，可能会花很长时间 ，但你不想让你的程序等着结果返回，而是给你返回 一个任务ID,你过一段时间只需要拿着这个任务id就可以拿到任务执行结果， 在任务执行ing进行时，你可以继续做其它的事情。 你想做一个定时任务，比如每天检测一下你们所有客户的资料，如果发现今天 是客户的生日，就给他发个短信祝福 Celery 在执行任务时需要通过一个消息中间件来接收和发送任务消息，以及存储任务结果， 一般使用rabbitMQ or Redis Celery有以下优点： 简单：一单熟悉了celery的工作流程后，配置和使用还是比较简单的 高可用：当任务执行失败或执行过程中发生连接中断，celery 会自动尝试重新执行任务 快速：一个单进程的celery每分钟可处理上百万个任务 灵活： 几乎celery的各个组件都可以被扩展及自定制 Celery基本工作流程图 Celery安装使用 Celery的默认broker是RabbitMQ, 仅需配置一行就可以 broker_url = 'amqp://guest:guest@localhost:5672//' rabbitMQ

问题描述： 安装django_celery_results后，将任务结果保存在数据库中，但是在成功运行完任务时将执行结果保存在数据库中时报错 django.db.utils.OperationalError: (2003, "Can't connect to MySQL server on 'localhost' ([Errno 11001] No address found)") 如下： Traceback (most recent call last): File "f:\django_learn_project3\mysite\venv\lib\site-packages\celery\app\trace.py", line 449, in trace_task uuid, retval, task_request, publish_result, File "f:\django_learn_project3\mysite\venv\lib\site-packages\celery\backends\base.py", line 149, in mark_as_done self.store_result(task_id, result, state, request=request) File "f:\django_learn_project3\mysite\venv

django性能优化 方式1：压缩django响应体 通过压缩响应json数据，从而加快响应速度，并且 django-compression-middleware 支持多种浏览器（除了IE11）。 下载 django-compression-middleware 在settings配置： MIDDLEWARE = [ ... "django.middleware.common.CommonMiddleware", "django.contrib.auth.middleware.AuthenticationMiddleware", "compression_middleware.middleware.CompressionMiddleware", ... ] 使用 django-compression-middleware 之前： 使用 django-compression-middleware 之后： 可以看到，压缩后后响应体，Content-length相比原来缩小了六分之一。需要知道的是Django文档GZipMiddleware章节所说，压缩可能会导致网站出现安全漏洞。 方式2：通过分页来 通过 PageNumberPagination 解决，详见 restFramework之------分页 。 方式3：select_related 一对多关系,一对一关系 前置条件

celery定时任务 Celery 是一个强大的分布式任务队列，它可以让任务的执行完全脱离主程序，甚至可以被分配到其他主机上运行。我们通常使用它来实现异步任务（ async task ）和定时任务（ crontab ）。 异步任务比如是发送邮件、或者文件上传, 图像处理等等一些比较耗时的操作 ，定时任务是需要在特定时间执行的任务。它的架构组成如下图： 任务队列 任务队列是一种跨线程、跨机器工作的一种机制. 任务队列中包含称作任务的工作单元。有专门的工作进程持续不断的监视任务队列，并从中获得新的任务并处理. 任务模块 包含异步任务和定时任务。其中，异步任务通常在业务逻辑中被触发并发往任务队列，而定时任务由 Celery Beat 进程周期性地将任务发往任务队列。 消息中间件 Broker Broker ，即为任务调度队列，接收任务生产者发来的消息（即任务），将任务存入队列。 Celery 本身不提供队列服务，官方推荐使用 RabbitMQ 和 Redis 等。 任务执行单元 Worker Worker 是执行任务的处理单元，它实时监控消息队列，获取队列中调度的任务，并执行它。 任务结果存储 Backend Backend 用于存储任务的执行结果，以供查询。同消息中间件一样，存储也可使用 RabbitMQ, Redis 和 MongoDB 等。 Celery Beat 任务调度器

在生产环境中部署Django、Celery项目需要开机启动，因此需要配置系统服务。 下面以CentOS7系统为例，记录配置Django和Celery为系统服务，并开机启动。 1.Django服务 在生产环境中部署Django项目需要用到uwsgi或gunicorn，这里我使用gunicorn。 1.1 Gunicorn简介 Gunicorn“绿色独角兽”是一个被广泛使用的高性能的Python WSGI UNIX HTTP服务器，移植自Ruby的独角兽（Unicorn ）项目,使用pre-fork worker模式，具有使用非常简单，轻量级的资源消耗，以及高性能等特点。 Gunicorn 服务器作为wsgi app的容器，能够与各种Web框架兼容（flask，django等）,得益于gevent等技术，使用Gunicorn能够在基本不改变wsgi app代码的前提下，大幅度提高wsgi app的性能。 1.2 安装Gunicorn pip3 install gunicorn 1.3 Gunicorn systemd unit 编写/usr/lib/systemd/system/django.service [Unit] Description=django daemon service After=network.target [Service] WorkingDirectory=

基本使用参考之前blog http://my.oschina.net/1123581321/blog/209271 ---之前的blog代码组织结构不太好 参照官方doc http://docs.celeryproject.org/en/master/userguide/periodic-tasks.html 实例参考 http://www.dongwm.com/archives/how-to-use-celery/ 项目结构 test_new_style/proj ├── __init__.py ├── celery.py # 这个必须是celery.py这个名字 └── tasks.py # 这个不一定是tasks.py, 但是要和include的一致 test.py $cat test_new_style/proj/celery.py # -*- coding: utf-8 -*- from __future__ import absolute_import from celery import Celery app = Celery("proj", broker="amqp://guest@localhost//", backend="amqp", include=["proj.tasks"] ) app.conf.update( CELERY_ROUTES={ "proj

Docker Compose 前面我们使用 Docker 的时候，定义 Dockerfile 文件，然后使用 docker build、docker run 等命令操作容器。然而微服务架构的应用系统一般包含若干个微服务，每个微服务一般都会部署多个实例，如果每个微服务都要手动启停，那么效率之低，维护量之大可想而知使用 Docker Compose 可以轻松、高效的管理容器，它是一个用于定义和运行多容器 Docker 的应用程序工具 Docker 和 Compose兼容性看下图： Docker版本变化说明： Docker从1.13.x版本开始，版本分为企业版EE和社区版CE，版本号也改为按照时间线来发布，比如17.03就是2017年3月。 Docker的linux发行版的软件仓库从以前的https://apt.dockerproject.org和https://yum.dockerproject.org变更为目前的https://download.docker.com, 软件包名字改为docker-ce和docker-ee。 docker compose是什么： Compose是一个定义和管理多容器的工具，使用Python语言编写。 使用Compose配置文件描述多个容器应用的架构，比如使用什么镜像、数据卷、网络、映射端口等； 然后一条命令管理所有服务，比如启动、停止、重启等。

一、背景 本文同步发表于 Prodesire 公众号 ，和 Prodesire 博客 。 最近做云服务 API 测试项目的过程中，发现某些时候会大批量调用 API，从而导致限流的报错。在遇到这种报错时，传统的重试策略是每隔一段时间重试一次。但由于是固定的时间重试一次，重试时又会有大量的请求在同一时刻涌入，会不断地造成限流。 这让我回想起两年前在查阅 Celery Task 文档 的时候发现可以为任务设置 retry_backoff 的经历，它让任务在失败时以 指数退避 的方式进行重试。那么指数退避究竟是什么样的呢？ 二、指数退避 根据 wiki 上对 Exponential backoff 的说明，指数退避是一种通过反馈，成倍地降低某个过程的速率，以逐渐找到合适速率的算法。 在以太网中，该算法通常用于冲突后的调度重传。根据时隙和重传尝试次数来决定延迟重传。 在 c 次碰撞后（比如请求失败），会选择 0 和 $2^c-1$ 之间的随机值作为时隙的数量。 对于第 1 次碰撞来说，每个发送者将会等待 0 或 1 个时隙进行发送。 而在第 2 次碰撞后，发送者将会等待 0 到 3（ 由 $2^2-1$ 计算得到）个时隙进行发送。 而在第 3 次碰撞后，发送者将会等待 0 到 7（ 由 $2^3-1$ 计算得到）个时隙进行发送。 以此类推…… 随着重传次数的增加，延迟的程度也会指数增长。