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：重量级，高并发，异步
批量数据异步处理、并行任务串行化，高负载任务的负载均衡等
322
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
