RocketMQ的消息可靠性（防止消息丢失）

详细介绍了RocketMQ消息丢失的问题，以及解决办法。

消息的丢失问题，可能出现在生产者、MQ、消费者中。

1 生产者消息丢失

RocketMQ 提供了三种方式发送消息：同步、异步和单向。

同步发送：同步发送指消息发送方调用发出数据接口后会阻塞直到在收到接收方发回响应之后才进行后续的步骤，比如发送下一条消息。一般用于重要通知消息，例如重要通知邮件、营销短信。

异步发送：异步发送指发送方调用发出数据接口后，不等接收方发回响应，接着进行后续的步骤，比如发送下一条消息，一般用于可能链路耗时较长而对响应时间敏感的业务场景，例如用户视频上传后通知启动转码服务。

单向发送：单向发送是指只负责发送消息而不等待服务器回应且没有回调函数触发，适用于某些耗时非常短但对可靠性要求并不高的场景，例如日志收集。

想要生产者消息不丢失，那么只需要在生产者每发送一个消息时，Broker同步返回一个消息发送成功SEND_OK的反馈消息即可，如果发生异常，比如反馈失败或者超时则重试，重试还是不成功的话就先入库，后续再人工处理。注意即使返回SEND_OK也不一定意味着它是可靠的，还应启用同步Master服务器或同步刷盘，即SYNC_MASTER或SYNC_FLUSH，但至少表示Producer端是没问题的。

另一个方法就是使用RocketMQ自带的事务机制来发送消息，即事务消息，这样还能保证生产者事务和消息发送同时成功，但会事务消息更加重量级，还会降低吞吐量。

2 MQ消息丢失

RocketMQ支持消息的高可靠存储，Broker端影响消息可靠性的几种情况：

1. Broker非正常关闭
2. Broker异常Crash
3. OS Crash
4. 机器掉电，但是能立即恢复供电情况
5. 机器无法开机（可能是cpu、主板、内存等关键设备损坏）
6. 磁盘设备损坏

1)、2)、3)、4) 四种情况都属于硬件资源可立即恢复情况，RocketMQ在这四种情况下能保证消息不丢，或者丢失少量数据（依赖刷盘方式是同步还是异步）。

5)、6)属于单点故障，且无法恢复，一旦发生，在此单点上的消息全部丢失。RocketMQ在这两种情况下，通过配置Broker主从可以解决。通过主从异步复制，可保证99%的消息不丢，但是仍然会有极少量的消息可能丢失。通过主从同步双写技术可以完全避免单点，同步双写势必会影响性能，适合对消息可靠性要求极高的场合，例如与Money相关的应用。注：RocketMQ从3.0版本开始支持同步双写。

3 消费者消息丢失

如果消费者拿到了消息还没有开始消费就自动向broker提交了此消息的offset，这会导致mq认为这条消息已经处理过了。此时如果消费者突然宕机了，然而实际并没有处理，重启之后获取的消息中不会包含已提交消息，所以这条消息就丢失掉了。

对于Kafka和RabbitMQ来讲，默认的消费模式就是上边这种自动提交的模式，所以是有可能导致消息丢失掉的，所以其实Consumer的消息丢失解决方案也很简单，就是将自动提交改为手动提交。

而RocketMQ的消费者有点不一样，它本身就是需要手动返回消息处理成功的ack的，对于并行消费需要手动返回ConsumeConcurrentlyStatus.CONSUME_SUCCESS，对于串行消费需要返回ConsumeOrderlyStatus.SUCCESS，因此不需要额外的配置。

另外，如果采用广播模式消费，则需要在客户端维护offset，需要持久化。

相关文章：

RocketMQ

如有需要交流，或者文章有误，请直接留言。另外希望点赞、收藏、关注，我将不间断更新各种Java学习博客！