发送方确认机制：
信道需要设置为 confirm 模式，则所有在信道上发布的消息都会
分配⼀个唯⼀ ID
。⼀旦消息被投递到
queue
（可持久化的消息需要写⼊磁盘），信道会发送⼀个确认给⽣产者（包含消息唯⼀ ID）。
如果
RabbitMQ 发⽣内部错误从⽽导致消息丢失
，会发送⼀条 nack（未确认）消息给⽣产者。所有被发送的消息都将被
confirm（即 ack） 或者被nack⼀次
。但是没有对消息被 confirm 的快慢做任何保证，
并且同⼀条消息不会既被 confirm⼜被nack 发送⽅确认模式是异步的
，⽣产者应⽤程序在等待确认的同时，可以继续发送消息。当确认消息到达⽣产者，⽣产者的回调⽅法会被触发。
ConfirmCallback接⼝：
只确认是否正确到达 Exchange 中，成功到达则回调
ReturnCallback接⼝：
消息失败返回时回调
接收方确认机制：
消费者在声明队列时，可以指定
noAck
参数，当noAck=false时，RabbitMQ会等待消费者显式发回ack信号后才从内存(或者磁盘，持久化消息)中移去消息。否则，消息被消费后会被⽴即删除。
消费者接收每⼀条消息后都必须进⾏确认（消息接收和消息确认是两个不同操作）。只有消费者确认了消息，RabbitMQ 才能安全地把消息从队列中删除。
RabbitMQ不会为未ack的消息设置超时时间，它判断此消息是否需要重新投递给消费者的唯⼀依据是消费该消息的消费者连接是否已经断开。这么设计的原因是RabbitMQ允许消费者消费⼀条消息的时间可以很⻓。保证数据的最终⼀致性；
如果消费者返回ack之前断开了链接，RabbitMQ 会重新分发给下⼀个订阅的消费者。（可能存在消息重复消费的隐患，需要去重）
![[附源码]计算机毕业设计JAVA小超市进销存管理系统](https://img-blog.csdnimg.cn/aa29b8e1bd3044b1ba62320d4533be9c.png)
![[MAUI] 开篇-初识MAUI](https://img-blog.csdnimg.cn/339276249a30429fa909b447ccf5e3d7.png)
