大牛总结超详细的RabbitMQ入门，看这篇文章就够了！

V-xin：ruyuanhadeng获得600+页原创精品文章汇总PDF

目录

• 一、前情提示
• 二、ack机制回顾
• 三、ack机制实现原理：delivery tag
• 四、RabbitMQ如何感知仓储服务实例宕机
• 五、仓储服务处理失败时的消息重发
• 六、阶段总结

一、前情提示

上一篇文章《每次都碰到面试官问我如何保证Kafka不丢失消息，快哭了！》,我们初步介绍了之前制定的那些消息中间件数据不丢失的技术方案遗留的问题。

一个最大的问题，就是生产者投递出去的消息，可能会丢失。

丢失的原因有很多，比如消息在网络传输到一半的时候因为网络故障就丢了，或者是消息投递到MQ的内存时，MQ突发故障宕机导致消息就丢失了。

针对这种生产者投递数据丢失的问题，RabbitMQ实际上是提供了一些机制的。

---

比如，有一种重量级的机制，就是事务消息机制。采用类事务的机制把消息投递到MQ，可以保证消息不丢失，但是性能极差，经过测试性能会呈现几百倍的下降。

所以说现在一般是不会用这种过于重量级的机制，而是会用轻量级的confirm机制。

但是我们这篇文章还不能直接讲解生产者保证消息不丢失的confirm机制，因为这种confirm机制实际上是采用了类似消费者的ack机制来实现的。

所以，要深入理解confirm机制，我们得先从这篇文章开始，深入的分析一下消费者手动ack机制保证消息不丢失的底层原理。

---

二、ack机制回顾

其实手动ack机制非常的简单，必须要消费者确保自己处理完毕了一个消息，才能手动发送ack给MQ，MQ收到ack之后才会删除这个消息。

如果消费者还没发送ack，自己就宕机了，此时MQ感知到他的宕机，就会重新投递这条消息给其他的消费者实例。

通过这种机制保证消费者实例宕机的时候，数据是不会丢失的。

再次提醒一下大家，如果还对手动ack机制不太熟悉的同学，可以回头看一下之前的一篇文章：《车祸现场！线上突然宕机，一条订单消息丢失了…》。然后这篇文章，我们将继续深入探讨一下ack机制的实现原理。

---

三、ack机制实现原理：delivery tag

如果你写好了一个消费者服务的代码