如何保证消息可靠性？

蔚落 2023-01-19 04:59 22阅读 0赞

### 文章目录 ###

*  一、消息可靠性方案
 *  二、消息丢失
 *  三、消息重复
 *  四、消息积压

# 一、消息可靠性方案 #

**① 持久化**

*  `exchange`要持久化
 *  `queue`要持久化
 *  `message`要持久化

**② 生产方确认 Confirm**

**③ 消费方确认 Ack**

**④ Broker 高可用**

# 二、消息丢失 #

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

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

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

`publisher`也必须加入确认回调机制，确认成功的消息，修改数据库消息状态。参考：[RabbitMQ 4.1 消息的可靠投递][RabbitMQ 4.1]

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

一定要手动`ACK`，消费成功才移除，失败或者来得及处理就`noAck`并重新入队。参考：[RabbitMQ 4.2 Consumer Ack][RabbitMQ 4.1]

# 三、消息重复 #

消息导致重复的场景：

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

消息重复的解决方案：

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

CREATE TABLE `mq message`(
    `message_id`CHAR (32) NOT NULL,
    `content` TEXT,
    `to_exchane` VARCHAR (255) DEFAULT NULL,
    `routing_key` VARCHAR (255) DEFAULT NULL,
    `class_type` VARCHAR (255) DEFAULT NULL,
    `message_status`INT(1) DEFAULT 'O' COMMENT '0-新建1-已发送2-错误抵达3-已抵达',
    `create_time` DATETIME DEFAULT NULL,
    `update_time` DATETIME DEFAULT NULL,
    PRIMARY KEY ( `message id`)
    ENGINE=INNODB DEFAULT CHARSET=utf8mb4

# 四、消息积压 #

消息导致积压的场景：

*  消费者宕机积压
 *  消费者消费能力不足积压
 *  发送者发送流量太大

消息积压解决方案：

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

[RabbitMQ 4.1]: https://hucheng.blog.csdn.net/article/details/115874215