一个成长中的程序员，期待用技术的眼光生活

其实要回答好这个面试题，是需要系统的从多个角度来分析的，你可以从 RocketMQ 本身的维度，也可以从消费者、生产者维度，还可以从业务维度。当然如果你是面试官，我希望你可以更多关注面试者的理解程度，毕竟大家都是八股选手谁也别为难谁😂好啦，有关 RocketMQ 如何防止消息丢失教程就到这里啦，有疑惑和问题欢迎大家留言讨论。我是苍何，这是图解 RocketMQ 教程的第 13 篇，我们下篇见~

但凡是亲自部署过 RocketMQ 的小伙伴估计都跟我有一样的感受，岂是一个坑字了得。RocketMQ 的迭代不算快，但出乎意料的是不同的版本之间部署的方式又不大一样，你去上网查吧，大部分教程也没标注使用的是哪个版本。作为技术博主，我对教程是有着强烈洁癖的，我认为一切不标注时效的教程都不是好教程。正如你所看到的，我正写的保姆级部署教程是基于的这个版本，来自未来的读者，我希望你在实践之前能和我的版本保持一致。

定时好理解呀，就像鸡毛设定了一个下午两点要去买菜的闹钟，延时就是鸡毛 20 分钟后要去打酱油。定时是设定未来具体时间要干某事，延时则是推迟多久干某事。知道了什么是定时和延时，那定时消息和延时消息就是消息队列中一种特殊类型的消息，作用就是起到定时和延时的作用。定时消息是生产者指定一个确切的时间点，消息会在该时间点被投递。比如在 2024年12月25日00:00:00 发送一条"圣诞快乐"的消息。延时消息是生产者指定一个延迟时间，消息会在发送后经过指定的延迟时间后被投递。

我们先想象一个场景：从用户 A 的账户中扣减 100 元。向用户 B 的账户中增加 100 元。这两个步骤要么都成功，要么都失败。如果在步骤 1 扣减了100元，但步骤 2 增加时发生了错误，我们希望，用户A的账户金额恢复到原来的状态。上面是一个典型的事务场景，什么是事务？，简而言之，事务是逻辑上的一组操作，要么都执行，要么都不执行。下面有一道经典的八股，衡量事务的四大特性的了解程度，理解的背一下就好了。

大家好，我是苍何。顺序消息是业务中常用的功能之一，而 RocketMQ 默认发送的事普通无序的消息，那该如何发送顺序消息呢？要保证消息的顺序，要从生产端到 broker 消息存储，再到消费消息都要保证链路的顺序，才可以做到真正的顺序消息。

不得不说，一个优秀的中间件，往往会有很多精妙的设计，RocketMQ 的消息存储机制的设计就堪称完美。当然，还有更多的细节，比如 commitlog 的加载流程、索引的存储结构，这些大家感兴趣的可以自行查阅资料哈。好啦，今天的分享结束。我是苍何，这是图解 RocketMQ 教程的第 8 篇，我们下篇见~

大家好，我是苍何。在上一篇[[图解RocketMQ之生产者如何进行消息重试]]中分析了当生产者发送消息失败的时候，RocketMQ 是如何进行重试的。最后留了一个问题，生产端的消息是重试 hold 住了，但如果消费者出现异常，消费某一条消息失败，这时候 RocketMQ 会怎么处理呢？这还是很普遍的场景，试想一下如果订单系统发了个消息出去，库存系统消费这条消息失败，那会出现一个什么奇葩的现象呢？就是你明明下了单买了一包辣条，结果迟迟收不到货，一查人说你的辣条订单压根没出库。

大家好，我是苍何。上一篇留了一个小问题，如果消费者出现异常，消费某一条消息失败，这时候 RocketMQ 会怎么处理呢？你可能会用你聪明绝顶的脑袋瓜子想，苍何你是不是傻，失败了肯定重试啊，RocketMQ 一定有什么重试机制。没错，RocketMQ 就是用重试机制来解决消息消费失败问题，那如果我问你重试都有哪些策略呢？生产端和消费端如何进行消息重试呢？这个时候你肯定一脸懵逼，啥玩意？别急，我们这一篇就专门来叨叨 RocketMQ 的消息重试机制。

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

我们知道了重置消费位点可以解决消息堆积、重复消费历史消息、跳过消费某些消息等功能，可谓是收获满满呀。但这功能虽好用，也是带着很大风险的，特别是回溯重置类场景，可能会造成系统压力上升，因此也不是想重置就立马重置的，生产上需要严格控制好权限，做好评估。最后还有一点需要我们注意的是，RocketMQ 中重置消费位点只能重置对消费者可见的消息，不能重置定时中、重试等待中的消息，这部分消息如何处理我们后面也会介绍。好啦，本篇文章就到这里，我是苍何，这是图解 RocketMQ 教程的第 4 篇，我们下篇见~

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

我们先来看看官方定义：主题是 RocketMQ 中消息传输和存储的顶层容器，用于标识同一类业务逻辑的消息。我的理解主题就是消息的分类，比如上一篇说到的鸡毛的餐厅中订单消息是一类主题消息，顾客下单的消息都往订单消息这个主题里面发，那么同样鸡鸡毛的朋友狗毛约他去打球，就属于打球主题消息，依此类推，不难发现，主题消息的分类其实是受业务所决定的，你要发什么业务消息最好单独是一个 Topic 主题，大家相互之间互不干扰。现如今垃圾都要做好干湿分类，消息可不能一个 topic 干到底哦。定义数据的分类隔离。

为了大家更好理解消息队列以及 RocketMQ，我将会通过好朋友鸡毛开餐馆的故事来展开。“老板，我的酸菜鱼好了没，都等 20 分钟了！”坐在角落那桌的长腿女生极为不满的吼道。“就快了，稍等！”鸡毛一边用挂在脖子上的毛巾擦汗，一边看着满桌子的订单，活了大半辈子也没见像今天生意这么好的样子。鸡毛是个大厂退役的 Java 开发，拿着被裁的几个月赔偿费和多年来做牛马的一点积蓄，回老家开了个破烂的餐馆。餐馆是个收垃圾的铺子改造而来，一开始顾客总觉得餐馆有股难闻的气味，所以来的人基本保持在个位数左右。