消息队列在微服务场景中的可靠性模式原理梳理

场景一：主业务服务发送消息时可能因为消息队列无法使用而失败

1. 主业务服务将要发送的消息持久化到本地数据库中，标记状态为“待发送”，然后把消息发送给消息队列
2. 消息队列接收到消息后，把消息持久化到自己的存储服务中，这时不是立即发送消息到子服务，而是立即向主服务（生产者）返回消息队列的结果
3. 主服务接收到消息的返回结果，判断是否成功，失败则结束后续业务处理，设置本地持久化记录状态为“结束”，否则执行后续的业务处理，设置本地持久化消息状态为“已发送”

场景二：消息队列发送消息后，从服务（消费者）宕机导致无法消费

采用消息队列的ACK机制：消息确认机制

默认情况下，消息队列采用自动应答，发送消息后立即从消息队列中删除该消息。所以，为了确保消息可靠，采用手动ACK方式保证消息可靠性

如果从业务因为宕机没有发送ACK，则消息队列会将消息重新发送。

如果从业务处理完相关业务后，ACK 通知消息队列，就会从消息队列中删除该持久化消息。

场景三：消息队列一直重试失败而无法投递，就会出现消息丢弃的情况

从业务消费成功后，会向消息队列发送一个通知消息，此时它是一个生产者。

主服务收到消息后，最终把本地持久化的消息状态改为“已完成”。

补偿机制：利用定时任务从数据库扫描一定时间内未完成的消息并重新投递

定时任务：单机：Quartz 分布式：Elastic-Job,XXL-JOB,ScheduleX等分布式定时任务中间件

场景四：从业务服务可能受到消息处理超时或服务宕机

可通过上述，可靠事件模式确保事件传递至少一次。

业务服务（消费者）保证幂等性。