[MQ]怎么检测消息是否丢失

1.检测消息丢失的方法

• 利用消息的有序行检验是否消息丢失(生产者给发出的消息加入连续递增的序号，在consumer来检查这个序号的连续性)
• 大多数消息队列的客户端都支持拦截器机制，你可以利用这个拦截器机制，在 Producer 发送消息之前的拦截器中将序号注入到消息中，在 Consumer 收到消息的拦截器中检测序号的连续性，这样实现的好处是消息检测的代码不会侵入到你的业务代码中，待你的系统稳定后，也方便将这部分检测的逻辑关闭或者删除。(使用拦截器机制，好处是可以定义到切面吗？？)

如果是分布式系统呢？

像 Kafka 和 RocketMQ 这样的消息队列，它是不保证在 Topic 上的严格顺序的，只能保证分区上的消息是有序的，所以我们在发消息的时候必须要指定分区，并且，在每个分区单独检测消息序号的连续性。

如果你的系统中 Producer 是多实例的，由于并不好协调多个 Producer 之间的发送顺序，所以也需要每个 Producer 分别生成各自的消息序号，并且需要附加上 Producer 的标识，在 Consumer 端按照每个 Producer 分别来检测序号的连续性。Consumer 实例的数量最好和分区数量一致，做到 Consumer 和分区一一对应，这样会比较方便地在 Consumer 内检测消息序号的连续性。

2. 消息的生产和消费的阶段

生产：生产者生产出来之后通过网络协议发送到Broker

存储：消息在broker端存储，如果是集群，那么消息会被复制到其他的副本中。

消费：消费者从broker pull数据，然后通过网络传输发送到consumer上。

生产阶段？

在生产阶段，你需要捕获消息发送的错误，并重发消息。

如何保证存储阶段消息可靠性？

如果在存储阶段，如果对消息的可靠性要求很高，可以通过配置broker的参数来避免挂了丢失消息。

对于单个节点的 Broker，需要配置 Broker 参数，在收到消息后，先写入磁盘再发送给生产者返回确认相应。

例如，在 RocketMQ 中，需要将刷盘方式 flushDiskType 配置为 SYNC_FLUSH 同步刷盘。

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

消费如何保证消息的可靠性？

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

消费部分代码注意的点就是：不能够在收到消息之后就立刻发送确认 而是执行了所有的消费业务逻辑之后 才能确认。

3. 消费的幂等性是什么？

消费者对接口的多次调用所产生的结果和调用一次是是一致的，也就是说在kafka中有可能会消费到重复的数据，这个时候需要客户端去处理这种情况，使得消息消费一次和消费多次是一样的结果。