RabbitMQ知识点

RabbitMQ知识点
一、MQ 的基本概念
1、MQ概述
MQ全称 Message Queue（消息队列），是在消息的传输过程中保存消息的容器。多用于分布式系统之间进
2、RabbitMQ 简介
AMQP，即 Advanced Message Queuing Protocol（高级消息队列协议），是一个网络协议，是应用层协议 的一个开放标准，为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同的开发语言等条件的限制。2006年，AMQP 规范发布。类比HTTP。 RabbitMQ 中的相关概念： Broker：接收和分发消息的应用，RabbitMQ Server就是 Message Broker ，Virtual host：出于多租户和安全因素设计的，把 AMQP 的基本组件划分到一个虚拟的分组中，类似于网络中的namespace 概念。当多个不同的用户使用同一个 RabbitMQ server 提供的服务时，可以划分出多 个vhost，每个用户在自己的 vhost 创建 exchange／queue 等 ，Connection：publisher／consumer 和 broker 之间的 TCP 连接 ，Channel：如果每一次访问 RabbitMQ 都建立一个 Connection，在消息量大的时候建立 TCP Connection，的开销将是巨大的，效率也较低。Channel 是在 connection 内部建立的逻辑连接，如果应用程序支持多线程，通常每个thread创建单独的 channel 进行通讯，AMQP method 包含了channel id 帮助客户端，message broker 识别 channel，所以 channel 之间是完全隔离的。Channel 作为轻量级的 Connection，极大减少了操作系统建立 TCP connection 的开销。
3、JMS
JMS 即 Java 消息服务（JavaMessage Service）应用程序接口，是一个 Java 平台中关于面向消息中间件的API ，JMS 是 JavaEE 规范中的一种，类比JDBC ，很多消息中间件都实现了JMS规范，例如：ActiveMQ。RabbitMQ 官方没有提供 JMS 的实现包，但是开源社区有
4、小结
RabbitMQ 是基于 AMQP 协议使用 Erlang 语言开发的一款消息队列产品。RabbitMQ提供了6种工作模式，我们学习5种。这是今天的重点。 AMQP 是协议，类比HTTP。 JMS 是 API 规范接口，类比 JDBC。
5、RabbitMQ 快速入门
入门程序：需求：使用简单模式完成消息传递，步骤： 创建工程（生成者、消费者），分别添加依赖，编写生产者发送消息，编写消费者接收消息。小结：上述的入门案例中其实使用的是如下的简单模式：在上图的模型中，有以下概念： P：生产者，也就是要发送消息的程序 ，C：消费者：消息的接收者，会一直等待消息到来，queue：消息队列，图中红色部分。类似一个邮箱，可以缓存消息；生产者向其中投递消息，消费者从其中取出消息
6、RabbitMQ 的工作模式
Work queues 工作队列模式：模式说明：Work Queues：与入门程序的简单模式相比，多了一个或一些消费端，多个消费端共同消费同一个队列中的消息。应用场景：对于任务过重或任务较多情况使用工作队列可以提高任务处理的速度。代码编写。Work Queues 与入门程序的简单模式的代码几乎是一样的。可以完全复制，并多复制一个消费者进行多个消费者同时对消费消息的测试。小结：在一个队列中如果有多个消费者，那么消费者之间对于同一个消息的关系是竞争的关系。 Work Queues 对于任务过重或任务较多情况使用工作队列可以提高任务处理的速度。例如：短信服务部署多个，只需要有一个节点成功发送即可。
7、Pub/Sub 订阅模式
在订阅模型中，多了一个 Exchange 角色，而且过程略有变化：P：生产者，也就是要发送消息的程序，但是不再发送到队列中，而是发给X（交换机），C：消费者，消息的接收者，会一直等待消息到来，Queue：消息队列，接收消息、缓存消息，Exchange：交换机（X）。一方面，接收生产者发送的消息。另一方面，知道如何处理消息，例如递交给某个特别队列、递交给所有队列、或是将消息丢弃。到底如何操作，取决于Exchange的类型。Exchange有常见以下3种类型： Fanout：广播，将消息交给所有绑定到交换机的队列，Direct：定向，把消息交给符合指定routing key 的队列，Topic：通配符，把消息交给符合routing pattern（路由模式） 的队列，Exchange（交换机）只负责转发消息，不具备存储消息的能力，因此如果没有任何队列与 Exchange 绑定，或者没有符合路由规则的队列，那么消息会丢失！小结：交换机需要与队列进行绑定，绑定之后；一个消息可以被多个消费者都收到。发布订阅模式与工作队列模式的区别：工作队列模式不用定义交换机，而发布/订阅模式需要定义交换机发布/订阅模式的生产方是面向交换机发送消息，工作队列模式的生产方是面向队列发送消息(底层使用默认交换机)发布/订阅模式需要设置队列和交换机的绑定，工作队列模式不需要设置，实际上工作队列模式会将队列绑定到默认的交换机
8、Routing 路由模式
模式说明：队列与交换机的绑定，不能是任意绑定了，而是要指定一个 RoutingKey（路由key），消息的发送方在向 Exchange 发送消息时，也必须指定消息的 RoutingKeyExchange 不再把消息交给每一个绑定的队列，而是根据消息的 Routing Key 进行判断，只有队列的Routingkey 与消息的 Routing key 完全一致，才会接收到消息
图解：P：生产者，向 Exchange 发送消息，发送消息时，会指定一个routing key 。X：Exchange（交换机），接收生产者的消息，然后把消息递交给与 routing key 完全匹配的队列。C1：消费者，其所在队列指定了需要 routing key 为 error 的消息，C2：消费者，其所在队列指定了需要 routing key 为 info、error、warning 的消息。小结：Routing 模式要求队列在绑定交换机时要指定 routing key，消息会转发到符合 routing key 的队列
9、Topics 通配符模式
模式说明：Topic 类型与 Direct 相比，都是可以根据 RoutingKey 把消息路由到不同的队列。只不过 Topic 类型Exchange 可以让队列在绑定 Routing key 的时候使用通配符！Routingkey 一般都是有一个或多个单词组成，多个单词之间以”.”分割，例如： item.insert通配符规则：# 匹配一个或多个词，* 匹配不多不少恰好1个词，例如：item.# 能够匹配 item.insert.abc 或者 item.insert，item.* 只能匹配 item.insert。图解：红色 Queue：绑定的是 usa.# ，因此凡是以 usa. 开头的 routing key 都会被匹配到，黄色 Queue：绑定的是 #.news ，因此凡是以 .news 结尾的 routing key 都会被匹配。小结：Topic 主题模式可以实现 Pub/Sub 发布与订阅模式和 Routing 路由模式的功能，只是 Topic 在配置routing key的时候可以使用通配符，显得更加灵活。
10、工作模式总结
简单模式 HelloWorld ：一个生产者、一个消费者，不需要设置交换机（使用默认的交换机）。工作队列模式 Work Queue：一个生产者、多个消费者（竞争关系），不需要设置交换机（使用默认的交换机）。发布订阅模式 Publish/subscribe ：需要设置类型为 fanout 的交换机，并且交换机和队列进行绑定，当发送消息到交换机后，交换机会将消息发送到绑定的队列。路由模式 Routing ：需要设置类型为 direct 的交换机，交换机和队列进行绑定，并且指定 routing key，当发送消息到交换机后，交换机会根据 routing key 将消息发送到对应的队列。通配符模式 Topic ：需要设置类型为 topic 的交换机，交换机和队列进行绑定，并且指定通配符方式的 routing key，当发送消息到交换机后，交换机会根据 routing key 将消息发送到对应的队列。
二、RabbitMQ 高级特性
1、消息的可靠投递
在使用 RabbitMQ 的时候，作为消息发送方希望杜绝任何消息丢失或者投递失败场景。RabbitMQ 为我们提供了两种方式用来控制消息的投递可靠性模式：confirm 确认模式
return 退回模式 。rabbitmq 整个消息投递的路径为：producer—>rabbitmq broker—>exchange—>queue—>consumer 。消息从 producer 到 exchange 则会返回一个 confirmCallback 。消息从 exchange–>queue 投递失败则会返回一个 returnCallback 。
2、我们将利用这两个 callback 控制消息的可靠性投递
设置ConnectionFactory的publisher-confirms=“true” 开启 确认模式。使用rabbitTemplate.setConfirmCallback设置回调函数。当消息发送到exchange后回调confirm方法。在方法中判断ack，如果为true，则发送成功，如果为false，则发送失败，需要处理。设置ConnectionFactory的publisher-returns=“true” 开启 退回模式。使用rabbitTemplate.setReturnCallback设置退回函数，当消息从exchange路由到queue失败后，如果设置了rabbitTemplate.setMandatory(true)参数，则会将消息退回producer。并执行回调函数returnedMessage。在RabbitMQ中也提供了事务机制，但是性能较差，此处不做讲解。使用channel下列方法，完成事务控制：txSelect(), 用于将当前channel设置成transaction模式txCommit()，用于提交事务txRollback(),用于回滚事务
3、 Consumer Ack
ack指Acknowledge，确认。 表示消费端收到消息后的确认方式。有三种确认方式：
自动确认：acknowledge=“none”，手动确认：acknowledge=“manual” ，根据异常情况确认：acknowledge=“auto”，（这种方式使用麻烦，不作讲解）其中自动确认是指，当消息一旦被Consumer接收到，则自动确认收到，并将相应 message 从 RabbitMQ 的 消息缓存中移除。但是在实际业务处理中，很可能消息接收到，业务处理出现异常，那么该消息就会丢失。如果设置了手动确认方式，则需要在业务处理成功后，调channel.basicAck()，手动签收，如果出现异常，则调用channel.basicNack()方法，让其自动重新发送消息
Consumer Ack 小结：在rabbit:listener-container标签中设置acknowledge属性，设置ack方式 none：自动确认，manual：手动确认如果在消费端没有出现异常，则调用channel.basicAck(deliveryTag,false);方法确认签收消息如果出现异常，则在catch中调用 basicNack或 basicReject，拒绝消息，让MQ重新发送消息。
4、持久化
exchange要持久化，queue要持久化，message要持久化，生产方确认Confirm，消费方确认Ack。Broker高可用
5、消费端限流
在rabbit:listener-container 中配置 prefetch属性设置消费端一次拉取多少消息
消费端的确认模式一定为手动确认。acknowledge=“manual”
6、TTL
TTL 全称 Time To Live（存活时间/过期时间）。 当消息到达存活时间后，还没有被消费，会被自动清除。RabbitMQ可以对消息设置过期时间，也可以对整个队列（Queue）设置过期时间。TTL 小结：设置队列过期时间使用参数：x-message-ttl，单位：ms(毫秒)，会对整个队列消息统一过期。 设置消息过期时间使用参数：expiration。单位：ms(毫秒)，当该消息在队列头部时（消费时），会单独判断这一消息是否过期。如果两者都进行了设置，以时间短的为准。
7、死信队列
死信队列，英文缩写：DLX 。Dead Letter Exchange（死信交换机），当消息成为Dead message后，可以被重新发送到另一个交换机，这个交换机就是DLX。消息成为死信的三种情况：队列消息长度到达限制；消费者拒接消费消息，basicNack/basicReject,并且不把消息重新放入原目标队列,requeue=false；原队列存在消息过期设置，消息到达超时时间未被消费；死信队列：队列绑定死信交换机：给队列设置参数：x-dead-letter-exchange 和 x-dead-letter-routing-key。死信队列小结：死信交换机和死信队列和普通的没有区别，当消息成为死信后，如果该队列绑定了死信交换机，则消息会被死信交换机重新路由到死信队列.消息成为死信的三种情况：队列消息长度到达限制；消费者拒接消费消息，并且不重回队列；原队列存在消息过期设置，消息到达超时时间未被消费；
8、延迟队列
延迟队列，即消息进入队列后不会立即被消费，只有到达指定时间后，才会被消费。
需求：下单后，30分钟未支付，取消订单，回滚库存。新用户注册成功7天后，发送短信问候。实现方式：定时器，延迟队列。延迟队列小结：延迟队列 指消息进入队列后，可以被延迟一定时间，再进行消费。 RabbitMQ没有提供延迟队列功能，但是可以使用 ： TTL + DLX 来实现延迟队列效果。
9、日志与监控
RabbitMQ日志：RabbitMQ默认日志存放路径： /var/log/rabbitmq/rabbit@xxx.log
日志包含了RabbitMQ的版本号、Erlang的版本号、RabbitMQ服务节点名称、cookie的hash值、RabbitMQ配置文件地址、内存限制、磁盘限制、默认账户guest的创建以及权限配置等等。web管控台监控：rabbitmqctl管理和监控：

10、消息追踪
在使用任何消息中间件的过程中，难免会出现某条消息异常丢失的情况。对于RabbitMQ而言，可能是因为生产者或消费者与RabbitMQ断开了连接，而它们与RabbitMQ又采用了不同的确认机制；也有可能是因为交换器与队列之间不同的转发策略；甚至是交换器并没有与任何队列进行绑定，生产者又不感知或者没有采取相应的措施；另外RabbitMQ本身的集群策略也可能导致消息的丢失。这个时候就需要有一个较好的机制跟踪记录消息的投递过程，以此协助开发和运维人员进行问题的定位。在RabbitMQ中可以使用Firehose和rabbitmq_tracing插件功能来实现消息追踪。
11、消息追踪-Firehose
firehose的机制是将生产者投递给rabbitmq的消息，rabbitmq投递给消费者的消息按照指定的格式发送到默认的exchange上。这个默认的exchange的名称为amq.rabbitmq.trace，它是一个topic类型的exchange。发送到这个exchange上的消息的routing key为 publish.exchangename 和 deliver.queuename。其中exchangename和queuename为实际exchange和queue的名称，分别对应生产者投递到exchange的消息，和消费者从queue上获取的消息。 注意：打开 trace 会影响消息写入功能，适当打开后请关闭。rabbitmqctl trace_on：开启Firehose命令，rabbitmqctl trace_off：关闭Firehose命令。
12、消息追踪-rabbitmq_tracing
rabbitmq_tracing和Firehose在实现上如出一辙，只不过rabbitmq_tracing的方式比Firehose多了一层GUI的包装，更容易使用和管理。启用插件：rabbitmq-plugins enable rabbitmq_tracing