RabbitMQ笔记

RabbitMQ笔记

  • rabbitmq中的角色可以抽象为生产者,消费者,broker,以及两条channel。三者之间通过channel进行交互。获取channel需要登陆授权的Connector。生产者的channel需要配置交换器标签和路由键标签,路由键标签最终代替queue标签,之后Producer不再与queue直接接触。而consumer的channel则需要配置好接收滑动窗口的大小,以及queue的名称,还有消息处理handler。
  • RabbitMQ的queue不支持广播消费(没有topic概念,如需要,需要自己封装),但是exchanger可以做到广播消息给多个队列。
  • RabbitMQ的架构依据是AMQP,所以最好有所了解。
  • Exchanger可以理解为Producer的代理,它可以把消息投递给一个或者多个队列
  • BindingKey的官方解释“the RoutingKey to use for Binding”, 从这句话可以理解为绑定键就是用来绑定的路由键,也就是说路有键可以分为未绑定的,和绑定过的(将exchanger和queue绑定)。之后producer就是面向bindingkey发布消息。
  • topic交换器可以使得bindingkey支持模糊匹配的能力,从某种意义上看,topic类型是direct类型的增强版。
  • exchanger由四种类型的direct,topic,fanout,headers。其中fanout就是全量广播,而topic支持模糊广播,而direct可以支持确定性广播。实际上用的最多的应该是topic,因为它的自定义功能最强大。
  • channel实现了对tcp连接connector的复用。减少了网络IO的开销。它是AMQP提出的概念。
  • AMQP协议是基于TCP协议之上的应用层协议,它的握手和关闭页TCP一样是稳定可靠保守的通讯协议,性能也相对低。(比如一样拥有滑动窗口机制)
  • AMQP协议中每次deliver都需要一个ack
#### 学习完AMQP的总结:
它是一个稳定可以靠的同学协议,它的角色是客户端和broker服务器,它的操作对象是消息,队列,交换器,连接,channel配置,事务,confirm机制配置。事务是同步耗性能的,confirm是异步高性能的。
  • channel是非线程安全的,但是它的isopen()方法是同步安全的,不过代价很大,它使用了syntronized关键字。

  • 交换器可以自由组合

  • 声明队列排他性是关键词:首次创建的连接可见,关闭连接后自动删除。

  • 自动删除的定义是,至少被消费者连接过一次,之后不再有任何client连接,就会被删除。

  • basic.consume是异步的比basic.get的吞吐量高很多。

  • 如果消费者没有ack时挂掉,消息会马上回到重新分发队列,如果消费者连接没有断开,这个消息会一直处于待确认状态。

  • basic.recover默认会重新分发消息给与之前不同的消费者处理。

  • mandatory 为true,无队列的消息会返回给producer的returnlistener处理。

  • 如果没有队列接受的消息,不想丢失,也不想返回,可以交给备胎交换器alternate-exchanger处理。

  • 备胎交换器的优先级 > mandatory > policy(rabbitmqctl set_policy )

  • 备胎交换器丢失的信息无任何异常日志。

  • 可以给队列所有方法设置相同的秒级过期时间TTL,过期的消息会定义被清除。也可以对单个消息设置毫秒级TTL,过期时延迟到即将投递之前判断是否过期抛弃(这种延迟删除有点类似delayQueue的实现),如果两种都设置了,则取最短的TTL为准。

  • ttl为0则表示消息马上投递给消费者,无消费者则给备胎exchanger或returnlistener或policy(过期)。

  • 队列的生命也可以设置TTL,不过rabbitmq重启后队列过期时间重新计算。

  • 死信邮箱DLX可以接受被拒绝,过期,队满时抛弃的消息。是重要的优化工具。(TTL+DLX)

  • 可以利用TTL+DLX死信邮箱机制模拟实现延迟队列,延迟队列是调度器线程池的核心工具。但是死信队列没有优先级,所以不同TTL的消息要放到不同的队列,又或者给队列和消息设置优先级。

  • 生产者的可靠发布,可以通过同步事务和异步确认来实现,如果异步确认采用waitforconfirm性能会退化接近同步事务。而较为常见的手段有批量同步confirm,和异步批量confirm.

  • 如果rabbitmq服务器在接受消息时出现异常就会返回给客户端basic.nack命令要求重发。

  • 在批量模式下,出现nack是很耗性能的事,因为它会要求这批消息重发。这个模式下批量发生的条数是由rabbitmq服务器设置的。

  • 在rabbitmq当中,Qos的滑动窗口大小中的global参数的含义:false表示,对针对每个接下来创建的consumer设置窗口,true表示该针对channel设置窗口大小。

  • 任何一个环境都可能会导致消息乱序,要确保有序只有一个方案,就是要求消息到处理前重排序,获取只处理期望得到的需要的消息,类似新增自定义滑动窗口。

  • Rabbitmq确保消息至少被消费一次的方法是:
    1.生产者采用confirm模式(或者事务模式)
    2.采用死信队列和备胎交换器
    3.broker持久化
    4.consumer采用手动确认

  • 目前所有MQ都无法保证消息能去重,最多只能确保不丢失。

  • 一台服务器上的rabbitmq应用程序是支持多租户vhost的,默认是/

  • connector共享和queue的轮训是rabbitmq的性能瓶颈之一

CAP

网络分区是否具备容错性决定了可用性和一致性

一个网络分区发生后如果具有容错算法或者同步冗余数据算法,比自动把故障节点剔除或者同步数据,那么网络在剔除或同步数据期间就不可用了(并非一直可用)。但是对外的服务数据一直保持着一致性,这种就是CP原则。

如果网络发生分区后,继续服务即一直可用,就会出现数据不一致。那么网络就是AP原则。

如果网络发生分区后直接挂掉,那么网络从挂掉之前网络一直可用且数据一致,那么就是CA。这跟单机没什么区别了。

  • rabbit垃圾会缓存后集中回收,内存报警的阈值是40%,超过这个值就会禁止生产者加入消息,最坏的情况下垃圾回收会导致内存使用率达到80%
  • 硬盘的告警阈值为可用剩下50M
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值