一个消息从生产者产生,到被消费者消费,主要经过这3个过程:
因此,本文将从以下这几个维度来回答:
-
生产者如何保证不丢消息
-
存储端如何保证不丢消息
-
消费者如何保证不丢消息
-
最后消费者消费的时候,宕机,消息会不会丢呢?
1. 生产者如何保证不丢消息
生产端如何保证不丢消息呢?那就是 确保生产的消息能到达存储端。
如果是RocketMQ消息中间件,Producer生产者提供了三种发送消息的方式,分别是:
-
同步发送
-
异步发送
-
单向发送
生产者要想发消息时保证消息不丢失,可以:
-
采用同步方式发送,send消息方法返回成功状态,就表示消息正常到达了存储端Broker。
-
如果send消息异常或者返回非成功状态,可以重试。
-
可以使用事务消息,RocketMQ的事务消息机制就是为了保证零丢失来设计的
2. 存储端不丢消息
如何保证存储端的消息不丢失呢?确保消息持久化到磁盘, 这时候大家很容易想到就是刷盘机制。
刷盘机制分同步刷盘和异步刷盘:
-
生产者消息发过来时,只有持久化到磁盘,RocketMQ的存储端Broker才返回一个成功的ACK响应,这就是同步刷盘。它保证消息不丢失,但是影响了性能。
-
异步刷盘的话,只要消息写入PageCache缓存,就返回一个成功的ACK响应。这样提高了MQ的性能,但是如果这时候机器断电了,就会丢失消息。
Broker一般是集群部署 的,有master
主节点和slave
从节点。消息到Broker
存储端,只有主节点和从节点都写入成功,才反馈成功的ack
给生产者。这就是同步复制 ,它保证了消息不丢失,但是降低了系统的吞吐量。与之对应的就是异步复制,只要消息写入主节点成功,就返回成功的ack,它速度快,但是可能会导致消息丢失。
3.消费阶段不丢消息
我们先来聊聊RocketMQ的消费模式:
至少一次(At Least Once)
-
特点:消息会被至少消费一次,可能会重复消费。
-
应用场景:适用于对消息丢失敏感的场景,但可以容忍重复消费。
至多一次(At Most Once):
-
特点:消息最多被消费一次,可能会丢失,但不会重复。
-
应用场景:适合对丢失消息不敏感的场景,通常用于实时性要求高的情况。
恰好一次(Exactly Once):
-
特点 :确保每条消息只被处理一次,既不丢失也不重复。
-
应用场景:适用于需要严格消息处理的场景,通常需要结合事务和幂等性机制。
再然后呢,我们再聊聊消费进度管理.RocketMQ 通过消费位点(offset)来跟踪已消费消息的进度。消费者执行完业务逻辑,再反馈会Broker说消费成功,这样来保证消费阶段不丢消息。
如果消费者在消费中宕机,下一次启动时可以从上次成功消费的位置继续消费。
4. 消费者消费的时候,宕机,消息会不会丢呢?
前面三节,其实我们已经回答了这个问题.
-
如果我们设置了的消费模式是,至多一次 ,那宕机的时候,消息可能会丢掉.
-
如果我们设置的消费模式是至少一次或者恰好一次,那消息不会丢失.
消息重试:RocketMQ 支持消息的重试机制。如果消费者在消费过程中宕机且没有确认消息,消息会在指定的重试时间内重新投递。消费者会在重试次数用尽后被标记为失败。
消息持久化:RocketMQ 将消息持久化到磁盘,这意味着即使消费者宕机,消息依然会存在,不会丢失。
RocketMQ 通过消费位点(offset)来跟踪已消费消息的进度。如果消费者在消费中宕机,下一次启动时可以从上次成功消费的位置继续消费。