目录

1. RocketMQ如何保证消息不丢失

1.1 分析消息丢失场景

1.2 解决方案

1.2.1 保证消息生产不丢失

1.2.1.1 生产消息时不使用单向发送消息发送模式

1.2.1.2 生产者使用事务消息机制

1.2.2 保证消息存储不丢失

1.2.3 保证消息消费不丢失

1.2.4 RocketMQ特有的问题，NameServer挂了如何保证消息不丢失？

2. 使用RocketMQ如何快速处理积压消息？

2.1 如何确定RocketMQ有大量的消息积压？

2.2 如何处理大量积压的消息？

---

1. RocketMQ如何保证消息不丢失

1.1 分析消息丢失场景

下图是一个MQ的通用场景图：

从上图中，我们可以得到，消息流转的4个环节

• 1：生产者发送消息到MQ服务
• 2：主从同步
• 3：同步磁盘
• 4：消费者消费消息

        其中1、3、4这3个环节都是跨网络的，而跨网络，那就可能会丢失消息。

        关于3这个环节，通常MQ存盘时都会先写入操作系统的缓存page cache中，然后再由操作异步的将消息写入硬盘。这个中间有个时间差，就可能会造成消息丢失。如果服务挂了，缓存中还没有来得及写入硬盘的消息就会丢失。

1.2 解决方案

        接下来我们看一下，当我们用RocketMQ时,如何解决上述4个环节丢失消息的场景；

1.2.1 保证消息生产不丢失

1.2.1.1 生产消息时不使用单向发送消息发送模式

        我们想一下，消息生产时为什么会丢失消息。当生产者发送消息时，如果出现了网络抖动或者消息异常，那么消息就有可能丢失。那么这个问题解决思路是什么呢？其实简单的来说就是4个字：应答重试。

        怎么理解应答重试呢？ 其实就是当生产者发送消息成功后返回成功确认消息，如果发送失败，客户端就尝试自动重试，避免网络抖动导致消息发送不成功。如果超过一定超时时间还是失败，那就抛出异常，由开发者自己在应用层面进行处理，手动重试发送 或者 记录失败。

     不过我们需要特别注意是，RocketMQ支持多种「消息类型」，但是并不是对所有「消息类型」 都会有应答重试机制（消息确认机制和失败重试机制）。

        RocketMQ生产消息时，支持多种「消息类型」和「消息发送模式」。有兴趣同学可以参考org.apache.rocketmq.client.producer.MQProducer这个接口定义即可。接下来我们看一下rocketMQ的消息类型和消息发送模式又哪些以及各自的特点：

消息类型：

• 普通消息：发送普通消息，异常时默认重试。
• 普通有序消息：发送普通有序消息，通过指定「消息筛选器selector」，动态决定发送哪个队列。异常默认不重试，可以用户自己重试，并发送到其他队列。
• 严格有序消息：发送严格有序消息，通过指定队列，保证严格有序，异常默认不重试。

消息发送模式：

• 同步：调用发送消息方法后，同步阻塞，直到返回SendResult。配置retryTimesWhenSendFailed重试次数。
• 异步：调用发送消息方法后，立即返回，发送结果会通过开发者自己注册的回调函数SendCallback进行处理。配置retryTimesWhenSendAsyncFailed重试次数。
• 单向发送：这种方法完全不关心发送后的返回结果。显然，它具有最大吞吐量，但也存在消息丢失的潜在风险。

        消息类型 和 消息发送模式 是 N * M 的关系，所以存在9种不同组合，RocketMQ也是定义了9种不同接口方法。
这9种方法里面，涉及到「单向发送」模式的3种方法，都是不可靠的，存在丢失消息的风险。其他发送消息的模式和消息类型，可以通过 消息确认、mq-client自动「失败重试机制」、业务自定义重试 等方式，确保消息发送不丢失。

1.2.1.2 生产者使用事务消息机制

        org.apache.rocketmq.client.producer.MQProducer还定义了「事务消息」的发送模式，接下来我们理解一下事务机制；因为RocketMQ的事务消息机制就是为了保证零丢失来设计的，并且经过阿里的 验证，肯定是非常靠谱的。所以事务机制也可以报纸生产者生产消息时不丢失消息。接下来我们用一个场景来简单分析一下事务消息机制是如何保证消息不丢失的。我们看下下面这个流程图：

2. 使用RocketMQ如何快速处理积压消息？

2.1 如何确定RocketMQ有大量的消息积压？

2.2 如何处理大量积压的消息？