做网站的设计公司,恩施州建设局网站,数字广东公司面试严吗,小程序模板源代码目录 一、RabbitMQ简介(消息中间件)1、RabbitMQ简介#xff1a;2、核心概念1、Message2、Publisher3、Exchange4、Queue5、Binding6、Connection7、Channel8、Consumer9、Virtual Host10、Broker 二、一些概念1、异步处理2、应用解耦3、流量控制5、概述 三、Docker安装RabbitM… 目录 一、RabbitMQ简介(消息中间件)1、RabbitMQ简介2、核心概念1、Message2、Publisher3、Exchange4、Queue5、Binding6、Connection7、Channel8、Consumer9、Virtual Host10、Broker 二、一些概念1、异步处理2、应用解耦3、流量控制5、概述 三、Docker安装RabbitMQ四、RabbitMQ运行机制1、AMQP 中的消息路由2、Exchange 类型 五、RabbitMQ整合六、RabbitMQ消息确认机制-可靠抵达1、可靠抵达-ConfirmCallback2、可靠抵达-ReturnCallback3、可靠抵达-Ack消息确认机制 七、RabbitMQ延时队列实现定时任务1、场景2、消息的TTLTime To Live3、Dead Letter ExchangesDLX4、延时队列实现-15、延时队列实现-26、SpringBoot中使用延时队列7、如何保证消息可靠性-消息丢失8、如何保证消息可靠性-消息重复9、如何保证消息可靠性-消息积压10、MQ对比 一、RabbitMQ简介(消息中间件)
1、RabbitMQ简介
RabbitMQ是一个由erlang开发的AMQP(Advanved Message Queue Protocol)的开源实现。
2、核心概念
1、Message
消息消息是不具名的它由消息头和消息体组成。消息体是不透明的而消息头则由一系列的可选属性组成 这些属性包括routing-key路由键、priority相对于其他消息的优先权、delivery-mode指出该消息可 能需要持久性存储等。
2、Publisher
消息的生产者也是一个向交换器发布消息的客户端应用程序。
3、Exchange
交换器用来接收生产者发送的消息并将这些消息路由给服务器中的队列。 Exchange有4种类型direct(默认)fanout, topic, 和headers不同类型的Exchange转发消息的策略有所区别
4、Queue
消息队列用来保存消息直到发送给消费者。它是消息的容器也是消息的终点。一个消息可投入一个或多个队列。消息一直 在队列里面等待消费者连接到这个队列将其取走。
5、Binding
绑定用于消息队列和交换器之间的关联。一个绑定就是基于路由键将交换器和消息队列连接起来的路由规则所以可以将交 换器理解成一个由绑定构成的路由表。 Exchange 和Queue的绑定可以是多对多的关系。
6、Connection
网络连接比如一个TCP连接。
7、Channel
信道多路复用连接中的一条独立的双向数据流通道。信道是建立在真实的TCP连接内的虚拟连接AMQP 命令都是通过信道 发出去的不管是发布消息、订阅队列还是接收消息这些动作都是通过信道完成。因为对于操作系统来说建立和销毁 TCP 都 是非常昂贵的开销所以引入了信道的概念以复用一条 TCP 连接。
8、Consumer
消息的消费者表示一个从消息队列中取得消息的客户端应用程序。
9、Virtual Host
虚拟主机表示一批交换器、消息队列和相关对象。虚拟主机是共享相同的身份认证和加密环境的独立服务器域。每个 vhost 本质上就是一个 mini 版的 RabbitMQ 服务器拥有自己的队列、交换器、绑定和权限机制。vhost 是 AMQP 概念的基础必须在连接时指定RabbitMQ 默认的 vhost 是 / 。
10、Broker
表示消息队列服务器实体 二、一些概念
1、异步处理 2、应用解耦 3、流量控制 5、概述
大多应用中可通过消息服务中间件来提升系统异步通信、扩展解耦能力消息服务中两个重要概念 消息代理message broker和目的地destination 当消息发送者发送消息以后将由消息代理接管消息代理保证消息传递到指定目的地。消息队列主要有两种形式的目的地 1、 队列queue点对点消息通信point-to-point 2、主题topic发布publish/订阅subscribe消息通信点对点式 • 消息发送者发送消息消息代理将其放入一个队列中消息接收者从队列中获取消息内容消息读取后被移出队列 • 消息只有唯一的发送者和接受者但并不是说只能有一个接收者发布订阅式 • 发送者发布者发送消息到主题多个接收者订阅者监听订阅这个主题那么就会在消息到达时同时收到消息JMSJava Message ServiceJAVA消息服务 • 基于JVM消息代理的规范。ActiveMQ、HornetMQ是JMS实现AMQPAdvanced Message Queuing Protocol • 高级消息队列协议也是一个消息代理的规范兼容JMS • RabbitMQ是AMQP的实现 Spring支持 • spring-jms提供了对JMS的支持 • spring-rabbit提供了对AMQP的支持 • 需要ConnectionFactory的实现来连接消息代理 • 提供JmsTemplate、RabbitTemplate来发送消息 • JmsListenerJMS、RabbitListenerAMQP注解在方法上监听消息 代理发布的消息 • EnableJms、EnableRabbit开启支持Spring Boot自动配置 • JmsAutoConfiguration • RabbitAutoConfiguration • 10、市面的MQ产品 • ActiveMQ、RabbitMQ、RocketMQ、Kafka
三、Docker安装RabbitMQ
docker run -d --name rabbitmq -p 5671:5671 -p 5672:5672 -p 4369:4369 -p 25672:25672 -p 15671:15671 -p 15672:15672 rabbitmq:management4369, 25672 (Erlang发现集群端口) 5672, 5671 (AMQP端口) 15672 (web管理后台端口) 61613, 61614 (STOMP协议端口) 1883, 8883 (MQTT协议端口) https://www.rabbitmq.com/networking.html 默认账号和密码是guest/guest 四、RabbitMQ运行机制
1、AMQP 中的消息路由
• AMQP 中消息的路由过程和 Java 开发者熟悉的 JMS 存在一些差别AMQP 中增加了 Exchange 和Binding 的角色。生产者把消息发布到 Exchange 上消息最终到达队列并被消费者接收而 Binding 决定交换器的消息应该发送到那个队列。
2、Exchange 类型
• Exchange分发消息时根据类型的不同分发策略有区别目前共四种类型direct、fanout、topic、headers 。headers 匹配 AMQP 消息的 header 而不是路由键headers 交换器和 direct 交换器完全一致但性能差很多目前几乎用不到了所以直接看另外三种类
消息中的路由键routing key如果和Binding 中的 binding key 一致 交换器就将消息发到对应的队列中。路由键与队列名完全匹配如果一个队列绑定到交换机要求路由键为“dog”则只转发 routingkey 标记为“dog”的消息不会转发“dog.puppy”也不会转发“dog.guard” 等等。它是完全匹配、单播的模式。 每个发到 fanout 类型交换器的消息都会分到所有绑定的队列上去。fanout 交换器不处理路由键只是简单的将队列绑定到交换器上每个发送到交换器的消息都会被转发到与该交换器绑定的所有队列上。很像子网广播每台子网内的主机都获得了一份复制的消息。fanout 类型转发消息是最快的。 topic 交换器通过模式匹配分配消息的路由键属性将路由键和某个模式进行匹配此时队列需要绑定到一个模式上。它将路由键和绑定键的字符串切分成单词这些单词之间用点隔开。它同样也会识别两个通配符符号“#”和符号“*”。#匹配0个或多个单词*匹配一个单词。 五、RabbitMQ整合
引入 spring-boot-starter-amqp application.yml配置 测试RabbitMQ AmqpAdmin管理组件 RabbitTemplate消息发送处理组件 RabbitListener 监听消息的方法可以有三种参数不分数量顺序 • Object content, Message message, Channel channel
六、RabbitMQ消息确认机制-可靠抵达
• 保证消息不丢失可靠抵达可以使用事务消息性能下降250倍为此引入确认机制 • publisher confirmCallback 确认模式 • publisher returnCallback 未投递到 queue 退回模式 • consumer ack机制
1、可靠抵达-ConfirmCallback
• spring.rabbitmq.publisher-confirmstrue • 在创建 connectionFactory 的时候设置 PublisherConfirms(true) 选项开启confirmcallback 。 • CorrelationData用来表示当前消息唯一性。 • 消息只要被 broker 接收到就会执行 confirmCallback如果是 cluster 模式需要所有 broker 接收到才会调用 confirmCallback。 • 被 broker 接收到只能表示 message 已经到达服务器并不能保证消息一定会被投递到目标 queue 里。所以需要用到接下来的returnCallback 。
2、可靠抵达-ReturnCallback
• spring.rabbitmq.publisher-returnstrue • spring.rabbitmq.template.mandatorytrue • confrim 模式只能保证消息到达 broker不能保证消息准确投递到目标 queue 里。在有些业务场景下我们需要保证消息一定要投递到目标 queue 里此时就需要用到return 退回模式。 • 这样如果未能投递到目标 queue 里将调用 returnCallback 可以记录下详细到投递数据定期的巡检或者自动纠错都需要这些数据。
3、可靠抵达-Ack消息确认机制
•消费者获取到消息成功处理可以回复Ack给Broker •basic.ack用于肯定确认broker将移除此消息 •basic.nack用于否定确认可以指定broker是否丢弃此消息可以批量 •basic.reject用于否定确认同上但不能批量 •默认自动ack消息被消费者收到就会从broker的queue中移除 •queue无消费者消息依然会被存储直到消费者消费 •消费者收到消息默认会自动ack。但是如果无法确定此消息是否被处理完成或者成功处理。我们可以开启手动ack模式 •消息处理成功ack()接受下一个消息此消息broker就会移除 •消息处理失败nack()/reject()重新发送给其他人进行处理或者容错处理后ack •消息一直没有调用ack/nack方法broker认为此消息正在被处理不会投递给别人此时客户端断开消息不会被broker移除会投递给别人
七、RabbitMQ延时队列实现定时任务
1、场景
比如未付款订单超过一定时间后系统自动取消订单并释放占有物品。 常用解决方案 spring的 schedule 定时任务轮询数据库 缺点 消耗系统内存、增加了数据库的压力、存在较大的时间误差 解决rabbitmq的消息TTL和死信Exchange结合
2、消息的TTLTime To Live
• 消息的TTL就是消息的存活时间。 • RabbitMQ可以对队列和消息分别设置TTL。 • 对队列设置就是队列没有消费者连着的保留时间也可以对每一个单独的消息做单独的设置。超过了这个时间我们认为这个消息就死了称之为死信。 • 如果队列设置了消息也设置了那么会取小的。所以一个消息如果被路由到不同的队列中这个消息死亡的时间有可能不一样不同的队列设置。这里单讲单个消息的TTL因为它才是实现延迟任务的关键。可以通过设置消息的expiration字段或者x- message-ttl属性来设置时间两者是一样的效果。
3、Dead Letter ExchangesDLX
• 一个消息在满足如下条件下会进死信路由记住这里是路由而不是队列一个路由可以对应很多队列。什么是死信 • 一个消息被Consumer拒收了并且reject方法的参数里requeue是false。也就是说不会被再次放在队列里被其他消费者使用。basic.reject/ basic.nackrequeuefalse • 上面的消息的TTL到了消息过期了。 • 队列的长度限制满了。排在前面的消息会被丢弃或者扔到死信路由上 • Dead Letter Exchange其实就是一种普通的exchange和创建其他 exchange没有两样。只是在某一个设置Dead Letter Exchange的队列中有消息过期了会自动触发消息的转发发送到Dead Letter Exchange中去。 • 我们既可以控制消息在一段时间后变成死信又可以控制变成死信的消息被路由到某一个指定的交换机结合二者其实就可以实现一个延时队列 • 手动ack异常消息统一放在一个队列处理建议的两种方式 • catch异常后手动发送到指定队列然后使用channel给rabbitmq确认消息已消费 • 给Queue绑定死信队列使用nackrequque为false确认消息消费失败 4、延时队列实现-1 5、延时队列实现-2 6、SpringBoot中使用延时队列
• 1、Queue、Exchange、Binding可以Bean进去 • 2、监听消息的方法可以有三种参数不分数量顺序 • Object content, Message message, Channel channel • 3、channel可以用来拒绝消息否则自动ack
7、如何保证消息可靠性-消息丢失
• 1、消息丢失 • 消息发送出去由于网络问题没有抵达服务器 • 做好容错方法try-catch发送消息可能会网络失败失败后要有重试机制可记录到数据库采用定期扫描重发的方式 • 做好日志记录每个消息状态是否都被服务器收到都应该记录 • 做好定期重发如果消息没有发送成功定期去数据库扫描未成功的消息进行重发 • 消息抵达BrokerBroker要将消息写入磁盘持久化才算成功。此时Broker尚未持久化完成宕机。 • publisher也必须加入确认回调机制确认成功的消息修改数据库消息状态。 • 自动ACK的状态下。消费者收到消息但没来得及消息然后宕机 • 一定开启手动ACK消费成功才移除失败或者没来得及处理就noAck并重新入队
8、如何保证消息可靠性-消息重复
2、消息重复 • 消息消费成功事务已经提交ack时机器宕机。导致没有ack成功Broker的消息重新由unack变为ready并发送给其他消费者 • 消息消费失败由于重试机制自动又将消息发送出去 • 成功消费ack时宕机消息由unack变为readyBroker又重新发送 • 消费者的业务消费接口应该设计为幂等性的。比如扣库存有工作单的状态标志 • 使用防重表redis/mysql发送消息每一个都有业务的唯一标识处理过就不用处理 • rabbitMQ的每一个消息都有redelivered字段可以获取是否是被重新投递过来的而不是第一次投递过来的
9、如何保证消息可靠性-消息积压
3、消息积压 • 消费者宕机积压 • 消费者消费能力不足积压 • 发送者发送流量太大 • 上线更多的消费者进行正常消费 • 上线专门的队列消费服务将消息先批量取出来记录数据库离线慢慢处理
10、MQ对比
ActiveMQ、RabbitMQ、RocketMQ、Kafka、Flume
