1、什么情况会导致消息丢失？
a.发送时丢失：
生产者发送的消息未送达exchange
消息到达exchange后未到达queue
b.MQ宕机，queue将消息丢失
c.consumer接收到消息后未消费就宕机
2、如何保证息不丢失，就是分别避免每一个环节丢失
a.保证生产者不丢消息
b.保证rabbitmq不丢消息
c.保证消费端不丢消息
3、RabbitMQ生产者如何避免消息丢失？
a.保证生产者不丢消息，要确保说写rabbitmq的消息别丢，可以开启。
b.每次写的消息都会分配一个唯一的id，如果写入了rabbitmq中，rabbitmq会给你回传一个ack消息，告诉你说这个消息ok了。
c.如果rabbitmq没能处理这个消息，会回调你一个nack接口，告诉你这个消息接收失败，我们可以重试。
(publisher-confirm，发送者确认消息成功投递到交换机，返回ack；消息未投递到交换机，返回nack。publisher-return，发送者回执，消息投递到交换机，但是没有路由到队列。返回ACK，及路由失败原因。)
4、如何实现消息持久化？（注意：SpringAMQP默认已经进行持久化）
a.保证rabbitmq不丢消息，开启rabbitmq的持久化（持久化queue和message、exhange），设置不能自动删除
b.交换机持久化 ： 
c.持久化queue，在创建queue的时候将其设置为持久化的，这样就可以保证rabbitmq持久化queue的元数据，但是不会持久化queue里的数据。
d.持久化Message，在发送消息的时候将消息的deliveryMode设置为2，就是将消息设置为持久化的，此时rabbitmq就会将消息持久化到磁盘上去。
4、消费者有几种确认机制？
RabbitMQ支持消费者确认机制:消费者处理消息后可以向MQ发送ack回执，MQ收到ack回执后才会删除该消息。SpringAMQP允许配置三种确认模式：
none：关闭ack，MQ假定消费者获取消息后会成功处理，因此消息投递后立即被删除。
manual：手动ack，需要在业务代码结束后，调用api发送ack。
auto：自动ack，由spring监测listener代码是否出现异常，没有异常返回ack；有异常返回nack（默认）。（注意：auto默认方式，消费者消息处理异常后消息会重新入队，如果消费者一直异常则会一直死循环。）
方式是修改application.yml文件，添加下面配置： 
5、消费者消费失败后如何解决死循环导致MQ压力大？（注意：重试次数达到后，消息被丢弃。）
当消费者出现异常后，消息会不断requeue（重新入队）到队列，再重新发送给消费者，然后再次异常，再次requeue，无限循环，导致mq的消息处理飙升，带来不必要的压力：
我们可以利用Spring的retry机制，在消费者出现异常时利用本地重试，而不是无限制的requeue到mq队列。
开启Spring本地重试模式后，重试次数耗尽，如果消息依然失败，则需要有MessageRecoverer接口来处理，它包含三种不同的实现：
a.RejectAndDontRequeueRecoverer：重试耗尽后，直接reject，丢弃消息。默认就是这种方式。
b.ImmediateRequeueMessageRecoverer：重试耗尽后，返回nack，消息重新入队。
c.RepublishMessageRecoverer：重试耗尽后，将失败消息投递到指定的交换机(推荐使用)。 
测试下RepublishMessageRecoverer处理模式：
创建配置类ErrorMessageConfig，定义接收失败消息的交换机、队列及其绑定关系： 
然后，定义RepublishMessageRecoverer： 
6、如何确保RabbitMQ消息的可靠性（面试）？
1.开启生产者确认机制，确保生产者的消息能到达队列
2.开启持久化功能，确保消息未消费前在队列中不会丢失
3.开启消费者确认机制为auto，由spring确认消息处理成功后完成ack
4.开启消费者失败重试机制，配置重试次数、重试时间
5.改变默认失败重试策略，多次重试失败后将消息投递到异常交换机，交由人工处理
3410
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
