消息队列和Celery
消息队列（Message Queue，简称MQ）提供异步通信协议。可以实现进程间通信或同一进程的不同线程间通信：其中“消息”是指包含必要信息的数据。消息的发送者发送完毕后立即返回，消息被存储进队列中，对这个消息感兴趣的消费者会订阅消息并接收和处理它。
使用消息队列的好处如下：
- 应用解耦。消息是平台无关和语言无关的，消息队列可以应对多变的产品变更。
- 异步通信。可以缩短请求等待的时间，使用专门处理请求的消费者来执行，提高Web页面的吞吐量。尤其是瞬间发生的高流量情况，消息队列非常有助于顶住访问压力。
- 数据持久化。未完成的消息不会因为某些故障而丢失。
- 送达保证。消息队列提高的冗余机制保证了消息确实能被处理。除非消费者明确表示已经处理完这个消息，否则这个消息可以被放回队列中以备其他消费者处理。
本章主要包含以下内容：
- 使用Beanstalkd。
- 解释AMQP，深入理解RabbitMQ，介绍RabbitMQ插件系统，RabbitMQ集群的故障转移方法等。
- 介绍Celery的架构，运行起一个真实的应用，在Flask应用中使用Celery等功能。
- 深入Celery，介绍Celery的依赖及独立用法、Worker管理、监控等高级功能。
- 一些实践经验
使用Beanstalkd
Beanstalkd是消息队列的后起之秀,它是一个高性能、轻量级的分布式内存队列系统，最初设计的目的是想通过后台异步执行耗时的任务来降低Web应用的页面访问延迟。
Beanstalkd有如下特点：
- 可持久化。Beanstalkd运行使用内存，但也提供了持久性支持。启动时用-b指定持久化目录，它会将所有的任务写入binlog文件。在发生断电等情况后，用同样的参数指定重启它，它将恢复binlog中的内存。
- 支持任务优先级。值越小优先级越高。
- 任务超时重发。消费者必须在预设的TTR（Time To Run）时间内发送delete/release/bury改变任务状态，否则它会认为消息处理失败，把任务交给别的消费者节点执行。
- 支持任务预留。如果任务因为某些原因无法执行，消费者可以把任务置为buried状态保留这些任务。
- 支持分布式。客户端可以实现和Memcached一样的分布式。
- 灵活设置任务过期和TTR时间。
job就是待异步执行的任务，也就是消息，是Beanstalkd中的基本单元。一个job通过生产者使用put命令时创建，然后被放在一个管道（tube）中。在整个生命周期中job可能有4个工作状态。
- ready：等待被取出并处理。
- reserved： 如果job被消费者（worker）取出，将被此消费者预定，消费者将执行此job。
- delayed：等待特定时间之后，状态再改为ready状态。
- buried：等待唤醒，通常在job处理失败时，会变成这个状态。
一个服务器有一个或者多个管道，管道用来存储统一类型的job。每个管道由一个就绪队列与延迟队列组成。每个job所有的状态迁移在一个管道中完成。消费者监控/取消监控感兴趣的管道。当一个客户端连接上服务器时，客户端监控的管道默认为default，如果客户端提交任务时没有使用use命令，那么这些job就存于名为default的管道中。管道都是按需求创建的，无论它们在什么时候被引用到。如果一个管道变为空也没有任何客户端引用，它将会被自动删除。
信号系统
Celery支持7种信号类型：
1. 任务信号。
2. 应用信号
3. Worker信号
4. Beat信号
5. Eventlet信号
6. 日志信号
7. 命令信号