Celery:
Celery是基于Python开发的分布式任务队列。它支持使用任务队列的方式在分布的机器／进程／线程上执行任务调度。
1、 celery工作流程：
消息中间件（message broker）：Celery本身不提供消息服务，但是可以方便的和第三方提供的消息中间件集成。包括，RabbitMQ, Redis, MongoDB ，SQLAlchemy等，其中rabbitm与redis比较稳定，其他处于测试阶段。
任务执行单元（worker）：Worker是Celery提供的任务执行的单元，worker并发的运行在分布式的系统节点中。
任务结果存储（result store）：result store用来存储Worker执行的任务的结果，支持AMQP，redis，mongodb，mysql等主流数据库。
2、并发、序列化、压缩:
celery任务并发执行支持prefork、eventlet、gevent、threads的方式；
序列化支持pickle,json,yaml,msgpack等；
压缩支持zlib, bzip2 。
3、celery使用中的一些建议和优化
（1）、如果你的broker使用的是rabbitmq，可安装一个C语言版的客户端librabbitmq来提升性能， pip install librabbitmq；
（2）、通过 BROKER_POOL_LIMIT 参数配置消息中间件的连接池；
（3）、通过CELERYD_PREFETCH_MULTIPLIER 参数配置消息预取的数量，如果消息队列中有很多消息，这个值建议设为1，以达到各个worker的最大化利用；
（4）、指定worker消费的队列，如果你根据业务配置了多个不同的消息队列，各个队列的任务量大小不同，可以在worker启动时指定消费队列 celery -A app_name -l INFO -Q queue1,queue2
（5）、worke（prefork）默认启动cpu核数个子进程，进程管理可以使用supervisor，supervisor是用Python开发的一套通用的进程管理程序，能将一个普通的命令行进程变为后台daemon，并监控进程状态，异常退出时能自动重启
rabbitmq：
- AMQP，即AdvancedMessage Queuing Protocol，高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。消息中间件主要用于组件之间的解耦，消息的发送者无需知道消息使用者的存在，反之亦然。
- AMQP的主要特征是面向消息、队列、路由（包括点对点和发布/订阅）、可靠性、安全。
- RabbitMQ是一个开源的AMQP实现，服务器端用Erlang语言编写，支持多种客户端，如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP等，支持AJAX。用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗
1、queue、channel
- Queue（队列）是RabbitMQ的内部对象，用于存储消息。
- Channel是我们与RabbitMQ打交道的最重要的一个接口，我们大部分的业务操作是在Channel这个接口中完成的，包括定义Queue、定义Exchange、绑定Queue与Exchange、发布消息等。
2、exchange
- 生产者不是将消息直接放到queue（队列）中，而是先到exchange中，exchange主要用于控制消息到队列的路由,根据具体的exchange type将消息传给需要的队列或者直接废弃。
- RabbitMQ常用的ExchangeType有fanout、direct、topic、headers这四种，不同的类型有着不同的路由策略。
（1）fanout-exchange: fanout类型的Exchange路由规则非常简单，它会把所有发送到该Exchange的消息路由到所有与它绑定的Queue中；
（2）direct-exchange：direct类型的Exchange路由规则也很简单，它会把消息路由到那些bindingkey与routingkey完全匹配的Queue中；
（3）topic-exchange：前面讲到direct类型的Exchange路由规则是完全匹配bindingkey与routingkey，但这种严格的匹配方式在很多情况下不能满足实际业务需求。topic类型的Exchange在匹配规则上进行了扩展，它与direct类型的Exchage相似，也是将消息路由到bindingkey与routingkey相匹配的Queue中，但这里的匹配规则有些不同，它约定：
a.routing key为一个句点号“.”分隔的字符串（我们将被句点号 “. ”分隔开的每一段独立的字符串称为一个单词），如“stock.usd.nyse”、“nyse.vmw”、“quick.orange.rabbit”
b.binding key与routingkey一样也是句点号“.”分隔的字符串
c.binding key中可以存在两种特殊字符“*”与“#”，用于做模糊匹配， 其中“*”用于匹配一个单词，“#”用于匹配多个单词（可以是零个）
rabbitMQ和redis用作消息队列的区别:
可靠性:
- redis ：没有相应的机制保证消息的可靠消费，如果发布者发布一条消息，而没有对应的订阅者的话，这条消息将丢失，不会存在内存中；
- rabbitMQ：具有消息消费确认机制，如果发布一条消息，还没有消费者消费该队列，那么这条消息将一直存放在队列中，直到有消费者消费了该条消息，以此可以保证消息的可靠消费
实时性:
- redis:实时性高，redis作为高效的缓存服务器，所有数据都存在在服务器中，所以它具有更高的实时性
消费者负载均衡：
- redis发布订阅模式，一个队列可以被多个消费者同时订阅，当有消息到达时，会将该消息依次发送给每个订阅者；
- rabbitMQ队列可以被多个消费者同时监控消费，但是每一条消息只能被消费一次，由于rabbitMQ的消费确认机制，因此它能够根据消费者的消费能力而调整它的负载；
持久性:
- redis：redis的持久化是针对于整个redis缓存的内容，它有RDB和AOF两种持久化方式（redis持久化方式，后续更新），可以将整个redis实例持久化到磁盘，以此来做数据备份，防止异常情况下导致数据丢失。
- rabbitMQ：队列，消息都可以选择性持久化，持久化粒度更小，更灵活；
队列监控:
- rabbitMQ实现了后台监控平台，可以在该平台上看到所有创建的队列的详细情况，良好的后台管理平台可以方便我们更好的使用；
- redis没有所谓的监控平台。
总结:
- redis： 轻量级，低延迟，高并发，低可靠性；
- rabbitMQ：重量级，高可靠，异步，不保证实时；
- rabbitMQ是一个专门的AMQP协议队列，他的优势就在于提供可靠的队列服务，并且可做到异步，而redis主要是用于缓存的，redis的发布订阅模块，可用于实现及时性，且可靠性低的功能。
RabbitMQ与Redis队列对比(转载):
RabbitMQ
RabbitMQ是实现AMQP（高级消息队列协议）的消息中间件的一种，最初起源于金融系统，用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。消息中间件主要用于组件之间的解耦，消息的发送者无需知道消息使用者的存在，反之亦然。
Redis
是一个Key-Value的NoSQL数据库，开发维护很活跃，虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。
具体对比
可靠消费
Redis：没有相应的机制保证消息的消费，当消费者消费失败的时候，消息体丢失，需要手动处理
RabbitMQ：具有消息消费确认，即使消费者消费失败，也会自动使消息体返回原队列，同时可全程持久化，保证消息体被正确消费
可靠发布
Reids：不提供，需自行实现
RabbitMQ：具有发布确认功能，保证消息被发布到服务器
高可用
Redis：采用主从模式，读写分离，但是故障转移还没有非常完善的官方解决方案
RabbitMQ：集群采用磁盘、内存节点，任意单点故障都不会影响整个队列的操作
持久化
Redis：将整个Redis实例持久化到磁盘
RabbitMQ：队列，消息，都可以选择是否持久化
消费者负载均衡
Redis：不提供，需自行实现
RabbitMQ：根据消费者情况，进行消息的均衡分发
队列监控
Redis：不提供，需自行实现
RabbitMQ：后台可以监控某个队列的所有信息，（内存，磁盘，消费者，生产者，速率等）
流量控制
Redis：不提供，需自行实现
RabbitMQ：服务器过载的情况，对生产者速率会进行限制，保证服务可靠性
出入队性能
对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。
测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。
Redis：轻量级，高并发，延迟敏感
即时数据分析、秒杀计数器、缓存等
RabbitMQ：重量级，高并发，异步
批量数据异步处理、并行任务串行化，高负载任务的负载均衡等