RabbitMQ入门，武汉软通动力大数据开发面试

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新大数据全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip204888 （备注大数据）

正文

+ [如何处理真实的消息堆积](#_52)
+ [PS](#PS_58)

RabbitMQ

如何保证消息不丢失

• 生产者发送消息后, mq提供ack应答机制, 保证消息发送到mq中, 若未ack触发重发机制
• mq消息存盘. mq提供存盘机制, 但是这里存盘并非是一定不会丢失, 只是在丢失的时候我们还可以去磁盘恢复消息, 但是如果本身mq宕机了, 消息来不及存储到磁盘, 那么消息还是会丢失
• 主从节点之间采用同步策略, 镜像同步
• 在mq到消费者的过程中, 有手动应答和自动应答两种措施.
  • 自动应答是消费者完成消费后自动出发应答, 如果消费者因为业务错误而抛出异常, mq会将消息重试, 这就可能造成消息重复消费, 本身消息传递是没问题的.(比如减库存的业务逻辑错误, 我们不可能将减库存的消息一直发送到业务层, 那将导致库存持续减, 并且这条消息还一直存在mq中, 导致消息积压) 如果我们业务逻辑将异常捕获了, 也可能造成消息并没有消费但是会自动应答后删除, 这就导致了消息丢失
  • 手动应答是指消费者在消费成功后向mq返回消费成功的信息, 如果消费失败就会发送消费失败的消息, 保证mq暂时不删除消息, 手动应答显然比自动应答更能保证可靠性

如何保证消息不被重复消费/幂等性

上面我们说到自动应答的时候会导致消息重复消费, 当消息重复消费时, 业务逻辑的幂等性无法保证, 我们必须保证同一个请求, 重复多次的时候, 对应的数据是不会改变的, 不能出错.

这里提供一些思路

• 设置mq重试次数
• 业务上也需要进行幂等性处理, 可以给每一个消息加上唯一标识, 在消费端进行幂等性判断(比如我们使用订单号作为唯一标识, 那么这个订单就只能执行一次)
• 及时将消息放入死信队列

当然了, 还要结合具体的业务场景

• 比如我们在redis的set进行处理的时候, 天生的幂等性甚至可以避开我们的处理
• 还有在数据库层面, 如果有唯一约束来约束消息中的操作, 也会报错

如何保证消息顺序

在RabbitMQ中, 顺序性的设计偏弱, 我们知道要想满足顺序性, 那么单队列单消息推送是最好的选择, 但是这样就会导致在损耗性能的同时, 我们处理消息的能力还这么低, 白白浪费了大好资源, 通常的情况会使用多队列多消费者, 但是一个队列对应一个消费者, 在消费者内部进行并发处理消息
这里RabbitMQ提供了对应的配置, 例如使用在SSM项目中我们可以配置spring.rabbitmq.listener.simple.prefetch=1 达到单消费者消费的目的

如何预防消息堆积

RabbitMQ处理消息堆积的能力也偏弱, 在大量消息堆积的情况下, 性能会严重下降

(消息堆积导致RabbitMQ需要不断的将消息存储检索传递, 使得CPU使用率升高, 消费者重试也会花费cpu资源)

• 一般情况下, 尽量满足消费速度和生产速度的一致
• 在生产消息的时候可以多批消息一起发送, 减少IO
• 在MQ处, 可以选择分片队列存储消息, 减少单个队列堆积消息
• 消费者端要增加消费者数量, 尽快消费消息

当然了, 其实最一劳永逸的办法就是换成性能更高的消息队列hhhh

如何处理真实的消息堆积

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip204888 （备注大数据）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！**