✅P300_商城业务-订单服务-消息丢失-积压-重复等解决方案

如何保证消息可靠性-消息丢失

消息丢失

消息发送出去，由于网络问题没有抵达服务器

• 做好容错方法（try-catch），发送消息可能会网络失败，失败后要有重试机制，可记录到数据库，采用定期扫描重发的方式
• 做好日志记录，每个消息状态是否都被服务器收到都应该记录
• 做好定期重发，如果消息没有发送成功，定期去数据库扫描未成功的消息进行重发

消息抵达Broker，Broker要将消息写入磁盘（持久化）才算成功。此时Broker尚未持久化完成，宕机。

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

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

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

情况一：

消息发送出去但是由于网络原因未到达服务器，解决方案：采用try-catch将发送失败的消息持久化到数据库中，采用定期扫描重发的方式。

drop table if exists mq_message;
CREATE TABLE `mq_message` (
	`message_id` CHAR(32) NOT NULL,
	`content` TEXT,
	`to_exchange` VARCHAR(255) DEFAULT NULL,
	`routing_key` VARCHAR(255) DEFAULT NULL,
	`class_type` VARCHAR(255) DEFAULT NULL,
	`message_status` INT(1) DEFAULT '0' COMMENT '0-新建  1-已发送  2-错误抵达  3-已抵达',
	`create_time` DATETIME DEFAULT NULL,
	`update_time` DATETIME DEFAULT NULL,
	PRIMARY KEY (`message_id`)
) ENGINE=INNODB DEFAULT CHARSET=utf8mb4

情况二：

消息抵达服务器的队列中才算完成消息的持久化，解决方案publish的ack机制

情况三： 防止自动ack带来的缺陷，采用手动ack。

---

如何保证消息可靠性-消息重复

消息重复

消息消费成功，事务已经提交，ack时，机器宕机。导致没有ack成功，Broker的消息重新由unack变为ready，并发送给其他消费者

消息消费失败，由于重试机制，自动又将消息发送出去

成功消费，ack时宕机，消息由unack变为ready，Broker又重新发送

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

消息被成功消费，ack时宕机，消息由unack变成ready状态，Broker又重新发送。解决方案：将消费者的业务消费接口应该设计为幂等性的，比如扣库存有工作单的状态标志。

---

如何保证消息可靠性-消息积压

消息积压

消费者宕机积压；

消费者消费能力不足积压；

发送者发送流量太大：

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

消息积压即消费者的消费能力不够， 上线更多的消费者进行正常的消费。