在使用消息队列时，可能会遇到以下三个问题：
一.消息丢失
产生的原因：消息发送出去，由于网络问题或系统异常没有抵达服务器；
解决办法：
- 做好容错方法（try-catch），发送消息可能会网络失败，失败后要有重试机 制，可记录到数据库，采用定期扫描重发的方式
- 做好日志记录：每个消息状态是否都被服务器收到都应该记录
- 做好定期重发：如果消息没有发送成功，定期去数据库扫描未成功的消息进 行重发
- 消息抵达Broker：Broker要将消息写入磁盘（持久化）才算成功。此时Broker尚 未持久化完成，宕机。
- publisher也必须加入确认回调机制，确认成功的消息，修改数据库消息状态。
- 自动ACK的状态下。消费者收到消息，但没来得及消息然后宕机
- 一定开启手动ACK，消费成功才移除，失败或者没来得及处理就noAck并重 新入队。
概括起来就是：1.做好消息确认机制，包括生产者和消费者两端(public,consumer【手动ack】)；2.每一个发送的消息都在数据库做好记录，定期将失败的消息再次发送一次。
附日志记录表建表SQL:
CREATE TABLE `mq_message` (`message_id` char(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL,`content` text CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL,`routing_key` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL,`class_type` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NULL DEFAULT NULL,`message_status` int(4) NULL DEFAULT 0 COMMENT '0-新建 1-已发送 2-错误抵达 3-已抵达',`create_time` datetime NULL DEFAULT NULL,`update_time` datetime NULL DEFAULT NULL,PRIMARY KEY (`message_id`) USING BTREE
) ENGINE = InnoDB CHARACTER SET = utf8mb4 COLLATE = utf8mb4_general_ci ROW_FORMAT = Dynamic;二.重复消费
产生的原因：
- 消息消费成功，事务已经提交，ack时，机器宕机。导致没有ack成功，Broker的消息 重新由unack变为ready，并发送给其他消费者；
- 消息消费失败，由于重试机制，自动又将消息发送出去；
- 成功消费，ack时宕机，消息由unack变为ready，Broker又重新发送。
解决办法：
- 消费者的业务消费接口应该设计为幂等性的。比如扣库存有 工作单的状态标志
- 使用防重表（redis/mysql），发送消息每一个都有业务的唯 一标识，处理过就不用处理
- rabbitMQ的每一个消息都有redelivered字段，可以获取是否 是被重新投递过来的，而不是第一次投递过来的。
幂等性通俗来说，就是消息在进行处理时，判断数据的状态，如果是已处理过的则不再进行处理。
三.消息积压
产生的原因：
- 消费者宕机积压；
- 消费者消费能力不足积压；
- 发送者发送流量太大。
解决办法：
- 上线更多的消费者，进行正常消费
- 上线专门的队列消费服务，将消息先批量取出来，记录数据库，离线慢慢处理。
)
