图解RocketMQ

消息队列近年来成了分布式系统中必不可少的框架，且在面试中也是屡见不鲜。于是苍何结合了多年开发经验以及项目经验肝了一份硬核的 RocketMQ 教程。 在想名字的时候，苍何实在是头疼

那么这一篇呢，苍何想给大家分享的是在面试中的高频面试题，**如何保证消息不丢失**？但凡你简历中写上消息队列，面试官贼喜欢问这个问题。

但凡是亲自部署过 RocketMQ 的小伙伴估计都跟我有一样的感受，岂是一个坑字了得。 RocketMQ 的迭代不算快，但出乎意料的是不同的版本之间部署的方式又不大一样。

当我们在淘宝下单后，会有提示说"下单后 15 分钟未支付将会自动取消订单"，大家有没有想过是如何实现这个功能呢？

说起事务消息，你可能和我一样一开始有一些懵逼，但说起事务和分布式事务，我想对于八股选手来说，再熟悉不过了。 事务消息就是利用消息队列实现分布式事务的一种解决方案。

要保证消息的顺序，要从生产端到 broker 消息存储，再到消费消息都要保证链路的顺序，才可以做到真正的顺序消息。

不得不说，一个优秀的中间件，往往会有很多**精妙的设计**，RocketMQ 的消息存储机制的设计就堪称完美。 当然，还有更多的细节，比如 commitlog 的加载流程、索引的存储结构，这些大家感

在上一篇[[图解RocketMQ之生产者如何进行消息重试]]中分析了当生产者发送消息失败的时候，RocketMQ 是如何进行重试的。 最后留了一个问题，生产端的消息是重试 hold

生产者向 RocketMQ 的 broker 发送消息时，因自身原因如网络波动等导致没有发送成功，这时发送端没收到 RocketMQ 的 ACK 心跳包。

我们详细介绍了 RocketMQ 的消息过滤机制，让消息投其所好，最大化发挥他该有的价值，这其中包含 tag 标签过滤和 SQL 属性过滤。

当有大量消息堆积的时候，RocketMQ 如何处理消息堆积？如何实现重复消费或者跳过部分消息不消费？

消费点位的设计非常灵活，当然了对于我们面试来说，同样也是有很多文章可以挖的，比如 RocketMQ 如何处理消息堆积，如何实现重复消费或者跳过部分消息不消费，我们将在下一篇继续深挖。

上一篇 图解RocketMQ之初识MQ 已经介绍了消息队列的基础概念、常用的消息队列框架以及 RocketMQ 的整体设计架构。 还没看过或者已经忘记的小伙伴可以看看上一篇哈。

图解RocketMQ之初识MQ，为了大家更好理解消息队列以及 RocketMQ，我将会通过好朋友鸡毛开餐馆的故事来展开