《rabbitmq》专题

主要内容：一、前情提示,二、保证投递消息不丢失的confirm机制,三、confirm机制的代码实现,四、confirm机制投递消息的高延迟性,五、高并发下如何投递消息才能不丢失,六、消息中间件全链路100%数据不丢失能做到吗？一、前情提示 我们分析了RabbitMQ开启手动ack机制保证消费端数据不丢失的时候，prefetch机制对消费者的吞吐量以及内存消耗的影响。 通过分析，我们知道了prefetch过大容易导致内存溢出，prefetch过小又会导致消费吞吐量过低，所以在实际项目中需要慎重测

主要内容：一、前情提示,二、unack消息的积压问题,三、如何解决unack消息的积压问题,四、高并发场景下的内存溢出问题,五、低吞吐量问题,六、合理的设置prefetch count,七、阶段性总结一、前情提示 这篇文章，我们将会对ack底层的delivery tag机制进行更加深入的分析，让大家理解的更加透彻一些。 面试时，如果被问到消息中间件数据不丢失问题的时候，可以更深入到底层，给面试官进行分析。 二、unack消息的积压问题 首先，我们要给大家介绍一下RabbitMQ的prefetch

主要内容：一、前情提示,二、ack机制回顾,三、ack机制实现原理：delivery tag,四、RabbitMQ如何感知到仓储服务实例宕机,五、仓储服务处理失败时的消息重发,六、阶段总结一、前情提示 生产者投递出去的消息，可能会丢失，丢失的原因有很多，比如消息在网络传输到一半的时候因为网络故障就丢了，或者是消息投递到MQ的内存时，MQ突发故障宕机导致消息就丢失了。 针对这种生产者投递数据丢失的问题，RabbitMQ实际上是提供了一些机制的。 比如，有一种重量级的机制，就是事务消息机制。采用类事

主要内容：一、前情提示,二、选择性的订阅部分核心数据,三、RabbitMQ的queue与exchange的绑定,四、direct exchange实现消息路由,五、按需订阅的代码实现,六、更加强大而且灵活的按需订阅一、前情提示 上一篇文章《教你面试的时候如何迅速完成90%以上的海量数据处理题》，我们已经给出了一整套的数据一致性的保障方案。 我们从如下三个角度，给出了方案如何实现。并且通过数据平台和电商系统进行了举例分析。 核心数据的监控 数据链路追踪 自动化数据链路分析 目前为止，我们的架构图大

可靠消费 Redis：没有相应的机制保证消息的消费，当消费者消费失败的时候，消息体丢失，需要手动处理 RabbitMQ：具有消息消费确认，即使消费者消费失败，也会自动使消息体返回原队列，同时可全程持久化，保证消息体被正确消费 可靠发布 Reids：不提供，需自行实现 Redis的消息队列，如果在从队列pop出去的时候，worker处理失败的话，数据不会回到队列中，需要从业务中手动把失败的处理数据p

主要内容：1.如何保证RabbitMQ消息的顺序性？,2.消息如何分发？,3.消息怎么路由？,4.消息基于什么传输？,5.如何保证消息不被重复消费？或者说，如何保证消息消费时的幂等性？,6.如何确保消息正确地发送至 RabbitMQ？ 如何确保消息接收方消费了消息？,7.如何保证RabbitMQ消息的可靠传输？,8.为什么不应该对所有的 message 都使用持久化机制,9.如何保证高可用的？RabbitMQ 的集群,,1.如何保证RabbitMQ消息的顺序性？ 拆分多个 queue，每个 qu

主要内容：如何确保消息正确地发送至 RabbitMQ？ 如何确保消息接收方消费了消息,如何避免消息重复投递或重复消费,消息基于什么传输,消息如何分发,消息怎么路由,如何确保消息持久化,RabbitMQ 的集群,mq 的缺点,rabbitmq的工作模式如何确保消息正确地发送至 RabbitMQ？ 如何确保消息接收方消费了消息 发送方确认模式 将信道设置成 confirm 模式（发送方确认模式），则所有在信道上发布的消息都会被指派一个唯一的 ID。 一旦消息被投递到目的队列后，或者消息被写入磁盘后（

主要内容：9. RabbitMQ 其他知识点,9.1 幂等性,9.2 优先级队列,9.3 惰性队列9. RabbitMQ 其他知识点 9.1 幂等性 9.1.1 概念 用户对于统一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生副作用 举个栗子，用户购买商品后支付，支付扣款成功，但是返回结果的时候网络异常，此时钱已经扣了，用户再次点击按钮，会进行第二次扣款，返回结果依然成功。用户查询余额发现多扣钱了，流水记录也变成了两条。 在以前的但应用系统中，我们只需要把数据操作放入事务

主要内容：8. 发布高级确认,8.1 发布确认SpringBoot版本,8.2 回退消息,8.3 备份交换机8. 发布高级确认 在生产环境中由于一些不明原因，导致RabbitMQ重启，在RabbitMQ重启期间生产者消息投递失败，导致消息丢失，需要手动处理和恢复 于是，我们开始思考，如何才能进行RabbitMQ的消息可靠投递呢？特别是在这样比较极端的情况下，RabbitMQ集群不可用的时候，无法投递的消息该如何处理呢？ 8.1 发布确认SpringBoot版本 8.1.1 发布确认方案 当交换机

主要内容：7. 延迟队列,7.1 延迟队列的概念,7.2 延迟队列使用场景,7.4 整合SpringBoot,7.5 队列TTL,7.6 延迟队列优化,7.7 RabbitMQ 插件实现延迟队列,7.8 总结7. 延迟队列 7.1 延迟队列的概念 延迟队列，队列内部是有序的，最重要的特性就体现在它的延迟属性上。 延迟队列中的元素是希望在指定时间到了以后或之前取出和处理。简单来说，延迟队列就是用来存放需要在指定时间被处理的元素的队列。 延迟队列属于死信队列的一种，属于消息TTL过期的情况。 7.2

主要内容：6. 死信队列,6.1 死信的概念,6.2 死信的来源,6.3 死信实战6. 死信队列 6.1 死信的概念 死信，顾名思义就是无法被消费的消息。 字面意思可以这样理解，一般来说，producer（生产者）将消息投递到 broker 或者直接到 queue（队列）里了。consumer（消费者）从queue中取出消息后进行消费，但某些时候由于特定的原因导致 queue 中的消息无法被消费，这样的消息如果没有后续的处理，就变成了死信，有死信自然就有了死信队列。 应用场景：

主要内容：5. 交换机,,5.1 Exchanges,5.2 临时队列,5.3 绑定（binding）,5.4 Fanout 扇出模式（发布/订阅）,5.5 Direct exchange 直接交换机（路由模式）,5.6 Topics （主题模式）5. 交换机 假设工作队列背后，每个人物都恰好交付给一个消费者（工作进程）。在这一部分中，会将消息传达给多个消费者，这种模式被称为 “发布/订阅”。 5.1 Exchanges 5.1.1 Exchanges 概念 RabbitMQ 消息传递模型的核心

发布确认原理 生产者将信道设置成 confirm 模式，一旦信道进入 confirm 模式，所有在该信道上的消息都会被指派一个唯一的 ID（从一开始），一旦消息被投递到所有匹配的队列后，broker 就会发送一个确认给生产者（包含消息的唯一ID），这就使得生产者知道消息已经正确到达目的队列了 如果消息和队列是持久化的，那么确认消息会在将消息写入磁盘后发出，broker 回传给生产者的确认消息中 ，

概念 之前的消息应答部分已经看到了如何处理消息不丢失的情况，但是如何保障当 RabbitMQ服务停掉之后消息生产者发送过来的消息不丢失呢？ 默认情况下，RabbitMQ退出或者由于某种原因崩溃的时候，它会忽视队列和消息，除非告知它不要这样做。 确保消息不会丢失需要做两件事：将队列和消息都标记为持久化。 队列实现持久化 之前创建的队列都是非持久化的，RabbitMQ如果重启，该队列就会被删掉，如果要

概念 消费者完成一个任务可能需要一段时间，如果其中一个消费者处理一个长的任务并且只完成了一部分，如果它突然挂掉了，会发生什么情况？ RabbitMQ一旦向消费者传递了一条消息，就会立即将该消息标记为删除。在这种情况下突然有个消费者挂掉了，将会丢失正在处理的信息，以及后续应该发送给该消费者的信息，因为该消费者无法接收到 为了保证消息在发送过程中不丢失，RabbitMQ引入消息应答机制 消息应答机制指