1.如何处理消息丢失

场景1：消息发送出去，由于网络问题没有抵达MQ

解决方法：

  • 1).做好容错方法（try-catch），发送消息可能会网络失败，失败后要有重试机制，可记录到数据库，采用定期扫描重发的方式

  • 2).做好日志记录，每个消息状态是否都被服务器收到都应该记录，可以创建一张关于消息的数据表，存到数据库里 

    1. CREATE TABLE `mq_message` (
    2. `message_id` char(32) NOT NULL,
    3. `content` text,
    4. `to_exchane` varchar(255) DEFAULT NULL,
    5. `routing_key` varchar(255) DEFAULT NULL,
    6. `class_type` varchar(255) DEFAULT NULL,
    7. `message_status` int(1) DEFAULT '0' COMMENT '0-新建 1-已发送 2-错误抵达 3-已抵达',
    8. `create_time` datetime DEFAULT NULL,
    9. `update_time` datetime DEFAULT NULL,
    10. PRIMARY KEY (`message_id`)
    11. ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4

  • 3).做好定期重发，如果消息没有发送成功，定期去数据库扫描未成功的消息进行重发

场景2：消息抵达Broker之后，Broker要将消息写入磁盘（持久化）时宕机。

publisher必须加入确认回调机制，确认成功的消息，修改数据库消息状态。

场景3：自动ACK的状态下。消费者收到消息，但没来得及消息然后宕机

一定开启手动ACK，消费成功再移除，失败或者没来得及处理就noAck并重新入队

解决方法总结：

1：做好消息确认机制（生产者、消费者【开启手动ACK】）
2：每一个消息都需要在数据库中做好记录，定期将失败的消息重新发送。

2.如何解决消息重复

场景：

  • 1.消息消费成功，事务已经提交，ack时，机器宕机。导致没有ack成功，Broker的消息 重新由unack变为ready，并发送给其他消费
  • 2.消息消费失败，由于重试机制，自动又将消息发送出去
  • 3.成功消费，ack时宕机，消息由unack变为ready，Broker又重新发送

解决方法：消费者的业务接口设计成幂等性

  1. 消费者的业务消费接口应该设计为幂等性的。比如扣库存有工作单的状态
  2. 使用防重表（redis/mysql），发送消息每一个都有业务的唯一标识，处理过就不用处理
  3. rabbitMQ的每一个消息都有redelivered字段，可以获取是否是被重新投递过来的，而不是第一次投递过来的

3.如何解决消息积压

场景：

  • 消费者宕机积压
  • 消费者消费能力不足积压

  • 发送者发送流量太大

    解决：

  • 上线更多的消费者，进行正常消费

  • 上线专门的队列消费服务，将消息先批量取出来，记录数据库，离线慢慢处理