面试题-18RebbitMq

rabbitMq

四种常用消息中间件比较分析(RabbitMQ、ActiveMQ、Kafka、RocketMQ)

你们公司生产环境用的是什么消息中间件？ 从吞吐量来说：kafka和rocketMq支持高吞吐 从持久化消息比较：ActiveMq 和
rabbitmq都支持 高并发来说：rabbitMq最好

异步处理 - 相比于传统的串行、并行方式，提高了系统吞吐量。 应用解耦 - 系统间通过消息通信，不用关心其他系统的处理。 流量削锋 -
可以通过消息队列长度控制请求量；可以缓解短时间内的高 并发请求。

解耦：

A 系统发送数据到 BCD 三个系统，通过接口调用发送。如果 E 系统也要这个数据呢？那如果 C 系统现在不需要了呢？A
系统负责人几乎崩溃…A 系统跟其它各种乱七八糟的系统严重耦合，A 系统产生一条比较关键的数据，很多系统都需要 A
系统将这个数据发送过来。如果使用 MQ，A 系统产生一条数据，发送到 MQ 里面去，哪个系统需要数据自己去 MQ
里面消费。如果新系统需要数据，直接从 MQ 里消费即可；如果某个系统不需要这条数据了，就取消对 MQ 消息的消费即可。这样下来，A
系统压根儿不需要去考虑要给谁发送数据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。
就是一个系统或者一个模块，调用了多个系统或者模块，互相之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的，如果用
MQ 给它异步化解耦。

异步：

A 系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系统写库，自己本地写库要 3ms，BCD 三个系统分别写库要
300ms、450ms、200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms，接近
1s，用户感觉搞个什么东西，慢死了慢死了。用户通过浏览器发起请求。如果使用 MQ，那么 A 系统连续发送 3 条消息到 MQ
队列中，假如耗时 5ms，A 系统从接受一个请求到返回响应给用户，总时长是 3 + 5 = 8ms。

削峰：

减少高峰时期对服务器压力。

介绍Rabbitmq的手动ACK和自动ACK

当消息一旦被消费者接收，队列中的消息就会被删除。那么问题来了：RabbitMQ怎么知道消息被接收了呢？
这就要通过消息确认机制（Acknowlege）来实现了。当消费者获取消息后，会向RabbitMQ发送回执ACK，告知消息已经被接收。不过这种回执ACK分两种情况：
自动ACK：消息一旦被接收，消费者自动发送ACK 手动ACK：消息接收后，不会发送ACK，需要手动调用
这两ACK要怎么选择呢？这需要看消息的重要性： 如果消息不太重要，丢失也没有影响，那么自动ACK会比较方便
如果消息非常重要，不容丢失。那么最好在消费完成后手动ACK，否则接收消息后就自动ACK，RabbitMQ就会把消息从队列中删除。如果此时消费者宕机，那么消息就丢失了。

消息可靠性： 生产者向MQ发送消息到exchange 由于网络等问题，消息没有发送成功，怎么办？ 用confirm 生产者出错
confirm 消费者出错手动 ack

spring.rabbitmq.publisher-confirm-type=simple
spring.rabbitmq.publisher-returns=true

@Component
public class PublisherConfirmAndReturnConfig implements RabbitTemplate.ConfirmCallback,RabbitTemplate.ReturnsCallback{
@Autowired
private RabbitTemplate rabbitTemplate;
@PostConstruct
public void initMethod(){
rabbitTemplate.setConfirmCallback(this);
rabbitTemplate.setReturnsCallback(this);
}

@Override
public void confirm(CorrelationData correlationData, boolean b, String s) {
if(b){
System.out.println("消息已经发送到exchange");
}else {
System.out.println("消息发送失败");
}
}

@Override
public void returnedMessage(ReturnedMessage returnedMessage) {
System.out.println("消息没有发送到queue！！！！");
}
}

只需要修改生产者 让它找不到队列，就可以回调
rabbitTemplate.convertAndSend("boot-topic-exchange","slow.red.dog","慢红狗");//将 red -----> xxx就可以测试
System.in.read();

重复问题

当生产者生产消息通过 rabbitMq 发给 消费者，消费者消费户回调 ack 但是它没有回调，这是 rabbitmq
以为为发送成功，再次发送，给了消费者2号 这就造成了消息重复
幂等性：可以重复操作 非幂等：不可以，如付钱

再redis 里设置消息 的id 如果是0 表示正在执行 1 表示 执行业务成功 即使不返回给 mq ack 也没问题
因为当mq没有接受到ack 后，它将消息发送给了 2号消费者，2号消费者在消费之前，将信息的id通过 setnx的方式存入redis
如果key已经存在了，获取他的值，如果是0 2号消费者甚麽也不做，如果是1 直接返回 ack 防止mq再将信息发给其他消费者

极端情况：第一个消费者执行业务时，出现了死锁，这样的话消息一直被占用，给它设置一个生存时间，这样，例如要添加一个数据
如果超时了，那就删除key

1、什么是RabbitMQ？为什么使用RabbitMQ？
答：RabbitMQ是一款开源的，Erlang编写的，基于AMQP协议的，消息中间件；
可以用它来：解耦、异步、削峰。

2、RabbitMQ有什么优缺点？
答：优点：解耦、异步、削峰；
缺点：降低了系统的稳定性：本来系统运行好好的，现在你非要加入个消息队列进去，那消息队列挂了，你的系统不是呵呵了。因此，系统可用性会降低；
增加了系统的复杂性：加入了消息队列，要多考虑很多方面的问题，比如：一致性问题、如何保证消息不被重复消费、如何保证消息可靠性传输等。因此，需要考虑的东西更多，复杂性增大。

3、如何保证RabbitMQ的高可用？
答：没有哪个项目会只用一搭建一台RabbitMQ服务器提供服务，风险太大；

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

5、如何保证RabbitMQ消息的可靠传输？
答：消息不可靠的情况可能是消息丢失，劫持等原因；
丢失又分为：生产者丢失消息、消息列表丢失消息、消费者丢失消息；

生产者丢失消息：从生产者弄丢数据这个角度来看，RabbitMQ提供transaction和confirm模式来确保生产者不丢消息；
transaction机制就是说：发送消息前，开启事务（channel.txSelect()）,然后发送消息，如果发送过程中出现什么异常，事务就会回滚（channel.txRollback()）,如果发送成功则提交事务（channel.txCommit()）。然而，这种方式有个缺点：吞吐量下降；
confirm模式用的居多：一旦channel进入confirm模式，所有在该信道上发布的消息都将会被指派一个唯一的ID（从1开始），一旦消息被投递到所有匹配的队列之后；
rabbitMQ就会发送一个ACK给生产者（包含消息的唯一ID），这就使得生产者知道消息已经正确到达目的队列了；
如果rabbitMQ没能处理该消息，则会发送一个Nack消息给你，你可以进行重试操作。

消息队列丢数据：消息持久化。
处理消息队列丢数据的情况，一般是开启持久化磁盘的配置。
这个持久化配置可以和confirm机制配合使用，你可以在消息持久化磁盘后，再给生产者发送一个Ack信号。
这样，如果消息持久化磁盘之前，rabbitMQ阵亡了，那么生产者收不到Ack信号，生产者会自动重发。
那么如何持久化呢？
这里顺便说一下吧，其实也很容易，就下面两步
1.将queue的持久化标识durable设置为true,则代表是一个持久的队列
2.发送消息的时候将deliveryMode=2
这样设置以后，即使rabbitMQ挂了，重启后也能恢复数据

消费者丢失消息：消费者丢数据一般是因为采用了自动确认消息模式，改为手动确认消息即可！
消费者在收到消息之后，处理消息之前，会自动回复RabbitMQ已收到消息；
如果这时处理消息失败，就会丢失该消息；
解决方案：处理消息成功后，手动回复确认消息。

6、如何保证RabbitMQ消息的顺序性？
答：单线程消费保证消息的顺序性；对消息进行编号，消费者处理消息是根据编号处理消息；