一、消息丢失

当消息产生的速度长时间远远大于消费的速度的时候，就会产生消息的堆积。

消息堆积的影响：

1.新消息可能无法进入MQ。 2.旧消息无法丢失。 3.等待消费的时间过长，超出业务的容忍范围。

产生堆积可能的因素：

1.生产者大量发布消息 2.消费者消费失败，没有ack自动应答。 3.消费者可能出现性能瓶颈。 4.消费服务挂掉。

解决思路：

1.排查消费者运行效率、性能问题。 2.消费者多线程处理。 3.增加更多的消费者。

处理过程：

新生产的消息转移到新的队列，增加新的服务器部署新的消费者来消费。 原来的消息队列的消息可以继续慢慢消费。

二、消息丢失

1.生产者环节丢失消息

问题场景：生产者在投递消息过程中，突遇断网可能丢失消息。 解决方案：生产者在消息投递环节开启消息确认机制（事物或者comfirm），发送失败时候重试。

2.队列中丢失消息

问题场景：队列服务宕机、重启，消息丢失。 解决方案：投递消息的时候，交换机、队列、消息都设置为持久化durable=true

3.消费者中丢失消息

问题场景：消费者启用了自动应答，消费者服务挂掉。 解决方案：通道设置每次只处理一条消息，关闭消费者自动应答，消费完成手动应答。

三、顺序消费

问题场景：多条不幂等消息如消息1、消息2、消息3，采用worker模式投递，由于worker模式的消费者是竞争者关系，拿到的消息顺序是有问题的。 解决方案：将消息1、消息2、消息3分别投递进不同队列，每个队列对应一个消费者

问题场景：消费者开启了多线程 解决方案：消息队列分配消息后，创建多个内存队列，每个线程消费者去消费内存队列里面的消息

四、重复消费

出现原因：消费者消息消息的时候，MQ没有收到消息的ack应答。

场景：
  • 1.消费者消费消息后没有ack。
  • 2.消费者在消费消息后，ack时网络异常。

解决方案

  1. 消费者消费后，记录通过缓存记录消息的消费标识，消息id如redis的setnx
  2. 如果消费成功且ack成功，则删除记录的消息标记。
  3. 如果ack失败，消息下次被消费消息时候，先去查询消息的消费标识，已经消费则直接ack，未消费则继续消费。