前言

Celery 是一个简单、灵活且可靠的，处理大量消息的分布式系统，并且提供 维护这样一个系统的必需工具。celery是一个专注于实时处理的任务队列，同时也支持任务调度。

在我们日常开发中，特别是Python Web 开发，Celery基本上是一个无法绕开的分布式任务队列框架，虽然Celery底层也是使用消息队列实现的，但是我们仍然将Celery称之为任务队列，原因在于通常我们指消息队列的时候，更多的是以大数据，高吞吐量，低延时相关联。而Celery本身的侧重点则在任务的生产以及消费中，消息队列传递的是消息，而任务队列传递的媒介是任务。通常来说，任务队列虽然会有并发处理任务的场景，但是本质上由于任务队列做了更多额外的关于任务的场景化的功能，比如状态，执行结果，重试, 分发等等等等，本身并不是特别适用于大数据，高吞吐量，低延时的场景。

对于蓝鲸的开发者而言，Celery绝对是我们无法绕开的任务队列框架，一方面，得益于Python在Web领域并不是特别繁荣的生态，导致出现了Celey这种一骑绝尘的任务队列框架，虽然我们可以找到一些比较冷门的任务队列框架，但是能做到Celey如此可靠，功能繁多，并且仍然在不断维护的任务队列框架只有这一个了。

通常而言，实现一个能用的最基础的任务队列框架貌似并不是非常的复杂，我们只需要自己制定一套合适的协议，然后往rabbitmq或者redis维护一个队列，生产者源源不断的往队列里面扔任务，消费者不断轮询任务中是否有新的任务，有的话就拿出来消费，然后把执行结果扔进另外一个结果消息队列里面，生产者根据task_id或者什么东西的去结果队列里面拿到结果。

就这？你这方案保可行吗？

这话说的，我还能卖给你生方案蛋子？

如果大家对如何实现一套延时任务队列感兴趣的话，可以阅读以下有赞的这篇文章，个人感觉写的还是比较详细的：

传送门: tech.youzan.com/queuing_del…

回到正题，如果看过celery的源码，基本上都觉得实现一个类似功能的框架并没有那么容易，毕竟好家伙，celery的github仓库那代码量也是非常大的，如此多的代码量就只是为了实现一个任务队列？ 在除了任务的生产和消费之外，celery又为我们提供了哪些额外的高级特性已经容错措施？