Go语言系列之RabbitMQ消息队列 消息队列 rabbitmq

RabbitMQ

MQ

  消息队列（Message queue）是一种进程间通信或同一进程的不同线程间的通信方式，也是一种跨进程、异步的通信机制。就是说：消息的发送者和接收者不需要同时与消息队列互交。消息会保存在队列中，直到接收者取回它。

实现

消息队列常常保存在链表结构中。拥有权限的进程可以向消息队列中写入或读取消息。

广泛使用的消息队列有RabbitMQ 、 RocketMQ 、 ActiveMQ 、 Kafka 、 ZeroMQ 、 MetaMq等，而部分数据库如 Redis 、 Mysql 以及 phxsql 也可实现消息队列的功能。

队列：用来传递消息，发送者和接收者都是和队列进行交互的

消息中间件

MQ是遵循生产者-消费者典型模式的，一端往消息队列中写消息，一端从消息队列中读消息。而MQ则是遵循了AMQP协议的具体实现和产品。消息队列有两种方式：

区分AMQP和JMS

AMQP：是一种协议，是一个标准，具体的实现按照自己来就好。AMQP协议模型有三部分组成：生产者、消费者和服务端。

JMS：Java消息服务应用程序接口，

优点：应用解耦、异步处理、流量削锋

应用解耦：例如：用户注册用2秒就可以将出具存入数据库，为了增加用户体验，

就给用户发送邮件，先注册，发送邮件，存入数据库，一系列的时间花费9秒。

之后发送短信，先注册，发送短信，存入数据库等，花费12秒。这样的操作，代码修改的过高。只是为了提高用户的体验，耦合度过高，添加或修改功能时，原来的代码就得修改，响应时间过长。

解决：采用多线程，发送消息。消息队列，用户将数据给消息队列，消息队列调用邮件和短信，两个可以同时进行。注册和邮件的功能不受影响。复杂的异步封装起来。

异步处理：消息队列去找不同的执行功能，异步，两个可以同时进行

流量削锋：秒杀时，数据库扛不住，崩了，让消息按照业务规读取则进行排队，再找数据库去处理。先读500，读完之后，可以再读500.

使用场景：当不需要立即获得结果，但是并发量又需要进行控制的时候，差不多就是需要使用消息队列的时候

AMQP：高级消息队列协议，主要特征是面向消息，队列，路由，可靠性，安全。

RabbitMQ是一个开源的AMQP实现，服务器端用Erlang语言编写，支持多种客户端，如： Python 、 Ruby 、 .NET 、 Java 、 JMS 、 C 、 PHP 、 ActionScript 、 XMPP 、 STOMP 等，支持AJAX。用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。

总结如下：

• 基于AMQP协议
• 高并发(是一个容量的概念，服务器可以接受的最大任务数量)
• 高性能(是一个速度的概念，单位时间内服务器可以处理的任务数)
• 高可用(是一个持久的概念，单位时间内服务器可以正常工作的时间比例)
• 强大的社区支持，以及很多公司都在使用
• 支持插件
• 支持多语言

  生产者是投递消息的一方，首先连接到Server，建立一个连接，开启一个信道；然后生产者声明交换器和队列，设置相关属性，并通过路由键将交换器和队列进行绑定。同理，消费者也需要进行建立连接，开启信道等操作，便于接收消息。

  接着生产者就可以发送消息，发送到服务端中的虚拟主机，虚拟主机中的交换器根据路由键选择路由规则，然后发送到不同的消息队列中，这样订阅了消息队列的消费者就可以获取到消息，进行消费。

最后还要关闭信道和连接。

RabbitMQ是基于AMQP协议实现的，和AMQP协议简直就是一模一样。

RabbitMQ常用交换机类型

RabbitMQ常用的交换器类型有direct、topic、fanout、headers四种。

ConnectionFactory、Connection、Channel

ConnectionFactory、Connection、Channel都是RabbitMQ对外提供的API中最基本的对象。Connection是RabbitMQ的socket链接，它封装了socket协议相关部分逻辑。ConnectionFactory为Connection的制造工厂。 Channel是我们与RabbitMQ打交道的最重要的一个接口，我们大部分的业务操作是在Channel这个接口中完成的，包括定义Queue、定义Exchange、绑定Queue与Exchange、发布消息等。

RabbitMQ模式

简单队列模式

一个生产者生产消息，将消息发送到队列中之后，供消费者去消费

一个发送者和一个接收者

问题：如果任务量很大，消息得不到及时的消费会造成队列积压，问题非常严重，比如内存溢出，消息丢失等。

解决：配置多个消费者消费消息。

总结：简单队列-处理消息效率不高，吞吐量较低，不适合生成环境

优点：简单

缺点：生产者生产的消息过多，消费者消费的消息过少，消息堆积过多。

work—queues工作模式队列

1.工作模式队列-消息轮询分发(Round-robin)

  实际生活中会遇到：注册一个平台，用户如果注册成功，就会给用户发送消息，这个时候，发送的消息量可能比较大，同一个时刻可能存在很多用户去注册这个平台，因此，单个消费者去处理消息就比较慢，会给节点带来压力，导致消息堆积越来越多。对于这种情况，RabbitMQ 提供了工作队列模式，通过工作队列提供做个消费者，对MQ产生的消息进行消费，提高MQ消息的吞吐率，降低消息的处理时间。

自动确认改为手动确认，确认的消息是不是多条。添加手动确认的标识

消费者一人一个的去消费

优点：解决的了简单队列的缺点

缺点：消费者的能力又高又低，如果添加线程睡眠，有的消费慢有的消费快，消费水平按照低的算，速度快的结束之后，资源浪费。

2.工作模式队列-消息公平分发(fair dispatch)

我们使用basicQos(prefetchCount = 1) 方法，来限制RabbitMQ只发不超过1条的消息给同一个消费者。当消息处理完毕后，有了反馈，才会进行第二次发送。

每次只接收一条消息，只有就收完之后才能就收下一条消息。能者多劳

Publish/Subscribe-消息的发布与订阅模式队列

  对于微信公众号，相信每个人都订阅过，当公众号发送新的消息后，对于订阅过该公众号的所有用户均可以收到消息，这个场景大家都能明白，同样对于RabbitMQ消息的处理也支持这种消息处理，当生产者把消息投送出去后，不同的消费者均可以对该消息进行消费，而不是消息被一个消费者消费后就立即从队列中删除，对于这种消息处理，我们通常称之为消息的发布与订阅模式，凡是消费者订阅了该消息，均能够收到对应消息进行处理，比较常见的如用户注册操作。

广播模式：交换机将消息发给所有的队列，队列发给消费者（fanout 模式）

• 消息产生后不是直接投送到队列中，而是将消息先投送给Exchange交换机，然后消息经过Exchange交换机投递到相关队列
• 多个消费者消费的不再是同一个队列，而是每个消费者消费属于自己的队列。

添加了交换机，发到交换机，经过交换机发送给不同的队列，最后再将消息发给不同的消费者

不再绑定队列，绑定的是交换机，直接发给交换机，生成排他队列

Routing路由模式队列

  针对不同的消息，在对消息进行消费时，通过 Exchange types 以及 Routing key 设置的规则 ，便可以将不同消息路由到不同的队列中然后交给不同消费者进行消费操作。

（直连模式）

例如：公众号的会员模式，会员可以看到付费文章和免费文章，普通用户只能看到免费文章。

1. 生产者产生的消息投给交换机
2. 交换机投送消息时的Exchange Types为direct类型
3. 消息通过定义的Routing Key被路由到指定的队列进行后续消费

通过routing key ，发送不同的消息，消息绑定了不同的路由Key，发送给交换机，交换机将消息发送给不同的队列中，再发送给消费者。

发送的消息要携带路由Key，消费者绑定队列的时候，要把交换机和队列一起绑定上。

如果交换机传参时是空的，就会默认是AMQP的交换机。如果真找不到，那么 消息就会丢弃。

优点：满足了业务的需求，想让谁接收就让谁接收，资源不再浪费

缺点：多了路由件，项目较小时易于管理，项目大，路由件比较多的时候，难以管理，匹配难度大，

Topic主题模式队列

对于routing key匹配模式定义规则举例如下:

• routing key为一个句点号 . 分隔的字符串（我们将被句点号 . 分隔开的每一段独立的字符串称为一个单词），如“stock.usd.nyse”、“nyse.vmw”、“quick.orange.rabbit”
• routing key中可以存在两种特殊字符 * 与 # ，用于做模糊匹配，其中 * 用于匹配一个单词， # 用于匹配多个单词（可以是零个）

如果一个routing key在同一个队列中匹配了多次，那么也只能发送一个。都不匹配的话，消息就会丢失。发送者需要发送完整的，不能用*和#。

优点：解决了路由模式的问题，可以进行匹配，易于管理。

RPC-远程过程调用模式队列

RabbitMQ是异步的 ，RPC是同步的。

MQ本身是基于异步的消息处理，前面的示例中所有的生产者（P）将消息发送到RabbitMQ后不会知道消费者（C）处理成功或者失败（甚至连有没有消费者来处理这条消息都不知道）。但实际的应用场景中，我们很可能需要一些同步处理，需要同步等待服务端将我的消息处理完成后再进行下一步处理。这相当于RPC（Remote Procedure Call，远程过程调用）。在RabbitMQ中也支持RPC。

客户端和消费端有两种角色，分别会是生产者和消费者。

例如：送外卖事件，消费者告诉店家地址和联系电话，收到消息后，开始做饭。之后，外卖小哥根据发送过来的地址进行配送，再根据联系电话进行唯一标识的配送。

RabbitMQ中实现RPC的机制是：

1. 客户端发送请求（消息）时，在消息的属性（MessageProperties，在AMQP协议中定义了14种 properties，这些属性会随着消息一起发送）中设置两个值 replyTo （一个Queue名称，用于告诉服务器处理完成后将通知我的消息发送到这个Queue中）和 correlationId （此次请求的标识号，服务器处理完成后需要将此属性返还，客户端将根据这个id了解哪条请求被成功执行了或执行失败）
2. 服务器端收到消息并处理
3. 服务器端处理完消息后，将生成一条应答消息到 replyTo 指定的Queue，同时携带correlationId 属性

客户端之前已订阅 replyTo 指定的Queue，从中收到服务器的应答消息后，根据其中的correlationId 属性分析哪条请求被执行了，根据执行结果进行后续业务处理。

RabbitMQ消息的事务机制

  在使用RabbitMQ的时候，我们可以通过消息持久化操作来解决因为服务器的异常奔溃导致的消息丢失，发送消息的时候，传递的参数中有持久化的参数，是一个boolean类型。消费者中还有自动收到消息的确认。也是Boolean类型的。

  除此之外我们还会遇到一个问题，当消息的发布者在将消息发送出去之后，消息到底有没有正确到达broker代理服务器呢？如果不进行特殊配置的话，默认情况下发布操作是不会返回任何信息给生产者的，也就是默认情况下我们的生产者是不知道消息有没有正确到达broker的，如果在消息到达broker之前已经丢失的话，持久化操作也解决不了这个问题，因为消息根本就没到达代理服务器，你怎么进行持久化，那么这个问题该怎么解决呢？

生产者到消费者的过程中，怎么确认消息精准送到队列当中呢？RabbitMQ为我们提供了两种方式：

• 通过AMQP事务机制实现，这也是AMQP协议层面提供的解决方案；
• 通过将channel设置成confirm模式来实现；

11.1. AMQP事务机制控制

  RabbitMQ中与事务机制有关的方法有三个： txSelect() , txCommit() 以及 txRollback()。txSelect()用于将当前channel设置成transaction模式

txCommit()用于提交事务

txRollback() 用于回滚事务

  在通过txSelect() 开启事务之后，我们便可以发布消息给broker代理服务器了，如果txCommit() 提交成功了，则消息一定到达了broker（队列）了，如果在txCommit()执行之前broker（队列）异常崩溃或者由于其他原因抛出异常，这个时候我们便可以捕获异常通过txRollback()回滚事务。

  事务确实能够解决producer与broker（队列）之间消息确认的问题，只有消息成功被broker（队列）接受，事务提交才能成功，否则我们便可以在捕获异常进行事务回滚操作同时进行消息重发，但是使用事务机制的话会降低RabbitMQ的性能，那么有没有更好的方法既能保障producer知道消息已经正确送到，又能基本上不带来性能上的损失呢？从AMQP协议的层面看是没有更好的方法，但是RabbitMQ提供了一个更好的方案，即将channel信道设置成confirm模式。

通过事务确保生产者把消息发送给队列。使用事务降低了RabbitMQ的性能。可以利用confirm确认模式。

confirm确认模式

  通过AMQP协议层面为我们提供了事务机制解决了这个问题，但是采用事务机制实现会降低RabbitMQ的消息吞吐量，此时处理AMQP协议层面能够实现消息事物控制外，我们还有第二种方式即:Confirm模式。

Confirm确认模式原理

  生产者将信道设置成confirm模式，一旦信道进入confirm模式，所有在该信道上面发布的消息都会被指派一个唯一的ID(从1开始)，一旦消息被投递到所有匹配的队列之后，broker就会发送一个确认给生产者（包含消息的唯一ID）,这就使得生产者知道消息已经正确到达目的队列了，如果消息和队列是可持久化的，那么确认消息会将消息写入磁盘之后发出，broker回传给生产者的确认消息中deliver-tag域包含了确认消息的序列号，此外broker也可以设置basic.ack的multiple域，表示到这个序列号之前的所有消息都已经得到了处理。

  confirm模式最大的好处在于他是异步的，一旦发布一条消息，生产者应用程序就可以在等信道返回确认的同时继续发送下一条消息，当消息最终得到确认之后，生产者应用便可以通过回调方法来处理该确认消息，如果RabbitMQ因为自身内部错误导致消息丢失，就会发送一条nack消息，生产者应用程序同样可以在回调方法中处理该nack消息。

  在channel 被设置成 confirm 模式之后，所有被 publish 的后续消息都将被 confirm（即 ack） 或者被nack一次。但是没有对消息被 confirm 的快慢做任何保证，并且同一条消息不会既被 confirm又被nack 。

注意:两种事物控制形式不能同时开启！

Confirm确认机制代码实现

实现生产者confirm 机制有三种方式:

• 普通confirm模式：每发送一条消息后，调用waitForConfirms()方法，等待服务器端confirm。再发下一条消息。实际上是一种串行confirm了。
• 批量confirm模式：每发送一批消息后，调用waitForConfirmsOrDie()方法，等待服务器端confirm。串行confirm
• 异步confirm模式：提供一个回调方法，服务端confirm了一条或者多条消息后Client端会回调这个方法。确认

同步Confirm

  使用同步的方式需要等所有的消息发送成功以后才会执行后面代码，只要有一个消息未被确认就会抛出IO异常。解决办法可以使用异步确认。

  需要开启确认模式。有单条模式和批量模式。批量模式时，只有全部收到的时候，才会确认，如果没有满足，那么就会抛出异常。

异步confirm

  异步confirm模式的编程实现最复杂，Channel对象提供的ConfirmListener()回调方法只包含deliveryTag（当前Chanel发出的消息序号），

我们需要自己为每一个Channel维护一个unconfirm的消息序号集合，每publish一条数据，集合中元素加1，每回调一次 handleAck方法， unconfirm集合删掉相应的一条 （multiple=false） 或多条 （multiple=true） 记录。从程序运行效率上看，这个 unconfirm集合最好采用有序集合SortedSet存储结构。实际上， waitForConfirms()方法也是通过SortedSet维护消息序号的。

优点：异步模式的优点就是执行效率高，不需要等待消息执行完，只需要监听消息即可。基本上都是多条确认，单条确认很少。

生产者一下子发送很多条信息，生产者里面有一个回调方法，回调方法能够确认你的信息，有一个SortedSet集合，每次发送一个，都会有唯一一个标识，回调的监听里面会有一个这个序号，

当发送消息，就把消息序号存放在SortedSet集合里面，当监听确认的时候，就会删除在里面存放的序号。