rabbitmq功能总结和demo演示

MQ概念

MQ全称为Message Queue, 消息队列（MQ）是一种应用程序对应用程序的通信方法。应用程序通过读写出入队列的消息（针对应用程序的数据）来通信，而无需专用连接来链接它们。消息传递指的是程序之间通过在消息中发送数据进行通信，而不是通过直接调用彼此来通信，直接调用通常是用于诸如远程过程调用的技术。排队指的是应用程序通过 队列来通信。队列的使用除去了接收和发送应用程序同时执行的要求

MQ使用场景

1.异步处理

场景说明：用户注册后，需要发注册邮件和注册短信。

传统的做法：

(1)串行方式:将注册信息写入数据库后,发送注册邮件,再发送注册短信,以上三个任务全部完成后才返回给客户端。 这有一个问题是,邮件,短信并不是必须的,它只是一个通知,而这种做法让客户端等待没有必要等待的东西.

(2)并行方式:将注册信息写入数据库后,发送邮件的同时,发送短信,以上三个任务完成后,返回给客户端,并行的方式能提高处理的时间。

引入消息队列后，把发送邮件，短信不是必须的，业务逻辑异步处理，用户的响应时间就等于写入数据库的时间+写入消息队列的时间(可以忽略不计),引入消息队列后处理后,响应时间是串行的3倍,是并行的2倍。

2.应用解耦

场景：双11是购物狂节,用户下单后,订单系统需要通知库存系统。

传统的做法：订单系统调用库存系统的接口。这种做法有一个缺点:当库存系统出现故障时，订单就会失败。(这样马云将少赚好多好多钱^ ^)，订单系统和库存系统高耦合。

引入消息队列： 订单系统:用户下单后,订单系统完成持久化处理,将消息写入消息队列,返回用户订单下单成功。 库存系统:订阅下单的消息,获取下单消息,进行库操作。 就算库存系统出现故障,消息队列也能保证消息的可靠投递,不会导致消息丢失(马云这下高兴了).

3.流量削峰

场景:秒杀活动，一般会因为流量过大，导致应用挂掉,为了解决这个问题，一般在应用前端加入消息队列。

1.可以控制活动人数，超过此一定阀值的订单直接丢弃(我为什么秒杀一次都没有成功过呢^^)

2.可以缓解短时间的高流量压垮应用(应用程序按自己的最大处理能力获取订单)

实现：

1.用户的请求,服务器收到之后,首先写入消息队列,加入消息队列长度超过最大值,则直接抛弃用户请求或跳转到错误页面.

2.秒杀业务根据消息队列中的请求信息，再做后续处理.

rabbitmq概念

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

AMQP，即Advanced Message Queuing Protocol，高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。消息中间件主要用于组件之间的解耦，消息的发送者无需知道消息使用者的存在，反之亦然。

1.Queue

1.Queue（队列）是RabbitMQ的内部对象，用于存储消息。

2.RabbitMQ中的消息都只能存储在Queue中，生产者（下图中的P）生产消息并最终投递到Queue中，消费者（下图中的C）可以从Queue中获取消息并消费。

3.多个消费者可以订阅同一个Queue，这时Queue中的消息会被平均分摊给多个消费者进行处理，而不是每个消费者都收到所有的消息并处理。

2.Exchange

生产者将消息投递到Queue中，实际上这在RabbitMQ中这种事情永远都不会发生。实际的情况是，生产者将消息发送到Exchange（交换器，下图中的X），由Exchange将消息路由到一个或多个Queue中（或者丢弃）。

3.路由绑定规则

生产者在将消息发送给Exchange的时候，一般会指定一个routing key，来指定这个消息的路由规则，而这个routing key需要与Exchange Type及binding key联合使用才能最终生效。

在Exchange Type与binding key固定的情况下（在正常使用时一般这些内容都是固定配置好的），我们的生产者就可以在发送消息给Exchange时，通过指定routing key来决定消息流向哪里。RabbitMQ为routing key设定的长度限制为255 bytes。

RabbitMQ中通过Binding将Exchange与Queue关联起来，这样RabbitMQ就知道如何正确地将消息路由到指定的Queue了。

4.Exchange Types ： fanout

RabbitMQ常用的Exchange Type有fanout、direct、topic、headers这四种。 fanout类型的Exchange路由规则非常简单，它会把所有发送到该Exchange的消息路由到所有与它绑定的Queue中。

图中，生产者（P）发送到Exchange（X）的所有消息都会路由到图中的两个Queue，并最终被两个消费者（C1与C2）消费。

5.Exchange Types ： direct

direct类型的Exchange路由规则也很简单，它会把消息路由到那些binding key与routing key完全匹配的Queue中。

以图的配置为例，我们以routingKey=”error”发送消息到Exchange，则消息会路由到Queue1（amqp.gen-S9b…，这是由RabbitMQ自动生成的Queue名称）和Queue2（amqp.gen-Agl…）；如果我们以routingKey=”info”或routingKey=”warning”来发送消息，则消息只会路由到Queue2。如果我们以其他routingKey发送消息，则消息不会路由到这两个Queue中。

6.Exchange Types ： topic

topic类型的Exchange约定binding key中可以存在两种特殊字符“*”与“#”，用于做模糊匹配，其中“*”用于匹配一个单词，“#”用于匹配多个单词（可以是零个）。

以图中的配置为例，routingKey=”quick.orange.rabbit”的消息会同时路由到Q1与Q2，routingKey=”lazy.orange.fox”的消息会路由到Q1与Q2，routingKey=”lazy.brown.fox”的消息会路由到Q2，routingKey=”lazy.pink.rabbit”的消息会路由到Q2（只会投递给Q2一次，虽然这个routingKey与Q2的两个bindingKey都匹配）；routingKey=”quick.brown.fox”、routingKey=”orange”、routingKey=”quick.orange.male.rabbit”的消息将会被丢弃，因为它们没有匹配任何bindingKey。

7.Exchange Types ： headers

headers类型的Exchange不依赖于routing key与binding key的匹配规则来路由消息，而是根据发送的消息内容中的headers属性进行匹配。在绑定Queue与Exchange时指定一组键值对；当消息发送到Exchange时，RabbitMQ会取到该消息的headers（也是一个键值对的形式），对比其中的键值对是否完全匹配Queue与Exchange绑定时指定的键值对；如果完全匹配则消息会路由到该Queue，否则不会路由到该Queue。

如图的headers-type-queue队列，如果生产者发送消息的headers的值为{“headers-key”:”headers-value”}，则会路由到该队列

8.生产者confirm机制

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

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

9.消费者ack机制

在实际应用中，可能会发生消费者收到Queue中的消息，但没有处理完成就宕机（或出现其他意外）的情况，这种情况下就可能会导致消息丢失。为了避免这种情况发生，我们可以要求消费者在消费完消息后发送一个回执给RabbitMQ，RabbitMQ收到消息回执（Message acknowledgment）后才将该消息从Queue中移除；如果RabbitMQ没有收到回执并检测到消费者的RabbitMQ连接断开，则RabbitMQ会将该消息发送给其他消费者（如果存在多个消费者）进行处理。这里不存在timeout概念，一个消费者处理消息时间再长也不会导致该消息被发送给其他消费者，除非它的RabbitMQ连接断开。 这里会产生另外一个问题，如果我们的开发人员在处理完业务逻辑后，忘记发送回执给RabbitMQ，这将会导致严重的bug——Queue中堆积的消息会越来越多；消费者重启后会重复消费这些消息并重复执行业务逻辑…

10.Prefetch count

      prefetch允许为每个consumer指定最大的unacked messages数目，默认是1。简单来说就是用来指定一个consumer一次可以从Rabbit中获取多少条message并缓存在client中(RabbitMQ提供的各种语言的client library)。一旦缓冲区满了，Rabbit将会停止投递新的message到该consumer中直到它发出ack。      

假设prefetch值设为10，共有两个consumer。意味着每个consumer每次会从queue中预抓取 10 条消息到本地缓存着等待消费。同时该channel的unacked数变为20。而Rabbit投递的顺序是，先为consumer1投递满10个message，再往consumer2投递10个message。如果这时有新message需要投递，先判断channel的unacked数是否等于20，如果是则不会将消息投递到consumer中，message继续呆在queue中。之后其中consumer对一条消息进行ack，unacked此时等于19，Rabbit就判断哪个consumer的unacked少于10，就投递到哪个consumer中。    

  总的来说，consumer负责不断处理消息，不断ack，然后只要unacked数少于prefetch * consumer数目，broker就不断将消息投递过去。

11.持久化

     如果我们希望即使在RabbitMQ服务重启的情况下，也不会丢失消息，我们可以将Exchange、Queue与Message都设置为可持久化的（durable），这样可以保证绝大部分情况下我们的RabbitMQ消息不会丢失。消息持久化需要在消息生成时，添加参数 properties=pika.BasicProperties(delivery_mode=2)

 

rabbitmq进阶

 

1.根据业务，设计消息发布订阅模式

首先，整理划分数据领域，如下图      

根据划分的数据领域，采用topic模式可以灵活的满足需求，可以考虑给每个微服务定义一个或多个队列来消费消息。如图，生产者可以决定发送哪些领域的消息，每个队列可以决定自己订阅哪些领域的消息，每个微服务可以决定监听哪些队列。  

2.失败重试策略

在生产者发布消息，和消费者消费消息的时候，都有可能因为异常原因导致消息发布失败或者消费失败

可以考虑把失败的数据库存入数据库，然后使用这边的xxl-job进行补偿处理

3.延时队列(消息的TTL和死信Exchange)

场景一：物联网系统经常会遇到向终端下发命令，如果命令一段时间没有应答，就需要设置成超时。

场景二：订单下单之后30分钟后，如果用户没有付钱，则系统自动取消订单。 上述类似的需求是我们经常会遇见的问题。

最常用的方法是定期轮训数据库，设置状态。在数据量小的时候并没有什么大的问题，但是数据量一大轮训数据库的方式就会变得特别耗资源。当面对千万级、上亿级数据量时，本身写入的IO就比较高，导致长时间查询或者根本就查不出来，更别说分库分表以后了。除此之外，还有优先级队列，基于优先级队列的JDK延迟队列，时间轮等方式。但如果系统的架构中本身就有RabbitMQ的话，那么选择RabbitMQ来实现类似的功能也是一种选择。 使用RabbitMQ来实现延迟任务必须先了解RabbitMQ的两个概念：消息的TTL和死信Exchange

消息的TTL（Time To Live）

消息的TTL就是消息的存活时间。RabbitMQ可以对队列和消息分别设置TTL。对队列设置就是队列没有消费者连着的保留时间，也可以对每一个单独的消息做单独的设置。超过了这个时间，我们认为这个消息就死了，称之为死信。如果队列设置了，消息也设置了，那么会取小的。所以一个消息如果被路由到不同的队列中，这个消息死亡的时间有可能不一样（不同的队列设置）。这里单讲单个消息的TTL，因为它才是实现延迟任务的关键。

死信(Dead Letter Exchanges)

有两种情况会触发死信路由：1.消息的TTL到了，消息过期了；2.队列的长度限制满了。

排在前面的消息会被丢弃或者扔到死信路由上。 Dead Letter Exchange其实就是一种普通的exchange，和创建其他exchange没有两样。只是在某一个设置Dead Letter Exchange的队列中有消息过期了，会自动触发消息的转发，发送到Dead Letter Exchange中去。

延时队列的具体实现：

4.消息堆积解决方案

总结起来解决方案大体包括：

1.增加消费者的处理能力，多线程或多实例消费

2.升级硬件设备，提高单实例消费效率

3.考虑使用队列最大长度限制策略

4.给消息设置年龄，超时就丢弃策略

5.批量消费确认策略

 

5.日志集成：Trace

  rabbitmq的官网介绍了两种trace的方式，一种称之为“firehose”，另一个是rabbitmq_tracing插件。 这两种方式都能对经过rabbitmq的消息进行跟踪记录。

firehose

firehose的机制是将生产者投递给rabbitmq的消息，rabbitmq投递给消费者的消息按照指定的格式发送到默认的exchange上。这个默认的exchange的名称为amq.rabbitmq.trace，它是一个topic类型的exchange。发送到这个exchange上的消息的routing key为 publish.exchangename 和 deliver.queuename。其中exchangename和queuename为实际exchange和queue的名称，分别对应生产者投递到exchange的消息，和消费者从queue上获取的消息。

1.通过命令开启firehose，这个命令还可以通过参数 -p 指定 vhost。  

  

rabbitmqctl trace_on 

2.创建queue并绑定到exchange（amq.rabbitmq.trace）

3.往exchange（amq.rabbitmq.trace）发送消息

rabbitmq_tracing plugin

rabbitmq_tracing插件同样能跟踪rabbitmq中消息的流入流出情况，通过这个插件我们可以在管理界面上进行简单操作，rabbitmq会将消息的收发情况记录到日志中。

1.rabbitmq_tracing插件同样能跟踪rabbitmq中消息的流入流出情况，通过这个插件我们可以在管理界面上进行简单操作，rabbitmq会将消息的收发情况记录到日志中。

rabbitmq-plugins enable rabbitmq_tracing 

2.根据一定规则增加trace 3.发送消息

rabbitmq高级

1.rabbitmq连接多路复用原理

java NIO是IO的多路复用，Channel连接是TCP的多路复用。 NIO是服务器开启一个线程，在内核中使用select()进行轮询管理一些socket，当socket数据准备好时，会通知应用程序进行读写请求。channel复用TCP连接，是为了避免TCP连接创建和销毁的性能损耗，而多个channel使用一个tcp连接。 rabbitmq的connection连接池如下：

 

RabbitMQ官方提供了：

Connection对象，就是一个TCP连接对象。

Channels对象，虚拟连接。

虚拟连接建立在上面Connection对象的TCP连接中。数据流动都是在Channel中进行的。每个Connection对象的虚拟连接也是有限的，如果单个Connnection的Channel对象超出指定范围了，也会有性能问题，另外一个TCP连接上的多个虚拟连接，实际在传输数据时，传输数据的虚拟连接还是独占了TCP连接，其它虚拟连接在排队等待。 在一个Connection对象上创建多个Channel，然后程序发送数据时，分别共享使用创建好的Channel，但使用具体的单个Channel时，需要保障单个Chanel的线程独占性使用，不要让多个线程同时在使用某一个Channel，这样会导致并发错误。

java的jar包：spring-boot-starter-amqp很好的处理了上述问题。

详见解析amqp源码的文章：https://www.cnblogs.com/gordonkong/p/7051220.html

2.集群部署方式选择

普通集群：    

以两个节点（rabbit01、rabbit02）为例来进行说明。 rabbit01和rabbit02两个节点仅有相同的元数据，即队列的结构，但消息实体只存在于其中一个节点rabbit01（或者rabbit02）中。     当消息进入rabbit01节点的Queue后，consumer从rabbit02节点消费时，RabbitMQ会临时在rabbit01、rabbit02间进行消息传输，把A中的消息实体取出并经过B发送给consumer。即对于同一个逻辑队列，要在多个节点建立物理Queue。否则无论consumer连rabbit01或rabbit02，出口总在rabbit01，会产生瓶颈。当rabbit01节点故障后，rabbit02节点无法取到rabbit01节点中还未消费的消息实体。如果做了消息持久化，那么得等rabbit01节点恢复，然后才可被消费；如果没有持久化的话，就会产生消息丢失的现象。

镜像集群：  

  在普通集群的基础上，把需要的队列做成镜像队列，消息实体会主动在镜像节点间同步，而不是在客户端取数据时临时拉取，也就是说多少节点消息就会备份多少份。该模式带来的副作用也很明显，除了降低系统性能外，如果镜像队列数量过多，加之大量的消息进入，集群内部的网络带宽将会被这种同步通讯大大消耗掉。所以在对可靠性要求较高的场合中适用     由于镜像队列之间消息自动同步，且内部有选举master机制，即使master节点宕机也不会影响整个集群的使用，达到去中心化的目的，从而有效的防止消息丢失及服务不可用等问题

 对于消息的生产和消费者可以通过HAProxy的软负载将请求分发至RabbitMQ集群中的Node1～Node7节点，其中Node8～Node10的三个节点作为磁盘节点保存集群元数据和配置信息。

参考：https://www.jianshu.com/p/6376936845ff    

 

 

另外有springboot集成rabbitmq的代码，rabbitmq的常见功能都有用到，

有direct，fanout，topic，headers，死信队列，回调机制等代码演示。欢迎下载学习使用。

见：https://gitee.com/small_team123/springboot-rabbitmq