推送消息到MQ的过程会丢失消息吗？订单系统在接收到订单支付成功的通知之后，必然会去推送一条订单支付成功的消息到MQ，那么在这个过程中，会出现丢失消息的问题吗？ 答案是可能会丢失的，比如订单系统在推送消息到RocketMQ的过程中，是通过网络去进行传输的，但是这个时候恰巧可能网络发生了抖动，就导致这次网络通信失败了，于是这个消息必然就没有成功投递给MQ。 除此之外，比如MQ确实收到了消息，但是他的网络通信模块的代码出现了异常，可能是他内部的网络通信的bug，导致消息没处理成功；或者是你在写消息到MO的过程中，刚好遇到了某个Leader Broker自身故障，其他的Follower Broker正在尝试切换为Leader Broker，这个过程中也可能会有异常，类似的问题可能还有其他的。 所以首先我们在使用任何一个MQ的时候，无论是RocketMQ、还是RabbitMQ、或者是Kafka，都要明确一点，不一定你发送消息出去就一定会成功，有可能失败，此时你的代码里可能会抛出异常，也可能不会抛出异常，具体要看到底是什么原因导致的消息推送失败。 消息到达了MQ，MQ自己会导致消息丢失吗？即使我们的订单系统成功的把消息写入了MQ，此时我们就可以想当然的认为你写成功了，消息就一定不会丢失了吗？ 我们现在都明确了一点，就是你的消息写入MQ之后，其实MQ可能仅仅是把这个消息给写入到page cache里，也就是操作系统自己管理的一个缓冲区，这本质也是内存。 然后这个时候，加入要是出现了Broker机器的崩溃，大家思考一下，机器一旦宕机，是不是os cache内存中的数据就没了，消息也就丢失了。 就算消息进入磁盘了，真的就万无一失了吗？Broker把消息写入os cache之后，其实操作系统自己在一段不太确定的时间之后，他自己会把数据从内存刷入磁盘文件里去的。但是万一机器磁盘坏了，可能上面的消息也都丢失了。 即使消费者拿到了消息，就一定不会丢失了吗？现在我们假设消费者系统已经获取到了消息，然后消息此时就在他的内存里，正准备运行代码去做业务逻辑，默认情况下，MQ的消费者可能会自动提交已经消费的offset，那么如果此时你还没处理这个消息的情况下，MQ的消费者可能直接自动给你提交这个消息的offset到broker了，标识为已经成功处理了这个消息。恰巧这个时候，消费者突然重启了，或者宕机了，此时还在内存里的消息就丢失了。