RabbitMQ下的生产消费者模式与订阅发布模式

所谓模式，就是在某种场景下，一类问题及其解决方案的总结归纳。生产消费者模式与订阅发布模式是使用消息中间件时常用的两种模式，用于功能解耦和分布式系统间的消息通信，以下面两种场景为例：

• 数据接入 

  

  生产消费者模式，数据上报为生产者，数据处理为消费者。

• 事件分发 订阅发布模式。

  

  可以看到，生产消费者模式与订阅发布模式都离不开消息中间件来作为消息中转站，开源的消息中间件有很多，各有优劣。本文将重点探讨RabbitMQ的特性，以及如何实现上述的两种场景。

RabbitMQ核心概念

  如果你只是想使用一下RabbitMQ，那么参考官方教程修改一下就可以跑起来了，很简单。如果你有一些概念上的疑惑，不妨与笔者一起来总结一下RabbitMQ的核心概念。

• 通信方式 

  

• 消息体 

• 消息投递 架构参见下图。细细品味就会体会到这样设计的精妙之处。

  

• 消息可靠性 

生产消费者模式

  搞清楚了RabbitMQ的核心概念，要针对特定的场景来设计使用方案就很简单了，基本上就是上述RabbitMQ架构图的变迁。让我们先来看看文章开头提到的“数据接入”场景，如何实现生产消费者模式。 

  这里增加了一下场景复杂度：对于上报的数据，如果是special的行为，需要优先处理。从上图可以看到，数据上报端负责将数据投递到RabbitMQ对应的Exchange，并指明routing_key是common还是special。数据处理端，可以根据情况启多个Woker来消费数据，但至少需要两个，一个用来处理common数据，一个用来处理special的数据。注意：当需要增加多个Worker来消费同一类数据时，需要保持Queue名字一致，比如上面的Common数据。

订阅发布模式

  再来看“事件分发”的场景，架构如下图所示，使用event name/id来作为RabbitMQ的routing key的名字。Event Processor 01对event 01 和event 02感兴趣，则在启动Consumer Worker时，将自己的Queue绑定到这两个routing key上即可，其他Event Processor也是如此，这样便完成了事件的订阅。当有事件发布时，消息便会按照event name/id被投递到对应的Queue中。 

  由此可见，在不同的应用中，变化的只是routing_key与Consumer Queue的绑定关系，在充分理解RabbitMQ的核心概念后处理这些应该也是得心应手了。

出处：http://blog.csdn.net/zwgdft/article/details/53561277