RocketMQ消息丢失的常见情形及应对策略有哪些？
- 内容介绍
- 文章标签
- 相关推荐
本文共计2102个文字，预计阅读时间需要9分钟。
在项目中使用MQ时，不可避免地需要考虑消息丢失问题。特别是在涉及金钱交易的场景下，消息丢失显得尤为致命。RocketMQ中存在几种可能导致消息丢失的场景：
1. 生产者端消息发送失败：如果生产者在发送消息时遇到网络问题或服务异常，消息可能没有被正确发送到MQ。
2.消费者端消费失败：消费者在处理消息时可能因为各种原因（如业务逻辑错误、系统异常等）导致消息处理失败，未能正确消费。
3.消息队列内部问题：MQ内部可能存在故障，如消息队列崩溃、数据损坏等，导致消息丢失。
4.消息确认机制失效：在某些情况下，消费者可能因为网络问题或其他原因未能及时确认消息，导致消息被认为是未消费状态。
RocketMQ提供了多种机制来避免和解决消息丢失问题：
- 消息持久化：确保消息在发送到MQ时被持久化存储，防止因系统故障导致消息丢失。
- 消息重试机制：当消息发送或消费失败时，系统可以自动重试，直到消息成功发送或消费。- 消息确认：消费者在处理完消息后需要向生产者发送确认，确认消息已被成功消费。- 消息顺序性保证：RocketMQ保证消息的顺序性，确保消息按照发送顺序被消费。通过这些机制，RocketMQ能够有效减少消息丢失的风险。
既然使用在项目中使用了MQ，那么就不可避免的需要考虑消息丢失问题。在一些涉及到了金钱交易的场景下，消息丢失还是很致命的。那么在RocketMQ中存在哪几种消息丢失的场景呢？
先来一张最简单的消费流程图：
上图中大致包含了这么几种场景：
生产者产生消息发送给RocketMQRocketMQ接收到了消息之后，必然需要存到磁盘中，否则断电或宕机之后会造成数据的丢失消费者从RocketMQ中获取消息消费，消费成功之后，整个流程结束
这三种场景都可能会产生消息的丢失，如下图所示：
场景1中生产者将消息发送给Rocket MQ的时候，如果出现了网络抖动或者通信异常等问题，消息就有可能会丢失场景2中消息需要持久化到磁盘中，这时会有两种情况导致消息丢失
①RocketMQ为了减少磁盘的IO，会先将消息写入到os cache中，而不是直接写入到磁盘中，消费者从os cache中获取消息类似于直接从内存中获取消息，速度更快，过一段时间会由os线程异步的将消息刷入磁盘中，此时才算真正完成了消息的持久化。在这个过程中，如果消息还没有完成异步刷盘，RocketMQ中的Broker宕机的话，就会导致消息丢失
②如果消息已经被刷入了磁盘中，但是数据没有做任何备份，一旦磁盘损坏，那么消息也会丢失消费者成功从RocketMQ中获取到了消息，还没有将消息完全消费完的时候，就通知RocketMQ我已经将消息消费了，然后消费者宕机，但是RocketMQ认为消费者已经成功消费了数据，所以数据依旧丢失了
那么如何保证消息的零丢失呢？
1、场景1中保证消息不丢失的方案是使用RocketMQ自带的事务机制来发送消息，大致流程为
①首先生产者发送half消息到RocketMQ中，此时消费者是无法消费half消息的，若half消息就发送失败了，则执行相应的回滚逻辑
②half消息发送成功之后，且RocketMQ返回成功响应，则执行生产者的核心链路
③如果生产者自己的核心链路执行失败，则回滚，并通知RocketMQ删除half消息
④如果生产者的核心链路执行成功，则通知RocketMQ commit half消息，让消费者可以消费这条数据
其中还有一些RocketMQ长时间没有收到生产者是要commit/rollback操作的响应，回调生产者接口的细节，感兴趣的可以参考文末的 RocketMQ分布式事务原理
在使用了RocketMQ事务将生产者的消息成功发送给RocketMQ，就可以保证在这个阶段消息不会丢失在场景2中要保证消息不丢失，首先需要将os cache的异步刷盘策略改为同步刷盘，这一步需要修改Broker的配置文件，将flushDiskType改为SYNC_FLUSH同步刷盘策略，默认的是ASYNC_FLUSH异步刷盘。一旦同步刷盘返回成功，那么就一定保证消息已经持久化到磁盘中了；为了保证磁盘损坏不会丢失数据，我们需要对RocketMQ采用主从机构，集群部署，Leader中的数据在多个Follower中都存有备份，防止单点故障。在场景3中，消息到达了消费者，RocketMQ在代码中就能保证消息不会丢失
//注册消息监听器处理消息 consumer.registerMessageListener(new MessageListenerConcurrently() { @Override public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context){ //对消息进行处理 return ConsumeConcurrentlyStatus.CONSUME_SUCCESS; } });
上面这段代码中，RocketMQ在消费者中注册了一个监听器，当消费者获取到了消息，就会去回调这个监听器函数，去处理里面的消息
当你的消息处理完毕之后，才会返回ConsumeConcurrentlyStatus.CONSUME_SUCCESS
只有返回了CONSUME_SUCCESS，消费者才会告诉RocketMQ我已经消费完了，此时如果消费者宕机，消息已经处理完了，也就不会丢失消息了
如果消费者还没有返回CONSUME_SUCCESS时就宕机了，那么RocketMQ就会认为你这个消费者节点挂掉了，会自动故障转移，将消息交给消费者组的其他消费者去消费这个消息，保证消息不会丢失
为了保证消息不会丢失，在consumeMessage方法中就直接写消息消费的业务逻辑就可以了，如果非要搞一些骚操作，比如下面的代码
//注册消息监听器处理消息 consumer.registerMessageListener(new MessageListenerConcurrently() { @Override public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context){ //开启子线程异步处理消息 new Thread() { public void run() { //对消息进行处理 } }.start(); return ConsumeConcurrentlyStatus.CONSUME_SUCCESS; } });
如果新开子线程异步处理消息的话，就有可能出现消息还没有被消费完，消费者告诉RocketMQ消息已经被消费了，结果宕机丢失消息的情况。
使用上面一整套的方案就可以在使用RocketMQ时保证消息零丢失，但是性能和吞吐量也将大幅下降
使用事务机制传输消息，会比普通的消息传输多出很多步骤，耗费性能同步刷盘相比异步刷盘，一个是存储在磁盘中，一个存储在内存中，速度完全不是一个数量级主从架构的话，需要Leader将数据同步给Follower消费时无法异步消费，只能等待消费完成再通知RocketMQ消费完成
消息零丢失是一把双刃剑，要想用好，还是要视具体的业务场景而定，选择合适的方案才是最好的
RocketMQ分布式事务原理
分布式事务常见的方案有TCC（Try-Confirm-Cancel），XA两阶段提交方案，可靠消息最终一致性方案，最大努力通知方案等等。其中可靠消息最终一致性方案主要就可以依靠RocketMQ来做，因为RocketMQ支持消息事务。先上一张图：
RocketMQ 事务消息的实现步骤如下：
- Producer发送half message给RocketMQ
- RocketMQ返回half message success（half message发送成功之后RocketMQ的消费者并不能消费这条消息，因为消息存储在Topic为 RMQ_SYS_TRANS_HALF_TOPIC 的消息消费队列中，而不是原先的Topic）
- 执行核心交易链路
- 返回执行交易链路的结果，如果失败则回滚
- 如果执行成功，则Producer返回一个COMMIT状态给RocketMQ
- 如果RocketMQ迟迟收不到Producer的返回结果，即这条消息的状态为UNKNOWN，则会回调服务接口，查询这条消息到底是commit还是rollback
- RocketMQ确认消息为commit，则Consumer可以消费到这条消息
- Consumer操作数据库，执行自己的事务
- Consumer成功消费之后返回一个ACK消息给RocketMQ，如果成功消费则显示消费成功，否则RocketMQ会重发消息给Consumer继续消费
RocketMQ 事务消息的实现原理基于两阶段提交和定时事务状态回查来决定消息最终是提交还是回滚，RocketMQ 先执行第一部分的事务，如果失败则回滚，如果成功则定时任务会去回查到事务执行成功，这个时候通知消费者执行第二阶段的事务，如果失败则不断重发消息给消费者消费，如果成功则整个流程走完，保证了事务的原子性。
总结
到此这篇关于RocketMQ消息丢失场景以及解决方法的文章就介绍到这了,更多相关RocketMQ消息丢失场景内容请搜索易盾网络以前的文章或继续浏览下面的相关文章希望大家以后多多支持易盾网络！
本文共计2102个文字，预计阅读时间需要9分钟。
在项目中使用MQ时，不可避免地需要考虑消息丢失问题。特别是在涉及金钱交易的场景下，消息丢失显得尤为致命。RocketMQ中存在几种可能导致消息丢失的场景：
1. 生产者端消息发送失败：如果生产者在发送消息时遇到网络问题或服务异常，消息可能没有被正确发送到MQ。
2.消费者端消费失败：消费者在处理消息时可能因为各种原因（如业务逻辑错误、系统异常等）导致消息处理失败，未能正确消费。
3.消息队列内部问题：MQ内部可能存在故障，如消息队列崩溃、数据损坏等，导致消息丢失。
4.消息确认机制失效：在某些情况下，消费者可能因为网络问题或其他原因未能及时确认消息，导致消息被认为是未消费状态。
RocketMQ提供了多种机制来避免和解决消息丢失问题：
- 消息持久化：确保消息在发送到MQ时被持久化存储，防止因系统故障导致消息丢失。
- 消息重试机制：当消息发送或消费失败时，系统可以自动重试，直到消息成功发送或消费。- 消息确认：消费者在处理完消息后需要向生产者发送确认，确认消息已被成功消费。- 消息顺序性保证：RocketMQ保证消息的顺序性，确保消息按照发送顺序被消费。通过这些机制，RocketMQ能够有效减少消息丢失的风险。
既然使用在项目中使用了MQ，那么就不可避免的需要考虑消息丢失问题。在一些涉及到了金钱交易的场景下，消息丢失还是很致命的。那么在RocketMQ中存在哪几种消息丢失的场景呢？
先来一张最简单的消费流程图：
上图中大致包含了这么几种场景：
生产者产生消息发送给RocketMQRocketMQ接收到了消息之后，必然需要存到磁盘中，否则断电或宕机之后会造成数据的丢失消费者从RocketMQ中获取消息消费，消费成功之后，整个流程结束
这三种场景都可能会产生消息的丢失，如下图所示：
场景1中生产者将消息发送给Rocket MQ的时候，如果出现了网络抖动或者通信异常等问题，消息就有可能会丢失场景2中消息需要持久化到磁盘中，这时会有两种情况导致消息丢失
①RocketMQ为了减少磁盘的IO，会先将消息写入到os cache中，而不是直接写入到磁盘中，消费者从os cache中获取消息类似于直接从内存中获取消息，速度更快，过一段时间会由os线程异步的将消息刷入磁盘中，此时才算真正完成了消息的持久化。在这个过程中，如果消息还没有完成异步刷盘，RocketMQ中的Broker宕机的话，就会导致消息丢失
②如果消息已经被刷入了磁盘中，但是数据没有做任何备份，一旦磁盘损坏，那么消息也会丢失消费者成功从RocketMQ中获取到了消息，还没有将消息完全消费完的时候，就通知RocketMQ我已经将消息消费了，然后消费者宕机，但是RocketMQ认为消费者已经成功消费了数据，所以数据依旧丢失了
那么如何保证消息的零丢失呢？
1、场景1中保证消息不丢失的方案是使用RocketMQ自带的事务机制来发送消息，大致流程为
①首先生产者发送half消息到RocketMQ中，此时消费者是无法消费half消息的，若half消息就发送失败了，则执行相应的回滚逻辑
②half消息发送成功之后，且RocketMQ返回成功响应，则执行生产者的核心链路
③如果生产者自己的核心链路执行失败，则回滚，并通知RocketMQ删除half消息
④如果生产者的核心链路执行成功，则通知RocketMQ commit half消息，让消费者可以消费这条数据
其中还有一些RocketMQ长时间没有收到生产者是要commit/rollback操作的响应，回调生产者接口的细节，感兴趣的可以参考文末的 RocketMQ分布式事务原理
在使用了RocketMQ事务将生产者的消息成功发送给RocketMQ，就可以保证在这个阶段消息不会丢失在场景2中要保证消息不丢失，首先需要将os cache的异步刷盘策略改为同步刷盘，这一步需要修改Broker的配置文件，将flushDiskType改为SYNC_FLUSH同步刷盘策略，默认的是ASYNC_FLUSH异步刷盘。一旦同步刷盘返回成功，那么就一定保证消息已经持久化到磁盘中了；为了保证磁盘损坏不会丢失数据，我们需要对RocketMQ采用主从机构，集群部署，Leader中的数据在多个Follower中都存有备份，防止单点故障。在场景3中，消息到达了消费者，RocketMQ在代码中就能保证消息不会丢失
//注册消息监听器处理消息 consumer.registerMessageListener(new MessageListenerConcurrently() { @Override public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context){ //对消息进行处理 return ConsumeConcurrentlyStatus.CONSUME_SUCCESS; } });
上面这段代码中，RocketMQ在消费者中注册了一个监听器，当消费者获取到了消息，就会去回调这个监听器函数，去处理里面的消息
当你的消息处理完毕之后，才会返回ConsumeConcurrentlyStatus.CONSUME_SUCCESS
只有返回了CONSUME_SUCCESS，消费者才会告诉RocketMQ我已经消费完了，此时如果消费者宕机，消息已经处理完了，也就不会丢失消息了
如果消费者还没有返回CONSUME_SUCCESS时就宕机了，那么RocketMQ就会认为你这个消费者节点挂掉了，会自动故障转移，将消息交给消费者组的其他消费者去消费这个消息，保证消息不会丢失
为了保证消息不会丢失，在consumeMessage方法中就直接写消息消费的业务逻辑就可以了，如果非要搞一些骚操作，比如下面的代码
//注册消息监听器处理消息 consumer.registerMessageListener(new MessageListenerConcurrently() { @Override public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context){ //开启子线程异步处理消息 new Thread() { public void run() { //对消息进行处理 } }.start(); return ConsumeConcurrentlyStatus.CONSUME_SUCCESS; } });
如果新开子线程异步处理消息的话，就有可能出现消息还没有被消费完，消费者告诉RocketMQ消息已经被消费了，结果宕机丢失消息的情况。
使用上面一整套的方案就可以在使用RocketMQ时保证消息零丢失，但是性能和吞吐量也将大幅下降
使用事务机制传输消息，会比普通的消息传输多出很多步骤，耗费性能同步刷盘相比异步刷盘，一个是存储在磁盘中，一个存储在内存中，速度完全不是一个数量级主从架构的话，需要Leader将数据同步给Follower消费时无法异步消费，只能等待消费完成再通知RocketMQ消费完成
消息零丢失是一把双刃剑，要想用好，还是要视具体的业务场景而定，选择合适的方案才是最好的
RocketMQ分布式事务原理
分布式事务常见的方案有TCC（Try-Confirm-Cancel），XA两阶段提交方案，可靠消息最终一致性方案，最大努力通知方案等等。其中可靠消息最终一致性方案主要就可以依靠RocketMQ来做，因为RocketMQ支持消息事务。先上一张图：
RocketMQ 事务消息的实现步骤如下：
- Producer发送half message给RocketMQ
- RocketMQ返回half message success（half message发送成功之后RocketMQ的消费者并不能消费这条消息，因为消息存储在Topic为 RMQ_SYS_TRANS_HALF_TOPIC 的消息消费队列中，而不是原先的Topic）
- 执行核心交易链路
- 返回执行交易链路的结果，如果失败则回滚
- 如果执行成功，则Producer返回一个COMMIT状态给RocketMQ
- 如果RocketMQ迟迟收不到Producer的返回结果，即这条消息的状态为UNKNOWN，则会回调服务接口，查询这条消息到底是commit还是rollback
- RocketMQ确认消息为commit，则Consumer可以消费到这条消息
- Consumer操作数据库，执行自己的事务
- Consumer成功消费之后返回一个ACK消息给RocketMQ，如果成功消费则显示消费成功，否则RocketMQ会重发消息给Consumer继续消费
RocketMQ 事务消息的实现原理基于两阶段提交和定时事务状态回查来决定消息最终是提交还是回滚，RocketMQ 先执行第一部分的事务，如果失败则回滚，如果成功则定时任务会去回查到事务执行成功，这个时候通知消费者执行第二阶段的事务，如果失败则不断重发消息给消费者消费，如果成功则整个流程走完，保证了事务的原子性。
总结
到此这篇关于RocketMQ消息丢失场景以及解决方法的文章就介绍到这了,更多相关RocketMQ消息丢失场景内容请搜索易盾网络以前的文章或继续浏览下面的相关文章希望大家以后多多支持易盾网络！