MQ消息丢失处理方案

MQ定义：在分布式系统中，消息中间件（如 RabbitMQ、RocketMQ、Kafka、Pulsar 等）扮演着关键角色，用于解耦生产者和消费者，并确保数据传输的可靠性和顺序性。

如何预防/避免MQ消息丢失：消息持久化、手动确认机制和重试机制等

针对MQ消息已经丢失的处理方案：

1. 生产者发送消息失败
   场景： 生产者在发送消息到消息中间件时失败，消息没有成功进入队列
   解决方案：

消息重发: 生产者实现重试，在发送消息失败时进行多次重试，确保消息最终能被成功发送出去

本地存储: 在发送消息失败时，将消息保存到本地存储（如数据库或文件），稍后再尝试发送，确保消息不会丢失

日志记录: 记录发送失败的日志信息，方便后续排查和处理

2. 消息在传输过程中丢失
   场景： 消息在从生产者到消息中间件，或者从消息中间件到消费者的传输过程中丢失
   解决方案：

消息重发： 生产者实现重试，在发送消息失败时进行多次重试，确保消息最终能被成功发送出去

3. 消息中间件内部丢失
   场景： 消息中间件由于内部故障（如节点崩溃、磁盘故障等）导致消息丢失
   解决方案：

高可用配置: 一般来说消息中间件都会配置集群，当然集群的方案可能会不同，但如果是配置了高可用集群，此时是主节点挂了可以通过多节点冗余和数据复制来提高系统的容错能力。在某个节点发生故障时，可以从其他节点恢复数据

备份与恢复： 定期备份消息和队列状态，当发生硬件故障时，可以从备份中恢复数据

日志记录: 日志记录系统操作和状态变化，通过重放日志可以在节点故障后恢复数据

4. 消费者未处理完消息前丢失
   场景： 消费者收到消息后，在处理消息的过程中发生异常，导致消息丢失
   解决方案：

消息重发（针对于业务简单的情况）： 由生产者实现消息重发，也就是再次发起业务。当然这种方式得生产者进行配合，有时比较深的业务链某个环节出现丢失，要重新发送的代价也会比较高

未确认消息重发: 如果是消费者在处理消息时不会自动ACK或未发送ACK给消息中间件情形，此时消息中间件会将未确认的消息重新放回队列，重新投递给其他消费者或同一个消费者进行处理

死信队列： 若是消息处理失败超过一定次数或消息在队列中停留超过一定时间时，此时消息转移到死信队列。消费者可以从死信队列中找回消息