RocketMQ消费者消费的时间,宕机了,消息会丢失吗?

一个消息从生产者产生，到被消费者消费，主要经过这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）来跟踪已消费消息的进度。如果消费者在消费中宕机，下一次启动时可以从上次成功消费的位置继续消费。
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。