rabbitMQ几种工作模式及策略分享

1、Work模式

一个生产者，多个消费者，每个消费者获取到的消息唯一。

1、 自动模式

消费者从消息队列获取消息后，服务端就认为该消息已经成功消费。

2、 手动模式

消费者从消息队列获取消息后，服务端并没有标记为成功消费

消费者成功消费后需要将状态返回到服务端

2、订阅模式

一个生产者发送的消息会被多个消费者获取。

生产者：可以将消息发送到队列或者是交换机。

消费者：只能从队列中获取消息。

如果消息发送到没有队列绑定的交换机上，那么消息将丢失。

3、路由模式

1、 发送消息到交换机并且要指定路由key

2、 消费者将队列绑定到交换机时需要指定路由key

4、通配符模式

将路由键和某模式进行匹配，此时队列需要绑定在一个模式上，“#”匹配一个词或多个词，“*”只匹配一个词。

5、RPC模式

(RPC) Remote Procedure Call Protocol 远程过程调用协议

在一个大型的公司，系统由大大小小的服务构成，不同的团队维护不同的代码，部署在不同的机器。但是在做开发时候往往要用到其它团队的方法，因为已经有了实现。但是这些服务部署不同的机器上，想要调用就需要网络通信，这些代码繁琐且复杂，一不小心就会写的很低效。RPC协议定义了规划，其它的公司都给出了不同的实现。比如微软的wcf，以及现在火热的WebApi。

在RabbitMQ中RPC的实现也是很简单高效的，现在我们的客户端、服务端都是消息发布者与消息接收者。

首先客户端通过RPC向服务端发出请求

我这里有一堆东西需要你给我处理一下，correlation_id：这是我的请求标识，erply_to：你处理完过后把结果返回到这个队列中。

服务端拿到了请求，开始处理并返回

correlation_id：这是你的请求标识 ，原封不动的给你。 这时候客户端用自己的correlation_id与服务端返回的id进行对比。是我的，就接收。

RabbitMQ可以通过三种方法部署分布式系统：集群、联盟（federation）和shovel。

集群通过连接多个机器组成单个逻辑中间服务器。机器之间通信要借助于Erlang的消息传输，要求集群中所有节点必须有相同的Erlang cookie；节点之间的网络必须是可靠的，且运行相同版本的RabbitMQ和Erlang。虚拟主机、交换机、用户信息和权限会自动镜像到集群中各个节点。队列可能位于单个节点或镜像到多个节点。连接到任意节点的客户端能够看到集群中所有队列，即使该队列不位于连接节点上。通常可以使用集群来提高可靠性和吞吐量，前提是在分布同一个区域内的机器，不支持网络分段。

联盟允许单台服务器上的交换机或队列接收发布到另一台服务器上交换机或队列的消息，可以是单独机器或集群。服务器之间通过AMQP协议通信，因此两个联盟交换机或联盟队列要求设置相应的用户权限。联盟交换机之间由单向点对点链接关联，默认消息只会由联盟链接转发一次，但允许有更复杂的路由拓扑来提高转发次数。消息也可以不进行转发；如果消息到达联盟交换机之后不会路由到队列，那么它再也不会被转发。联盟队列类似于单向点对点连接，消息会在联盟队列之间转发任意次，直到被消费者接受。通常使用联盟来连接internet上的中间服务器，用作订阅分发消息或工作队列。

shovel连接方式与联盟的连接方式类似，但它工作在更低层次。shovel接受队列上的消息，转发到另一台服务器上的交换机。shovel和联盟类似，但它比联盟提供更多控制。

联盟/shovel vs 集群：1）前者中间服务器逻辑分离，后者组成一个逻辑中间服务器；2）前者可以运行不同版本RabbitMQ和Erlang，后者要求RabbitMQ和Erlang的版本保持一致；3）前者可以分布在WAN上，采用AMQP协议通信，要求设置权限，后者必须分布在LAN上，结合Erlang内部节点通信，要求有相同的Erlang cookie；4）前者的拓扑结构可自行设计，链接可以单向或双向，后者要求节点之间必须保持双向链接；5）前者遵循CAP理论的可用性和分区容错性，后者遵循CAP理论的一致性和可用性（可选择一致性和分布容错性）；6）前者服务器中的交换机可以选择联盟或本地，后者孤注一掷；7）前者客户端只能看到所连接服务器上的队列，后者客户端可以看到所有节点的队列。