在上一篇文章中，我们对之前的日志系统进行了改进，使用direct类型的exchange替代了只能广播消息的fanout类型，让日志系统能够有选择性的接收处理消息。
虽然使用direct类型的exchange提升了日志系统的扩展性，但还是有它的局限性存在，那就是无法配置多重标准的路由。
如果想让系统不能仅根据日志级别来定义，还能根据发送日志的源信息来订阅。如unix工具syslog，就是根据日志级别(info/warn/crit..)和设备(auth/cron/kern)来进行路由的。这会提供更多的灵活性，如可以做到监听所有来自'cron'和'kern'设备的error信息。
为了实现这种灵活性，需要来学习下另外一个功能更综合的topic类型的交换器(exchange).
在上一篇文章中，我们实现了一个可以广播消息给多个接收者的日志系统。在本篇中，将介绍如何对消息进行过滤，从而只处理我们感兴趣的消息。如只把一些严重的错误信息写入磁盘，但对所有类型的消息都打印到屏幕。
本系列摘自RabbitMQ官方教程，边学习边翻译的中文的版本，水平有限，不妥之处，欢迎交流。
在前一篇介绍中实现了一个工作队列，它假设队列中的每一个任务都只会被分发到一个工作者进行处理。在本篇中，我们尝试将同一个消息发送给多个消费者进行处理，这就是广为人知的发布/订阅模式。
本篇通过搭建一个日志系统来阐述发布/订阅模式，它包含两部分内容：一个用于产生日志消息的程序，另一个用于接收和打印消息。
在这个日志系统中，每一份接收者程序的拷贝都能收到消息，因此我们可以轻易地使用一个程序将日志写入磁盘，而另一个程序直接在屏幕显示。
本质上来说，当系统收到一个日志处理请求时，会把这个消息广播给所有的接收者。
本系列摘自RabbitMQ官方教程，边学习边翻译的中文的版本，水平有限，不妥之处，欢迎交流。
在上一篇介绍中我们实现了从消息产生程序发送简单消息到命名队列的过程，本篇将实现一个将耗时任务分发到多个消费者程序的工作队列。
工作队列的主要思想是避免对资源密集型任务处理时的等待，而是先将任务压入队列，后期再进行计划处理。我们将任务封装成消息发送给队列，由队列程序按策略分发到所有的在线工作者程序执行。当有多个工作程序同时在线时，多项任务同时被多个不同的工作者处理便成为可能。
在Web应用程序领域，如果需要在一个HTTP短连接中完成一些复杂的耗时任务时，工作队列的思想能大幅提高处理效率而带来了更好的用户体验。