- 原则
- 消息传输的可靠性：保证消息不会丢失。
- 支持集群，包括横向扩展，单点故障都可以解决。
- 性能要好，要能够满足业务的性能需求。
- RabbitMQ支持大多数语言；因为实现的是协议
- 选型
- exchange和queues绑定： BindingKey
- 生产者：发送给交换器，会有一个RoutingKey，会和BindingKey对比进行绑定。然后放在某一个queue里面
- 交换器类型
- fanout
- 一对多直接交换
- 不需要BK和RK
- Direct
- RK和BK，点对点，
- 如果没有匹配的，可以设置丢掉还是退回给生产者
- Topic交换器
- RK和BK可以指定通配符
- BK和RK点分单词：
- *一个单词；#零到多个单词
- fanout
- 存储机制
- 持久化消息和非持久化消息
- 这两种消息都会写入磁盘
- 性能弹性
- 非持久化消息写盘： 内存不够
- 持久化写内存：
- 性能弹性
- 队列的四种状态
- alpha：消息索引和消息内容都存内存，最耗内存，很少消耗CPU
- beta：消息索引存内存，消息内存存磁盘
- gama：消息索引内存和磁盘都有，消息内容存磁盘
- delta：消息索引和内容都存磁盘，基本不消耗内存，消耗更多CPU和I/O操作
- 延伸题目：如果rabbit大量消息堆积后果
- 会堆积磁盘，延迟很小，出现大量磁盘IO，效率很低
- 有没有大小限制?
- 理论上没有，看磁盘大小
- 安装注意版本兼容
- 工作流程
- 生产时候：需要声明交换器和RK
- 消费流程
- Connection和Channel关系
通过信道复用TCP连接，使用时候会加锁
- 秒杀应用
- 分为高并发读和高并发写
- 工作模式：
- Work Queue
- 发布订阅模式(fanout)
- 类似于广播，人不在，挺不到
- 路由模式 // direct
- 主题模式 // topic
- 消息可靠性
- 消息可靠性
- 重复消费
- 通过构建一个线程监听；根据指标监听，然后分到相同消息者里面
- 顺序消费
- 消息丢失
- 异常捕获
- 确认机制：生产者确认和消费者确认
- 高可用：broker镜像队列、高可用备份
- 生产者重发；消费者重试
- 事务机制： 不建议用
- 数据持久化：
- 交换器的持久化、队列的持久化、消息的持久化
- 进项队列
- 消费端限流： 防止推模式下消费端堆积
- 流控机制： 生产方阻塞
- QoS机制： 仅对推模式有效
- 三个消费的层级
- 不支持恰好一次
- 通过最少一次+ 幂等性
- TTL机制
- 对消息设置TTL
- 对消息队列设置TTL
- 不同的消息队列设置时间不同，意义不大：
- 只检查超时队列头部的
- 闹钟不合适；延迟支付还可以
- 死信队列
- 配置以后，消息过期后会进入死信队列
- 队列达到最大长度
- 消息被拒绝；并设置requeue为false
- 延迟队列
- 定时操作
- 使用插件rabbitmq_delayed_message_exchange
- 可以实现按照过期时间进行轮训
- 集群
- 主备、主从、主主、分片集群、异地多活
- nginx ： keep-alive 进行IP漂移，实现nginx的高可用
- 集群两个目标： 横向扩容和高可用
- 常用负载均衡算法
- 随机、轮询、加权、最少活跃、原地址、一致性hash
- 脑裂
- 过半机制
- 通过Zk实现过半机制
- 缺点浪费资源
- kafka逆势
- 缺点浪费资源
- 不用过半
- 不用内存
- RabbitMQ的集群
- 兔子窝：主备模式
- 铲子模式： 数据复制
- Federation联邦模式 ： 实现跨集群、节点消息同步的插件。
- 一般不用来解决问题；因为数据库没法跟着配置；容易出现问题
- 集群
- 共享元数据；不共享消息
- 挂在嘴上的镜像队列
- 每个镜像队列包含一个master，若干个镜像。master存在于称为master的节点上。
所有的操作都是首先对master执行，之后广播到镜像。
这涉及排队发布，向消费者传递消息，跟踪来自消费者的确认等。镜像意味着集群，不应该WAN使用。 - 提供了高可用，但是没有负载均衡。 使用HA-Proxy进行负载均衡。
- 每个镜像队列包含一个master，若干个镜像。master存在于称为master的节点上。
- 大厂面试题
若有收获，就点个赞吧
0 人点赞
