ConfirmCallBack 回调只能保证消息已经到达服务器，但不能保证消息一定会被投递到目标 Queue 里。

我觉得您提出的“消费出现异常”，和消息投递的可靠性是两个东西。这里的重试机制也仅仅是消息无法投递到MQ做出的补偿。?

延长定时时间？

拿订单业务来说，消费端就是消息请求出队后做一些业务操作，写订单或者记录日志，包括一些更新操作。消息中间件的作用可以说是降低了服务端的压力，不管你是多少并发，都得按照程序设计依次进行处理。

高并发的时候就体现出来了

@EnableScheduling去掉

同问，运行一次就停止了，也加了spring-boot-starter-web依赖

这位同学是不是没有设置spring.rabbitmq.publisher-confirms=true

同 问

@Input(StreamClient.input)和@Output(StreamClient.input)通道名不能一样

你消费端手工ACK的时候，有两个参数，第二个参数你设置成了false，那么生产端接受到的ACK就是false

改exchange的名称不是网络闪断，而是让消息找不到对应的exchange。消息找不到对应的交换机，从而消息发送失败。讲师只是通过这种方式来模拟消息发送失败的场景

这个地址可以看到 点我

我们的验证已经完善，谢谢提出宝贵意见。嗯嗯找到就开始coding把^-^...

如果消息正常投递，消息进入队列，这时候生产者的任务已经完成，数据库也会更新为投递成功。

消费者出现问题，如果设置了消息正常消费后发送ack响应，那么这个消息队列不会收到ack响应，所以不会从队列中移除。当消费者和broker断开连接，该消息会重新变为ready状态，等待新的消费者消费。

ack是rabbitmq返回的，跟消费端没关系。这些个消息中间件就是为了让生产者与消费者无直接联系。

消费端没有可靠性投递的说法。 如果消费没有成功 可以采用消息的重投处理（比如延迟队列）或者记录日志重发

https://download.csdn.net/download/jwq1220/10872749