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