RabbitMq笔记

1. 为什么使用MQ,优点

其实就是问问你消息队列都有哪些使用场景,然后你项目里具体是什么场景,说说你在这个场景里用消息队列是什么?
面试官问你这个问题,期望的一个回答是说,你们公司有个什么业务场景,这个业务场景有个什么技术挑战,如果不用 MQ 可能会很麻烦,但是你现在用了 MQ 之后带给了你很多的好处。
先说一下消息队列常见的使用场景吧,其实场景有很多,但是比较核心的有 3 个:解耦、异步、削峰。

  • 解耦
    在这里插入图片描述
  • 异步
    在这里插入图片描述
  • 削峰
    在这里插入图片描述

2. 消息队列有什么缺点

  • 系统可用性降低
    系统引入的外部依赖越多,越容易挂掉。本来你就是 A 系统调用 BCD 三个系统的接口就好了,ABCD 四个系统还好好的,没啥问题,你偏加个 MQ 进来,万一 MQ 挂了咋整?MQ 一挂,整套系统崩溃,你不就完了?
  • 系统复杂度提高
    硬生生加个 MQ 进来,你怎么保证消息没有重复消费?怎么处理消息丢失的情况?怎么保证消息传递的顺序性?头大头大,问题一大堆,痛苦不已。
  • 一致性问题
    A 系统处理完了直接返回成功了,人都以为你这个请求就成功了;但是问题是,要是 BCD 三个系统那里,BD 两个系统写库成功了,结果 C 系统写库失败了,咋整?你这数据就不一致了

3. Kafka、ActiveMQ、RabbitMQ、RocketMQ 的区别

在这里插入图片描述

4. 消息的消费的顺序问题

假如生产者产生了 2 条消息:M1、M2,假定 M1 发送到 S1,M2 发送到 S2,如果要保证 M1 先于 M2 被消费,怎么做?

  • 解决方案
    保证生产者 - MQServer - 消费者是一对一对一的关系
    在这里插入图片描述
    缺陷:
  • 并行度就会成为消息系统的瓶颈(吞吐量不够)
  • 更多的异常处理,比如:只要消费端出现问题,就会导致整个处理流程阻塞,我们不得不花费更多的精力来解决阻塞的问题。
  • 不关注乱序的应用实际大量存在
  • 队列无序并不意味着消息无序 所以从业务层面来保证消息的顺序而不仅仅是依赖于消息系统,是一种更合理的方式。

5.什么是AMQP

AMQP全称:Advanced Message Queuing Protocol(高级消息队列协议)。是应用层协议的一个开发标准,为面向消息的中间件设计

6.交换机的三种类型

  • Direct Exchange(处理路由键)
    需要将一个队列绑定到交换机上,要求该消息与一个特定的路由键完全匹配。这是一个完整的匹配。如果一个队列绑定到该交换机上要求路由键 “dog”,则只有被标记为“dog”的消息才被转发,不会转发dog.puppy,也不会转发dog.guard,只会转发dog。(一对一的匹配才会转发)

  • Fanout Exchange(不处理路由键)
    你只需要简单的将队列绑定到交换机上。一个发送到交换机的消息都会被转发到与该交换机绑定的所有队列上。很像子网广播,每台子网内的主机都获得了一份复制的消息。Fanout交换机转发消息是最快的(也号称广播转发消息,会转发到所有绑定此交换机的队列上)

  • Topic Exchange(将路由键和某模式进行匹配)
    此时队列需要绑定要一个模式上。符号“#”匹配一个或多个词,符号“”匹配不多不少一个词。因此“audit.#”能够匹配到“audit.irs.corporate”,但是“audit.” 只会匹配到“audit.irs”。(匹配才会转发)

6.RabbitMQ的消息模式

  • 简单模式(Simple / HelloWorld 单生产单消费)
    简单的发送与接收,没有特别的处理。
    在这里插入图片描述
  • 工作模式(Work单发送多接收)
    一个生产者端,多个消费者端。为了保证消息发送的可靠性,不丢失消息,使消息持久化了。同时为了防止接收端在处理消息时down掉,只有在消息处理完成后才发送消息确认。
    在这里插入图片描述
  • 发布、订阅模式(Publish/Subscribe)
    使用场景:发布、订阅模式,生产者端发送消息,多个消费者同时接收所有的消息。
    在这里插入图片描述
  • 路由模式(Routing)
    生产者按routing key发送消息,不同的消费者端按不同的routing key接收消息。
    在这里插入图片描述
  • 通配符(或主题)模式(Topics ,按topic发送接收)
    生产者端不只按固定的routing key发送消息,而是按字符串“匹配”发送,消费者端同样如此。
    与之前的路由模式相比,它将信息的传输类型的key更加细化,以“key1.key2.keyN…”的模式来指定信息传输的key的大类型和大类型下面的小类型,让消费者端可以更加精细的确认自己想要获取的信息类型。而在消费者端,不用精确的指定具体到哪一个大类型下的小类型的key,而是可以使用类似正则表达式(但与正则表达式规则完全不同)的通配符在指定一定范围或符合某一个字符串匹配规则的key,来获取想要的信息。“通配符交换机”(Topic Exchange)将路由键和某模式进行匹配。此时队列需要绑定在一个模式上。符号“#”匹配一个或多个词,符号“*”仅匹配一个词。
    在这里插入图片描述

7.RabbitMQ如何保证消息不丢失

有三种丢失的情况:
1)生产者发送消息后,MQ没有成功接收到消息:解决方式有两种,事物机制和confirm机制,一般使用confirm机制
2)MQ接收到消息后,还没被消费:开启MQ的持久化,将消息持久化到硬盘中
3)消费者丢失了消息:ACK确认机制

8. 如何保证RabbitMQ不被重复消费

先说为什么会重复消费:正常情况下,消费者在消费消息的时候,消费完毕后,会发送一个确认消息给消息队列,消息队列就知道该消息被消费了,就会将该消息从消息队列中删除;
    但是因为网络传输等等故障,确认信息没有传送到消息队列,导致消息队列不知道自己已经消费过该消息了,再次将消息分发给其他的消费者。
    针对以上问题,一个解决思路是:保证消息的唯一性,就算是多次传输,不要让消息的多次消费带来影响;保证消息等幂性;
    比如:在写入消息队列的数据做唯一标示,消费消息时,根据唯一标识判断是否消费过;

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值