Rabbitmq如何避免消息重复消费?
消息全局 ID 或者写个唯一标识(如时间戳、UUID 等) ：每次消费消息之前根据消息 id 去判断该消息是否已消费过，如果已经消费过，则不处理这条消息，否则正常消费消息，并且进行入库操作。(消息全局 ID 作为数据库表的主键，防止重复)
Rabbitmq怎么保证消息的顺序性
单个队列：将需要保持顺序的消息发送到同一个队列中，这样消息会被按照发送的顺序依次处理。消费者在处理消息时，确保按照接收到的顺序进行处理
消息排序字段：在消息中添加一个排序字段，消费者在处理消息时根据该字段进行排序，保证消息的顺序性
有序消息中间件：使用有序消息中间件，如 RocketMQ 等，这些中间件可以保证消息的顺序性
RabbitMQ消息丢失解决方案
RabbitMQ消息丢失的3种情况:
第一种：生产者弄丢了数据。生产者将数据发送到 RabbitMQ 的时候，可能数据就在半路给搞丢了，因为网络问题啥的，都有可能
第二种：RabbitMQ 弄丢了数据。MQ还没有持久化自己挂了
第三种：消费端弄丢了数据。刚消费到，还没处理，结果进程挂了，比如重启了
RabbitMQ消息丢失的解决方案:
1.针对生产者-使用confirm机制
事务机制和 confirm 机制最大的不同在于，事务机制是同步的，你提交一个事务之后会阻塞在那儿，但是 confirm 机制是异步的
在生产者开启了confirm模式之后，每次写的消息都会分配一个唯一的id，然后如果写入了rabbitmq之中，rabbitmq会给你回传一个ack消息，告诉你这个消息发送OK了；如果rabbitmq没能处理这个消息，会回调你一个nack接口，告诉你这个消息失败了，你可以进行重试。而且你可以结合这个机制知道自己在内存里维护每个消息的id，如果超过一定时间还没接收到这个消息的回调，那么你可以进行重发
2.针对RabbitMQ-rabbitMQ的持久化机制
要保证rabbitMQ不丢失消息，那么就需要开启rabbitMQ的持久化机制，即把消息持久化到硬盘上，这样即使rabbitMQ挂掉在重启后仍然可以从硬盘读取消息
消息补偿机制
为什么还要消息补偿机制呢？难道消息还会丢失，没错，系统是在一个复杂的环境，不要想的太简单了，虽然以上的三种方案，基本可以保证消息的高可用不丢失的问题。
但是作为有追求的程序员来讲，要绝对保证我的系统的稳定性，有一种危机意识。
比如：持久化的消息，保存到硬盘过程中，当前队列节点挂了，存储节点硬盘又坏了，消息丢了，怎么办？
1）生产端首先将业务数据以及消息数据入库，需要在同一个事务中，消息数据入库失败，则整体回滚。
2）根据消息表中消息状态，失败则进行消息补偿措施，重新发送消息处理。
3.针对消费者-ACK确认机制
多个消费者同时收取消息，比如消息接收到一半的时候，一个消费者死掉了(逻辑复杂时间太长，超时了或者消费被停机或者网络断开链接)，如何保证消息不丢？
使用rabbitmq提供的ack机制，这样就解决了，即使一个消费者出了问题，但不会同步消息给服务端，会有其他的消费端去消费，保证了消息不丢的场景