PYTHON的学习和理解 CELERY最佳实践.pdfVIP

作为一个Celery使用重度用户，看到 CeleryBestPractices 这篇文章，干脆翻译出来，同时也会加入我们项目中celery的实战经 验。 通常在使用Django的时候，你可能需要执行一些长时间的后台任务，没准你可能需要使用一些能排序的任务队列，那么Celery将会 是一个非常好的选择。 当把Celery作为一个任务队列用于很多项目中后，作者积累了一些最佳实践方式，譬如如何用合适的方式使用Celery，以及一些Celery 提供的但是还未充分使用的特性。 1，不要使用数据库作为你的AMQP Broker 数据库并不是天生设计成能用于AMQP broker 的，在生产环境下，它很有可能在某时候当机 （PS，当掉这点我觉得任何系统都不能保 证不当吧！！！）。 作者猜想为啥很多人使用数据库作为broker主要是因为他们已经有一个数据库用来给webapp提供数据存储了，于是干脆直接拿来使 用，设置成Celery的broker是很容易的，并且不需要再安装其他组件 （譬如RabbitMQ）。 假设有如下场景：你有4个后端workers去获取并处理放入到数据库里面的任务，这意味着你有4个进程为了获取最新任务，需要频 繁地去轮询数据库，没准每个worker 同时还有多个自己的并发线程在干这事情。 某 一天，你发现因为太多的任务产生，4个worker不够用了，处理任务的速度已经大大落后于生产任务的速度，于是你不停去增加 worker 的数量。突然， 你的数据库因为大量进程轮询任务而变得响应缓慢，磁盘IO一直处于高峰值状态，你的web应用也开始受到 影响。这一切，都因为workers在不停地对数 据库进行DDOS。 而 当你使用一个合适的AMQP （譬如RabbitMQ）的时候，这一切都不会发生，以RabbitMQ为例，首先，它将任务队列放到内存里面， 你不需要去访 问硬盘。其次，consumers（也就是上面的worker）并不需要频繁地去轮询因为RabbitMQ能将新的任务推送给consumers。 当然， 如果RabbitMQ真出现问题了，至少也不会影响到你的web应用。 这也就是作者说的不用数据库作为broker 的原因，而且很多地方都提供了编译好的RabbitMQ镜像，你都能直接使用，譬如 这些 。 对 于这点，我是深表赞同的。我们系统大量使用Celery处理异步任务，大概平均一天几百万的异步任务，以前我们使用的mysql， 然后总会出现任务处理延 时太严重的问题，即使增加了worker也不管用。于是我们使用了redis，性能提升了很多。至于为啥使用 mysql很慢，我们没去深究，没准也还真出 现了DDOS的问题。 2，使用更多的queue （不要只用默认的） Celery非常容易设置，通常它会使用默认的queue用来存放任务 （除非你显示指定其他queue）。通常写法如下： @app.task() def my_taskA(a, b, c): print(doing something here...) @app.task() def my_taskB(x, y): print(doing something here...) 这 两个任务都会在同一个queue里面执行，这样写其实很有吸引力的，因为你只需要使用一个decorator就能实现一个异步任务。作 者关心的是 taskA和taskB没准是完全两个不同的东西，或者一个可能比另一个更加重要，那么为什么要把它们放到一个篮子里面呢？ （鸡蛋都不能放到一个篮子里 面，是吧！）没准taskB其实不怎么重要，但是量太多，以至于重要的taskA反而不能快速地被worker 进行处理。增加workers也解决不了这 个问题，因为taskA和taskB仍然在一个queue里面执行。 3，使用具有优先级的workers 为了解决2里面出现的问题，我们需要让taskA在一个队列Q1，而taskB在另一个队列Q2执行。同时指定 x workers去处理队列 Q1的任务，然后使用其它的workers去处理队列Q2的任务。使用这种方式，taskB能够获得足够的workers去处理，同时一些优先级 workers也能很好地处理taskA而不需要进行长时间的等待。 首先手动定义queue CELERY_QUEUES ( Queue(default, Exchange(default), routing_key default), Queue(for_task_A, Exchange(for_task_A), routing_key for_task_A), Queue(