RabbitMQ入门介绍

RabbitMQ入门

什么是MQ

MQ(Message Quene) : 翻译为 消息队列,通过典型的生产者和消费者模型,生产者不断向消息队列中生产消息，消费者不断的从队列中获取消息。因为消息的生产和消费都是异步的，而且只关心消息的发送和接收，没有业务逻辑的侵入,轻松的实现系统间解耦。别名为 消息中间件 通过利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。

MQ有哪些

当今市面上有很多主流的消息中间件，如老牌的ActiveMQ、RabbitMQ，炙手可热的Kafka，阿里巴巴自主开发RocketMQ等。

不同MQ特点

1.ActiveMQ

ActiveMQ 是Apache出品，最流行的，能力强劲的开源消息总线。它是一个完全支持JMS规范的的消息中间件。丰富的API,多种集群架构模式让ActiveMQ在业界成为老牌的消息中间件,在中小型企业颇受欢迎!

2.Kafka

Kafka是LinkedIn开源的分布式发布-订阅消息系统，目前归属于Apache顶级项目。Kafka主要特点是基于Pull的模式来处理消息消费，
追求高吞吐量，一开始的目的就是用于日志收集和传输。0.8版本开始支持复制，不支持事务，对消息的重复、丢失、错误没有严格要求，
适合产生大量数据的互联网服务的数据收集业务。

3.RocketMQ

RocketMQ是阿里开源的消息中间件，它是纯Java开发，具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。RocketMQ思路起
源于Kafka，但并不是Kafka的一个Copy，它对消息的可靠传输及事务性做了优化，目前在阿里集团被广泛应用于交易、充值、流计算、消
息推送、日志流式处理、binglog分发等场景。

4.RabbitMQ

RabbitMQ是使用Erlang语言开发的开源消息队列系统，基于AMQP协议来实现。AMQP的主要特征是面向消息、队列、路由（包括点对点和
发布/订阅）、可靠性、安全。AMQP协议更多用在企业系统内对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在
其次。

      RabbitMQ比Kafka可靠，Kafka更适合IO高吞吐的处理，一般应用在大数据日志处理或对实时性（少量延迟），可靠性（少量丢数据）要求稍低的场景使用，比如ELK日志收集。

RabbitMQ

基于AMQP协议，erlang语言开发，是部署最广泛的开源消息中间件,是最受欢迎的开源消息中间件之一。

   官网: https://www.rabbitmq.com/

   官方教程: https://www.rabbitmq.com/#getstarted

AMQP 协议

AMQP（advanced message queuing protocol）`在2003年时被提出，最早用于解决金融领不同平台之间的消息传递交互问题。顾名思义，AMQP是一种协议，更准确的说是一种binary wire-level protocol （链接协议）。这是其和JMS的本质差别，AMQP不从API层进行限定，而是直接定义网络交换的数据格式。这使得实现了AMQP的provider天然性就是跨平台的。以下是AMQP协议模型:

• Broker: 接收和分发消息的应用，RabbitMQ Server就是Message Broker。
• Virtual host:出于多租户和安全因素设计的，把AMQP的基本组件划分到一个虚拟的分组中，类似于网络中的namespace概念。当多个不同的用户使用同一个RabbitMQ
  server提供的服务时，可以划分出多个vhost，每个用户在自己的vhost创建exchange／queue等。
• Broker:Connection: publisher／consumer和broker之间的TCP连接。断开连接的操作只会在client端进行，Broker不会断开连接，除非出现网络故障或broker服务出现问题。
• Channel:如果每一次访问RabbitMQ都建立一个Connection，在消息量大的时候建立TCP Connection的开销将是巨大的，效率也较低。Channel是在connection内部建立的逻辑连接，如果应用程序支持多线程，通常每个thread创建单独的channel进行通讯，AMQP method包含了channel id帮助客户端和message broker识别channel，所以channel之间是完全隔离的。Channel作为轻量级的Connection极大减少了操作系统建立TCP connection的开销。
• Exchange: message到达broker的第一站，根据分发规则，匹配查询表中的routing
  key，分发消息到queue中去。常用的类型有：direct (point-to-point), topic
  (publish-subscribe) and fanout (multicast)。
• Queue: 消息最终被送到这里等待consumer取走。一个message可以被同时拷贝到多个queue中。
• **Binding: **exchange和queue之间的虚拟连接，binding中可以包含routing key。Binding信息被保存到exchange中的查询表中，用于message的分发依据。

RabbitMQ优劣势

• 优点
  • 应用异步
    • 就订单系统而言，下单成功后需要调用短信接口给用户发送下单成功的短信，一般的做法是在下单成功后直接调用短信接口给用户发送短信，但是如果调用的接口或者短信运营商出现问题，就会造成下单过程的阻塞，导致整个下单流程的不成功。我们引入RabbitMQ后可以对像发短信这样的不是必须的业务逻辑进行异步处理，就能有效的避免下单过程的阻塞。
  • 对系统解耦
    • 一般用户在下单成功后订单系统户调用库存系统来进行库存的减少，传统做法是下单成功后直接调用库存系统，这样做有两个问题：一.当库存系统出现问题就导致下单失败。二.订单系统和库存系统耦合性高。但是当我们引入RabbiMQ后，订单系统只需要把订单信息进行持久化，把消息存入消息队列，返回给用户下单成功的信息。对库存系统来说就是订阅下单信息，从消息队列中获取下单消息来进行库存的修改，当库存系统出现问题也会因为消息队列能保证消息的可靠投递，不会导致消息的丢失。
  • 对高并发流量进行削峰
    • 这边的流量削峰功能主要应用在秒杀活动中，在秒杀活动中一般因为流量过大，导致应用挂掉，为了解决这个问题，在应用前端、库存系统前端加入消息队列，在订单系统中，服务器收到用户的请求后，首先写入消息队列，超过消息队列的长度的用户请求，则被直接抛弃或者跳转到错误页面，这样可以控制活动人数；在接下来秒杀业务处理系统根据消息队列中的请求信息可以按照自己的最大处理能力获取订单，能有效的避免短时间内高流量涌入压垮应用的问题。
• 缺点
  • 增加系统的复杂性
    • 需要处理消息丢失
    • 消息的重复消费
    • 有些系统会对消息的顺序有要求这样就需要针对各队系统对消息顺序传递性问题的处理
  • 系统可用性降低
  • 系统增加了外部依赖越多，容易挂掉
    举例：以前是A系统直接调用BCD系统，现在在中加入了MQ，加入MQ挂掉了那整套系统就崩溃了。
  • 一致性问题
    • A系统处理成功后直接返回成功，接收到消息BC系统也写库成功，但是D系统处理写库失败，这个时候就造成了数据的不一致问题。

如何保证消息队列的高可用

（1）RabbitMQ的高可用性

   RabbitMQ是比较有代表性的，因为是基于主从做高可用性的，我们就以他为例子讲解第一种MQ的高可用性怎么实现。

   RabbitMQ有三种模式：单机模式，普通集群模式，镜像集群模式

1. 单机模式
         就是demo级别的，一般就是你本地启动了玩玩儿的，没人生产用单机模式
2. 普通集群模式
         意思就是在多台机器上启动多个rabbitmq实例，每个机器启动一个。但是你创建的queue，只会放在一个rabbtimq实例上，但是每个实例都同步queue的元数据。完了你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从queue所在实例上拉取数据过来。

      这种方式确实很麻烦，也不怎么好，没做到所谓的分布式，就是个普通集群。因为这导致你要么消费者每次随机连接一个实例然后拉取数据，要么固定连接那个queue所在实例消费数据，前者有数据拉取的开销，后者导致单实例性能瓶颈。

      而且如果那个放queue的实例宕机了，会导致接下来其他实例就无法从那个实例拉取，如果你开启了消息持久化，让rabbitmq落地存储消息的话，消息不一定会丢，得等这个实例恢复了，然后才可以继续从这个queue拉取数据。

      所以这个事儿就比较尴尬了，这就没有什么所谓的高可用性可言了，这方案主要是提高吞吐量的，就是说让集群中多个节点来服务某个queue的读写操作。

3. 镜像集群模式
         这种模式，才是所谓的rabbitmq的高可用模式，跟普通集群模式不一样的是，你创建的queue，无论元数据还是queue里的消息都会存在于多个实例上，然后每次你写消息到queue的时候，都会自动把消息到多个实例的queue里进行消息同步。

      这样的话，好处在于，你任何一个机器宕机了，没事儿，别的机器都可以用。坏处在于，第一，这个性能开销也太大了吧，消息同步所有机器，导致网络带宽压力和消耗很重！第二，这么玩儿，就没有扩展性可言了，如果某个queue负载很重，你加机器，新增的机器也包含了这个queue的所有数据，并没有办法线性扩展你的queue

      那么怎么开启这个镜像集群模式呢？我这里简单说一下，避免面试人家问你你不知道，其实很简单rabbitmq有很好的管理控制台，就是在后台新增一个策略，这个策略是镜像集群模式的策略，指定的时候可以要求数据同步到所有节点的，也可以要求就同步到指定数量的节点，然后你再次创建queue的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。

什么是死信？

当一条消息在队列中出现以下三种情况的时候，该消息就会变成一条死信。

• 消息被拒绝（basic.reject、basic,nack)，并且requeue=false。
• 消息的TTL（存活时间）过长
• 队列达到最大长度

当消息在一个队列中变成一个死信之后，如果配置了死信队列，他将被重新publish到死信交换机，死信交换机将死信投递到一个队列上，这个队列就是死信队列。

实现死信队列

工作模式

总共分为六大工作模式

• Work queues
  一个生产者，一个队列，多个消费者。
  消息不会被重复消费，只会发给某一个消费者，有点像负载均衡，默认轮询
• Publish/subscribe（发布订阅）
  一个生产者，一个交换机，多个队列，每个队列对应多个消费者
• Routing
  一个生产者，一个交换机，多个队列绑定不同的routingkey进行路由，每个队列对应多个消费者。
• Topics
  通配符工作模式，跟Routing模式很像，但是routingKey可以设置通配符
  Topics和Routing的routingKey匹配方式不同 前者可以模糊匹配，后者为等于
  通配符有两种，一种是#匹配一个或多个词，比如inform.#可匹配到inform.sms或者inform.email或者Inform.sms.email等，另一种是星号只能匹配一个词，比如inform.*可匹配到inform.sms、inform.email
• Header
  header模式与routing不同的地方在与header取消了routingKey，使用header中的key/value匹配队列
• RPC
  交换机的类型
  • BuiltinExchangeType类可以指定交换机类型
  • fanout：对应的是rabbitmq的工作模式的publish\subscribe
  • direct:对应的Routing工作模式
  • topic：对应的Topics工作模式
  • Headers:对应的Headers工作模式