消息代理RabbitMQ——实施篇

1系统设计

本此实施采用B/S架构设计模式进行开发。但是不同的是，我们除了测试的时候需要用到前段界面的Ajax异步代码，其他时候并没有前端存在的意义。

Fanout接口，生产者的接口指定为4个参数，islasting、message、exchange、queue。其中islasting参数为boolean类型变量，表示传递的消息是否持久化于队列中。message即为需要传递消息的字符串类型变量。exchange为我们发布消息所用到的转换器。queue表示消息需要发布到的指定的队列名。而对于消费者的入口参数和生产者唯一不同的是，没有message参数。因为我们只要确定了其他三个参数，便可得到对应的消息。

Direct接口，生产者的接口指定为5个参数，islasting、message、exchange、queue和binding。前面四个参数与Fanout相同，binding代表的是“绑定”。只有生产者发布了一条消息，并且用binding变量进行约束以后，消费者同样用binding进行约束，才能接收到消息。这种方式是一种定向型的发布订阅方式，但只有单一消费者的情况下，其效果和Fanout相同。但是有多个消费者的情况下，所有具有相同binding约束的消费者都会收到同样的消息，这就是生活中的群发概念的实现。消费者接口同上。

Topic接口，生产者的接口指定为5个参数，islasting、message、exchange、queue和matching。matching在生产者中和消费者中的含义不同。在生产者中，表示一个完全标识，例如发布一条标识为“news.orange”的消息，“news.orange”即代表matching。在消费者中，该变量标识一种模式匹配，即消费者可以用值为“news.*”的变量接收所有以“news.”标识开头的消息进行消费。这是一个需要区分的地方。

RPC接口，该类型接口不涉及生产者的接口，因为生产者同时可以认为是消费者，或者说生产者不可见。该类型的功能描述的是消费者需要获得某种数据，但是没有生产者为其提供，但又不得不需要。所以通过远程调用的方式通知生产者发布一条自己需要的数据并返回，通过这种方式消费消息。其参数可以简化为1个，即需要生产者加工的数据源。以Fanout为例：

  &nb