【MQ篇】初识RabbitMQ保证消息可靠性

🌟我的其他文章也讲解的比较有趣😁，如果喜欢博主的讲解方式，可以多多支持一下，感谢🤗！

🌟了解 MQ 请看 ： 【MQ篇】初识MQ！

其他优质专栏： 【🎇SpringBoot】【🎉多线程】【🎨Redis】【✨设计模式专栏（已完结）】…等

如果喜欢作者的讲解方式，可以点赞收藏加关注，你的支持就是我的动力
✨更多文章请看个人主页： 码熔burning

哈哈，老伙计，又见面了！😁 之前我们在 CSDN 上聊了 RabbitMQ 的那些“奇葩”事儿，这次咱们来聊聊它怎么当个“靠谱的”快递小哥，保证你的消息一个不丢！📦💨

你想想看，你的消息可能是啥？可能是老板的紧急指令 (“明天早上务必交报告！” 😱)，可能是老婆的购物清单 (“我要这个包包！👜✨”)，也可能是系统的关键通知 (“用户 XX 支付成功！💰”)。这些东西要是丢了，那可是要命的啊！☠️

所以，RabbitMQ 为了保证这些“重要包裹”安全送达，可是使出了浑身解数，从好几个方面层层把关，简直是消息界的“安全卫士”！🛡️

它是怎么做的呢？主要从这几个方面下手：

1. 发送方确认机制 (Publisher Confirms) - “你把包裹交给邮局了吗？邮局说收到没？” 🤔

   • 问题所在: 你（生产者 P）把消息发给了 RabbitMQ（邮局），但你咋知道 RabbitMQ 真收到了呢？万一网络抽风，或者 RabbitMQ 还没来得及处理就跪了？😵‍💫 你傻傻地以为发成功了，结果消息根本没到！
   • 怎么做: RabbitMQ 有个功能叫 Publisher Confirms。生产者发消息后，不是拍拍屁股就走人 👋。它会等着 RabbitMQ 给个“回执”——收到啦！👍 或者“没收到/处理失败”——啊哦！😭。
   • 好比: 你发了条微信消息给朋友，不是显示“已发送”就完事，还得等个“✓✓”或者“已读”标志，你心里才踏实。或者更像你把一封重要信件投到邮筒，你得等邮局给你发个短信说“您的邮件已揽收”你才放心，对吧？📨✅
   • 所以: 生产者开启这个功能后，只有收到 RabbitMQ 的确认，才认为消息成功发送。如果没收到确认或者收到失败通知，生产者就知道得重发这个消息了。贼靠谱！😎

2. 消息持久化 (Persistence) - “停电了？重启了？我的包裹还在吗？” 👻

   • 问题所在: RabbitMQ 运行在内存里，速度快是快，但万一它所在的服务器突然断电或者需要重启维护呢？⚡️💥 内存里的东西瞬间就没了啊！那队列里的消息不就灰飞烟灭了？🌪️
   • 怎么做: RabbitMQ 允许你把重要的东西“写下来”，存到硬盘上！硬盘这东西，除非物理损坏，不然断电重启也不丢数据。💾
   • 具体写啥？
     • 交换机 (Exchange) 和队列 (Queue) 可以声明为 durable (持久化)。 这就像在邮局里，那些重要的分拣台和信箱是用水泥钢筋造的 🏗️，不是临时的纸板箱。即使邮局大楼摇晃一下，这些关键设施还在。
     • 消息本身可以标记为 persistent (持久化)。 这就像你寄的包裹，上面贴了个“重要！防水防震防火！”的标签 🔥💧🛡️。即使 RabbitMQ 这个“快递仓库”需要暂时关闭或搬家，这些打了标签的包裹都会被妥善保管在库房的地下室（硬盘）里，等恢复正常再拿出来继续处理。
   • 所以: 把队列和消息都设置为持久化后，即使 RabbitMQ 服务器重启，之前收到的、还没来得及处理的持久化消息依然会在队列里乖乖等着，不会消失。厉害吧！💪

3. 消费者确认机制 (Consumer Acknowledgements) - “包裹送到了，客户签收并打开了吗？” 😉

   • 问题所在: RabbitMQ 把消息发给了消费者（C），消费者也收到了。但消费者收到后，可能需要花点时间处理（比如处理订单，发邮件等等）。万一消费者在处理过程中突然崩了呢？程序异常退出了？🐛👾 那消息虽然发给了它，但它压根没处理完啊！RabbitMQ 却可能以为“哦，消息发出去了，我的任务完成了！”然后就把这条消息删了。这就出问题了！❌
   • 怎么做: RabbitMQ 和消费者之间有个“签收”约定。当消费者收到消息后，它并不会立即告诉 RabbitMQ “搞定！”。它得等自己把消息里的事情办妥了，确信一切 OK 了，才会给 RabbitMQ 发一个“确认”信号 (ack)。
   • 好比: 快递员把包裹送到了你家门口，但他不会马上离开。他会等着你开门，拿包裹，甚至确认一下东西没问题了，你再给他一个“我收到啦，谢谢！”的手势或签字。✍️
   • 如果: 消费者在处理消息的过程中挂了，或者故意告诉 RabbitMQ “这个消息我处理不了！” (nack)，RabbitMQ 就知道这个消息没有被成功处理，它会把这个消息重新排队，或者发给另一个“闲着”的消费者去处理。这样就保证消息不会因为某个消费者的临时故障而丢失或未处理。超级负责！💯
   • 还有个偷懒模式叫 auto-ack: 消费者一收到消息就自动确认。这个方便是方便，但风险很大！就像快递员把包裹往门口一扔就跑路 🏃💨，他根本不管你有没有拿到，包裹会不会被别人捡走。所以对于重要消息，坚决不能开 auto-ack！🙅‍♀️

总的来说，RabbitMQ 就是通过生产者要确认、消息要存盘、消费者要签收这三重保险，构建了一个“消息永不丢失”的可靠传输体系。👍👍👍

当然，这只是最核心的几个点。更高级的玩法还有比如集群、镜像队列（多个 RabbitMQ 互相备份，一个倒了另一个顶上，就像两个邮局互相帮助不让包裹积压 👯‍♀️）等等，那又是更深的学问了。

怎么样，是不是觉得 RabbitMQ 这个快递小哥挺拼的？为了你的消息安全，真是操碎了心啊！😂 希望这次的“不正经”讲解，能让你对 RabbitMQ 的可靠性有更深刻（也更欢乐）的理解！🥳

后续会结合代码来讲解演示消息的确认机制和持久化，关注作者不迷路！