RabbitMq解析----shock wave 2

参考

中文文档rabbitmq.mr-ping.com/

RabbitMQ中文文档www.kancloud.cn/yunxifd/rab…

整体架构

主要应用

1、消息通信

消息队列最主要功能收发消息，其内部有高效的通讯机制，因此非常适合用于消息通讯。

2、异步处理

使用消息队列进行异步处理，可以更快地返回结果，加快服务器的响应速度，提升了服务器的性能。

3、服务解耦

在应用A与应用B之间引入消息队列进行服务解耦，如果应用B挂掉，也不会影响应用A的使用。

4、流量削峰

通过引入消息队列，可以有效缓冲突发流量，达到“削峰填谷”的作用。

核心概念

生产者（Producer）：发送消息的应用。

消费者（Consumer）：接收消息的应用。

队列（Queue）：存储消息的缓存。

消息（Message）：由生产者通过RabbitMQ发送给消费者的信息。

连接（Connection）：连接RabbitMQ和应用服务器的TCP连接。

通道（Channel）：连接里的一个虚拟通道。当你通过消息队列发送或者接收消息时，这个操作都是通过通道进行的。

交换机（Exchange）：交换机负责从生产者那里接收消息，并根据交换类型分发到对应的消息列队里。要实现消息的接收，一个队列必须到绑定一个交换机。

绑定（Binding）：绑定是队列和交换机的一个关联连接。

RabbitMQ五种消息发送模式

RabbitMQ包括五种队列模式，简单队列、工作队列、发布/订阅、路由、主题、rpc等。

简单模式

• 只有一个生产者、一个消费者和一个队列。
• 生产者和消费者在发送和接收消息时，只需要指定队列名，而不需要指定发送到哪个Exchange，RabbitMQ服务器会自动使用Virtual host的默认的Exchange，默认Exchange的type为direct。

工作模式

• 可以有多个消费者，但一条消息只能被一个消费者获取。
• 发送到队列中的消息，由服务器平均分配给不同消费者进行消费。

发布/订阅模式

• 发布/订阅模式中，Echange的type为fanout。
• 生产者发送消息时，不需要指定具体的队列名，Exchange会将收到的消息转发到所绑定的队列。
• 消息被Exchange转到多个队列，一条消息可以被多个消费者获取。

路由模式

• 路由模式下Exchange的type为direct。
• 消息的目标队列可以由生产者按照routingKey规则指定。
• 消费者通过BindingKey绑定自己所关心的队列。
• 一条消息队可以被多个消息者获取。
• 只有RoutingKey与BidingKey相匹配的队列才会收到消息。

主题模式

• 可以使用词匹配多个队列
• 主题模式Exchange的type取值为topic。
• 一条消息可以被多个消费者获取。

交换机类型

默认交换机

默认交换机（default exchange）实际上是一个由消息代理预先声明好的没有名字（名字为空字符串）的直连交换机（direct exchange）。它有一个特殊的属性使得它对于简单应用特别有用处：那就是每个新建队列（queue）都会自动绑定到默认交换机上，绑定的路由键（routing key）名称与队列名称相同。

举个栗子：当你声明了一个名为"search-indexing-online"的队列，AMQP代理会自动将其绑定到默认交换机上，绑定（binding）的路由键名称也是为"search-indexing-online"。因此，当携带着名为"search-indexing-online"的路由键的消息被发送到默认交换机的时候，此消息会被默认交换机路由至名为"search-indexing-online"的队列中。换句话说，默认交换机看起来貌似能够直接将消息投递给队列，尽管技术上并没有做相关的操作。

直连交换机

直连型交换机（direct exchange）是根据消息携带的路由键（routing key）将消息投递给对应队列的。直连交换机用来处理消息的单播路由（unicast routing）（尽管它也可以处理多播路由）。下边介绍它是如何工作的：

• 将一个队列绑定到某个交换机上，同时赋予该绑定一个路由键（routing key）
• 当一个携带着路由键为R的消息被发送给直连交换机时，交换机会把它路由给绑定值同样为R的队列。

直连交换机经常用来循环分发任务给多个工作者（workers）。当这样做的时候，我们需要明白一点，在AMQP 0-9-1中，消息的负载均衡是发生在消费者（consumer）之间的，而不是队列（queue）之间。

扇型交换机

扇型交换机（funout exchange）将消息路由给绑定到它身上的所有队列，而不理会绑定的路由键。如果N个队列绑定到某个扇型交换机上，当有消息发送给此扇型交换机时，交换机会将消息的拷贝分别发送给这所有的N个队列。扇型用来交换机处理消息的广播路由（broadcast routing）。

因为扇型交换机投递消息的拷贝到所有绑定到它的队列，所以他的应用案例都极其相似：

• 大规模多用户在线（MMO）游戏可以使用它来处理排行榜更新等全局事件
• 体育新闻网站可以用它来近乎实时地将比分更新分发给移动客户端
• 分发系统使用它来广播各种状态和配置更新
• 在群聊的时候，它被用来分发消息给参与群聊的用户。（AMQP没有内置presence的概念，因此XMPP可能会是个更好的选择）

主题交换机

主题交换机

主题交换机（topic exchanges）通过对消息的路由键和队列到交换机的绑定模式之间的匹配，将消息路由给一个或多个队列。主题交换机经常用来实现各种分发/订阅模式及其变种。主题交换机通常用来实现消息的多播路由（multicast routing）。

主题交换机拥有非常广泛的用户案例。无论何时，当一个问题涉及到那些想要有针对性的选择需要接收消息的 多消费者/多应用（multiple consumers/applications） 的时候，主题交换机都可以被列入考虑范围。

使用案例：

• 分发有关于特定地理位置的数据，例如销售点
• 由多个工作者（workers）完成的后台任务，每个工作者负责处理某些特定的任务
• 股票价格更新（以及其他类型的金融数据更新）
• 涉及到分类或者标签的新闻更新（例如，针对特定的运动项目或者队伍）
• 云端的不同种类服务的协调
• 分布式架构/基于系统的软件封装，其中每个构建者仅能处理一个特定的架构或者系统。

头交换机

有时消息的路由操作会涉及到多个属性，此时使用消息头就比用路由键更容易表达，头交换机（headers exchange）就是为此而生的。头交换机使用多个消息属性来代替路由键建立路由规则。通过判断消息头的值能否与指定的绑定相匹配来确立路由规则。

我们可以绑定一个队列到头交换机上，并给他们之间的绑定使用多个用于匹配的头（header）。这个案例中，消息代理得从应用开发者那儿取到更多一段信息，换句话说，它需要考虑某条消息（message）是需要部分匹配还是全部匹配。上边说的“更多一段消息”就是"x-match"参数。当"x-match"设置为“any”时，消息头的任意一个值被匹配就可以满足条件，而当"x-match"设置为“all”的时候，就需要消息头的所有值都匹配成功。

头交换机可以视为直连交换机的另一种表现形式。头交换机能够像直连交换机一样工作，不同之处在于头交换机的路由规则是建立在头属性值之上，而不是路由键。路由键必须是一个字符串，而头属性值则没有这个约束，它们甚至可以是整数或者哈希值（字典）等。

队列持久化

持久化队列（Durable queues）会被存储在磁盘上，当消息代理（broker）重启的时候，它依旧存在。没有被持久化的队列称作暂存队列（Transient queues）。并不是所有的场景和案例都需要将队列持久化。

持久化的队列并不会使得路由到它的消息也具有持久性。倘若消息代理挂掉了，重新启动，那么在重启的过程中持久化队列会被重新声明，无论怎样，只有经过持久化的消息才能被重新恢复。

绑定

绑定（Binding）是交换机（exchange）将消息（message）路由给队列（queue）所需遵循的规则。如果要指示交换机“E”将消息路由给队列“Q”，那么“Q”就需要与“E”进行绑定。绑定操作需要定义一个可选的路由键（routing key）属性给某些类型的交换机。路由键的意义在于从发送给交换机的众多消息中选择出某些消息，将其路由给绑定的队列。

消息确认

消费者应用（Consumer applications） - 用来接受和处理消息的应用 - 在处理消息的时候偶尔会失败或者有时会直接崩溃掉。而且网络原因也有可能引起各种问题。这就给我们出了个难题，AMQP代理在什么时候删除消息才是正确的？AMQP 0-9-1 规范给我们两种建议：

• 当消息代理（broker）将消息发送给应用后立即删除。（使用AMQP方法：basic.deliver或basic.get-ok）
• 待应用（application）发送一个确认回执（acknowledgement）后再删除消息。（使用AMQP方法：basic.ack）

前者被称作自动确认模式（automatic acknowledgement model），后者被称作显式确认模式（explicit acknowledgement model）。在显式模式下，由消费者应用来选择什么时候发送确认回执（acknowledgement）。应用可以在收到消息后立即发送，或将未处理的消息存储后发送，或等到消息被处理完毕后再发送确认回执（例如，成功获取一个网页内容并将其存储之后）。

如果一个消费者在尚未发送确认回执的情况下挂掉了，那AMQP代理会将消息重新投递给另一个消费者。如果当时没有可用的消费者了，消息代理会死等下一个注册到此队列的消费者，然后再次尝试投递。

消息队列事务

事务的实现主要是对信道(Channel)的设置，主要方法如下：

发送方：

• channel.txSelect()  声明启动事务模式
• channel.txCommit() 提交事务
• channel.txRollback()回滚事务

原理： 主要是commit提交到另外一个队列进行存储，如果事务确认之后，转移到消费队列进行消费，不成功需要失效rollback()方法进行回滚

消费者：

消费端必须使用手动确认，自动确认事务不会生效

补充

重复消费问题

• 使用唯一键判断是否已经被消费
• 使用消息id+redis解决重复消费问题
• 使用hash()+redis解决重复消费问题