如何确保消息不会丢失

消息从生产到消费的过程，可以划分为三个阶段：

生产阶段：在这个阶段，从消息在Producer创建出来，经过网络传输发送到Broker端。

存储阶段：在这个阶段，消息在Broker端存储，如果是集群，消息会在这个阶段被复制到其他副本上。

消费阶段：在这个阶段，Consumer从Broker上拉取消息，经过网络传输发送到Consumer上。

1. 生产阶段

在生产阶段，消息队列通过最常用的请求确认机制，来保证消息的可靠传递：当你的代码调用发 消息方法时，消息队列的客户端会把消息发送到Broker，Broker收到消息后，会给客户端返回一 个确认响应，表明消息已经收到了。客户端收到响应后，完成了一次正常消息的发送。

只要Producer收到了Broker的确认响应，就可以保证消息在生产阶段不会丢失。有些消息队列在 长时间没收到发送确认响应后，会自动重试，如果重试再失败，就会以返回值或者异常的方式告 知用户。

2. 存储阶段

在存储阶段正常情况下，只要Broker在正常运行，就不会出现丢失消息的问题，但是如果Broker出现了故障，比如进程死掉了或者服务器宕机了，还是会丢失消息的。

如果对消息的可靠性要求非常高，可以通过配置Broker参数来避免因为宕机丢失消息。

对于单个节点的Broker，需要配置Broker参数，在收到消息后，将消息写入磁盘后再给Producer 返回确认响应，这样即使发生宕机，由于消息已经被写入磁盘，就不会丢失消息，恢复后还可以 继续消费。例如，在RocketMQ中，需要将刷盘方式flushDiskType配置为SYNC_FLUSH同步刷 盘。

如果是Broker是由多个节点组成的集群，需要将Broker集群配置成：至少将消息发送到2个以上 的节点，再给客户端回复发送确认响应。这样当某个Broker宕机时，其他的Broker可以替代宕机 的Broker，也不会发生消息丢失。

3. 消费阶段

消费阶段采用和生产阶段类似的确认机制来保证消息的可靠传递，客户端从Broker拉取消息后， 执行用户的消费业务逻辑，成功后，才会给Broker发送消费确认响应。如果Broker没有收到消费 确认响应，下次拉消息的时候还会返回同一条消息，确保消息不会在网络传输过程中丢失，也不 会因为客户端在执行消费逻辑中出错导致丢失。

在编写消费代码时需要注意的是，不要在收到消息后就立即发送消费确认，而是应该在执行完所有消费业务逻辑之后，再发送消费确认。