怎么使用服务器做网站,合肥网站设计建,个人如何网站备案,外贸wordpress主题本文来说下RabbitMq相关的知识与概念 文章目录 概述AMQP协议Exchange 消息如何保证100#xff05;投递什么是生产端的可靠性投递可靠性投递保障方案 消息幂等性高并发的情况下如何避免消息重复消费confirm 确认消息、Return返回消息如何实现confirm确认消息return消息机制 消费… 本文来说下RabbitMq相关的知识与概念 文章目录 概述AMQP协议Exchange 消息如何保证100投递什么是生产端的可靠性投递可靠性投递保障方案 消息幂等性高并发的情况下如何避免消息重复消费confirm 确认消息、Return返回消息如何实现confirm确认消息return消息机制 消费端自定义监听消费端限流消费端ack与重回队列消息重回队列TTL队列/消息 死信队列rabbitMQ集群模式主备模式集群模式多活模式 本文小结 概述 RabbitMQ是基于AMQP协议的通过使用通用协议就可以做到在不同语言之间传递 AMQP协议 核心概念 server又称broker接受客户端连接实现AMQP实体服务。connection连接和具体broker网络连接。channel网络信道几乎所有操作都在channel中进行channel是消息读写的通道。客户端可以建立多个channel每个channel表示一个会话任务。message消息服务器和应用程序之间传递的数据由properties和body组成。properties可以对消息进行修饰比如消息的优先级延迟等高级特性body是消息实体内容。Virtual host虚拟主机用于逻辑隔离最上层消息的路由。一个Virtual host可以若干个Exchange和Queue同一个Virtual host不能有同名的Exchange或Queue。Exchange交换机接受消息根据路由键转发消息到绑定的队列上。bandingExchange和Queue之间的虚拟连接binding中可以包括routing keyrouting key一个路由规则虚拟机根据他来确定如何路由 一条消息。Queue消息队列用来存放消息的队列。 Exchange 交换机的类型direct、topic、fanout、headersdurability是否需要持久化true需要auto delete当最后一个绑定Exchange上的队列被删除Exchange也删除。 Direct Exchange,所有发送到Direct Exchange的消息被转发到RouteKey 中指定的Queue,Direct Exchange可以使用默认的默认的Exchange default Exchange默认的Exchange会绑定所有的队列所以Direct可以直接使用Queue名作为routing key 绑定。或者消费者和生产者的routing key完全匹配。Toptic Exchange,是指发送到Topic Exchange的消息被转发到所有关心的Routing key中指定topic的Queue上。Exchange 将routing key和某Topic进行模糊匹配此时队列需要绑定一个topic。所谓模糊匹配就是可以使用通配符“#”可以匹配一个或多个词“”只匹配一个词比如“log.#”可以匹配“log.info.test” log. 就只能匹配log.error。Fanout Exchange:不处理路由键只需简单的将队列绑定到交换机上。发送到改交换机上的消息都会被发送到与该交换机绑定的队列上。Fanout转发是最快的。 消息如何保证100投递
什么是生产端的可靠性投递 什么是生产端的可靠性投递 保证消息的成功发出保证MQ节点节点的成功接收发送端MQ节点broker收到消息确认应答完善消息进行补偿机制 可靠性投递保障方案 消息落库对消息进行打标 消息的延迟投递 在高并发场景下每次进行db的操作都是每场消耗性能的。我们使用延迟队列来减少一次数据库的操作。 消息幂等性 幂等性是什么 我对一个动作进行操作我们肯能要执行100次1000次对于这1000次执行的结果都必须一样的。比如单线程方式下执行update count-1的操作执行一千次结果都是一样的所以这个更新操作就是一个幂等的如果是在并发不做线程安全的处理的情况下update一千次操作结果可能就不是一样的所以并发情况下的update操作就不是一个幂等的操作。对应到消息队列上来就是我们即使受到了多条一样的消息也和消费一条消息效果是一样的。 高并发的情况下如何避免消息重复消费 唯一id加指纹码利用数据库主键去重。 优点实现简单
缺点高并发下有数据写入瓶颈。 利用Redis的原子性来实习。 使用Redis进行幂等是需要考虑的问题
是否进行数据库落库落库后数据和缓存如何做到保证幂等Redis 和数据库如何同时成功同时失败
如果不进行落库都放在Redis中如何这是Redis和数据库的同步策略还有放在缓存中就能百分之百的成功吗 confirm 确认消息、Return返回消息 理解confirm消息确认机制 消息的确认指生产者收到投递消息后如果Broker收到消息就会给我们 的生产者一个应答生产者接受应答来确认broker是否收到消息。 如何实现confirm确认消息
在Channel上开启确认模式channel.confirmSelect()
在channel上添加监听addConfirmListener监听成功和失败的结果具体结果对消息进行重新发送或者记录日志。 return消息机制
Return消息机制处理一些不可路由的消息我们的生产者通过指定一个Exchange和Routinkey把消息送达到某一个队列中去然后我们消费者监听队列进行消费处理
在某些情况下如果我们在发送消息的时候当Exchange不存在或者指定的路由key路由找不到这个时候如果我们需要监听这种不可到达的消息就要使用Return Listener
Mandatory 设置为true则会监听器会接受到路由不可达的消息然后处理。如果设置为falsebroker将会自动删除该消息。 消费端自定义监听
消费端限流 什么是消费端的限流限流算法 假设我们有个场景首先我们有个rabbitMQ服务器上有上万条消息未消费然后我们随便打开一个消费者客户端会出现巨量的消息瞬间推送过来但是我们的消费端无法同时处理这么多数据。
这时就会导致你的服务崩溃。其他情况也会出现问题比如你的生产者与消费者能力不匹配在高并发的情况下生产端产生大量消息消费端无法消费那么多消息。
rabbitMQ提供了一种qos服务质量保证的功能即非自动确认消息的前提下如果有一定数目的消息通过consumer或者Channel设置qos未被确认不进行新的消费。prefetchSize:0 单条消息的大小限制。0就是不限制一般都是不限制。prefetchCount: 设置一个固定的值告诉rabbitMQ不要同时给一个消费者推送多余N个消息即一旦有N个消息还没有ack则consumer将block掉直到有消息ackglobaltruefalse 是否将上面的设置用于channel也是就是说上面设置的限制是用于channel级别的还是consumer的级别的。 消费端ack与重回队列 消费端ack与重回队列 消费端进行消费的时候如果由于业务异常我们可以进行日志的记录然后进行补偿也可以加上最大努力次数的尝试如果由于服务器宕机等严重问题那我们就需要手动进行ack保证消费端的消费成功 消息重回队列 消息重回队列 重回队列就是为了对没有处理成功的消息把消息重新投递给broker实际应用中一般都不开启重回队列。 TTL队列/消息 TTL time to live 生存时间。 支持消息的过期时间在消息发送时可以指定。支持队列过期时间在消息入队列开始计算时间只要超过了队列的超时时间配置那么消息就会自动的清除。 死信队列 死信队列DLXDead-Letter-Exchange 利用DLX当消息在一个队列中变成死信dead message就是没有任何消费者消费之后他能被重新publish到另一个Exchange这个Exchange就是DLX。 消息变为死信的几种情况 消息被拒绝basic.reject/basic.nack同时requeuefalse不重回队列TTL过期队列达到最大长度
DLX也是一个正常的Exchange和一般的Exchange没有任何的区别他能在任何的队列上被指定实际上就是设置某个队列的属性。
当这个队列出现死信的时候RabbitMQ就会自动将这条消息重新发布到Exchange上去进而被路由到另一个队列。可以监听这个队列中的消息作相应的处理这个特性可以弥补rabbitMQ以前支持的immediate参数的功能。 死信队列的设置 设置Exchange和Queue然后进行绑定
Exchange: dlx.exchange(自定义的名字)
queue: dlx.queue自定义的名字
routingkey: ##表示任何routingkey出现死信都会被路由过来
然后正常的声明交换机、队列、绑定只是我们在队列上加上一个参数
arguments.put(“x-dead-letter-exchange”,“dlx.exchange”); rabbitMQ集群模式
主备模式 主备模式 实现rabbitMQ高可用集群一般在并发量和数据不大的情况下这种模式好用简单。又称warren模式。区别于主从模式主从模式主节点提供写操作从节点提供读操作主备模式从节点不提供任何读写操作只做备份如果主节点宕机备份从节点会自动切换成主节点提供服务 集群模式 集群模式 经典方式就是Mirror模式保证100%数据不丢失实现起来也是比较简单。
镜像队列是rabbitMQ数据高可用的解决方案主要是实现数据同步一般来说是由2-3节点实现数据同步对于100%消息可靠性解决方案一般是3个节点 多活模式
多活模式这种模式也是实现异地数据复制的主流模式因为shovel模式配置相对复杂所以一般来说实现异地集群都是使用这种双活多活的模式这种模式需要依赖rabbitMQ的federation插件可以实现持续可靠的AMQP数据。
rabbitMQ部署架构采用双中心模式多中心在两套或多套数据中心个部署一套rabbitMQ集群各中心的rabbitMQ服务需要为提供正常的消息业务外中心之间还需要实现部分队列消息共享。 多活架构如下 本文小结
本文介绍了RabbitMq一些基础知识和基本概念
