一、消息可靠性方案
① 持久化
exchange
要持久化queue
要持久化message
要持久化
② 生产方确认 Confirm
③ 消费方确认 Ack
④ Broker 高可用
二、消息丢失
① 消息发送出去,由于网络问题没有抵达服务器
- 做好容错方法(
try-catch
),发送消息可能会网络失败,失败后要有重试机制,可记录到数据库,采用定期扫描重发的方式; - 做好日志记录,每个消息状态是否被服务器收到都应该记录;
- 做好定期重发,如果消息没有发送成功,定期去数据库扫描未成功的消息进行重发。
② 消息抵达Broker,Broker要将消息写入磁盘(磁盘化)才算成功。此时Broker尚未持久化完成,宕机。
publisher
也必须加入确认回调机制,确认成功的消息,修改数据库消息状态。参考:RabbitMQ 4.1 消息的可靠投递
③ 自动ACK的状态下,消费者收到消息,但没来得及处理消息然后宕机
一定要手动ACK
,消费成功才移除,失败或者来得及处理就noAck
并重新入队。参考:RabbitMQ 4.2 Consumer Ack
三、消息重复
消息导致重复的场景:
- 消息消费成功,事务已经提交,
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
四、消息积压
消息导致积压的场景:
- 消费者宕机积压
- 消费者消费能力不足积压
- 发送者发送流量太大
消息积压解决方案:
- 上线更多的消费者,进行正常消费
- 上线专门的队列消费服务,将消息先批量取出来,记录数据库,离线慢慢处理