怎么做才能不丢消息?

现在主流的消息队列产品都提供了非常完善的消息可靠性保证机制,可以做到在消息传递的过程中,即使发生网络中断或者硬件故障,也能确保消息的可靠传递、不丢消息。

绝大部分丢消息的原因都是由于开发者不熟悉消息队列,没有正确使用和配置消息队列导致的。

检测消息丢失的方法

用消息队列最尴尬的情况不是丢消息,而是丢了消息还不知道。因此,我们需要设计一套机制来监控消息是否有丢失。

根据项目的成熟程度,一般有两种方式来检测:

  1. 如果项目基础设施比较完善,那么可以使用分布式链路追踪系统来追踪每一条消息。
  2. 如果项目初期,系统刚上线,那么可以利用消息队列的有序性来检测是否有消息丢失。

我们可以在Producer端发出的每一条消息附加一个连续递增的序号,然后在Consumer端检测这个序号的连续性。如果没有消息丢失,Consumer收到的消息的序号必然是连续递增的,如果检测到序号不连续,那么就是丢消息了,还可以通过缺失的序号来确定丢失的是哪一条消息。

针对这种检测方法,有3条建议:

  1. 像Kafka和RocketMQ这样的消息队列,它不保证消息在Topic上的严格顺序,只能保证消息在分区(队列)上是有序的,所以我们在发消息的时候必须要指定分区,并且每个分区单独检测消息序号的连续性。
  2. 如果系统中有多个Producer实例,并且不好协调多个Producer之间的发送顺序,那么也需要针对每个Producer分别生成各自的消息序号,并且需要附加上Producer标识,在Consumer端按照每个Producer分别来检测序号的连续性。
  3. Consumer实例的数量最好和分区数量一致,做到Consumer和分区一一对应,这样比较方便在Consumer内检测消息序号的连续性。

消息可靠传递

一条消息从生产到消费完成的过程,可以分为三个阶段:

  1. 生产阶段:消息在Producer创建出来,经过网络传输到Broker端。
  2. 存储阶段:消息在Broker端存储,如果是集群,消息还会被复制到其他副本上。
  3. 消费阶段:Consumer从Broker上拉取消息,经过网络传输到Consumer上。

消息生产阶段

在生产阶段,消息队列最常用的是请求-确认机制,来保证消息的可靠传递:当代码调用发消息方法时,消息队列的客户端会把消息发送到Broker,Broker收到消息后,会给客户端返回一个确认响应,表示消息已经收到了。

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

消息存储阶段

在存储阶段正常情况下,只要Broker在正常运行,就不会出现丢失消息的问题,但是如果Broker出现了故障,还是有可能会丢消息。

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

如果Broker是由多个节点组成的集群,那么需要将Broker集群配置成:至少将消息发送到2个以上的节点后,再给客户端回复发送确认响应。

消息消费阶段

消费阶段采用和生产阶段类似的请求-确认机制来保证消息的可靠传递,客户端从Broker拉取消息后,执行用户的消费业务逻辑,成功后,才会给Broker发送消费确认响应。

如果Borker没有收到消费确认响应,下次拉消息时还会返回同一条消息,确保消息不回在网络传输过程中丢失,也不会因为客户端在执行消费逻辑中出错导致丢失。

我们需要注意,不要在收到消息后就立即发送消费确认,而是应该在执行完所有消费业务逻辑之后,再发送消费确认。

    
出处:http://wing011203.cnblogs.com/
    
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。