怎样在消费端根据业务控制Ack，使生产端进行消息重发

Question

在消费端设置手动Ack

然后在消费端进行手动签收，Ack、NAck、Reject都试过

在生产端设置 Confirm监听与 Return 监听，其中，不管消费端是Ack、NAck、Reject，Confirm中 ack 都收到的true,Return监听则没有触发

生产端配置

想问的问题是，怎样在消费端根据业务控制Ack，使生产端进行消息重发

Answer 1

阿神 2018-08-20 00:05:27

nack是要配合死信队列的，或者要设置超时时间，reject表示拒绝消费

• 提问者 qq_哈之仆_0 #1

  非常感谢！

Answer 2

阿神 2018-08-20 18:59:21

如果进入死信队列的消息，消费失败就做人工补偿

• 提问者 qq_哈之仆_0 #1

  消费失败再回到死信队列，记录重试次数，超过一定次数就人工补偿，这样可以吗？

• 阿神 回复 提问者 qq_哈之仆_0 #2

  这个机制可以自己定

Answer 3

提问者 qq_哈之仆_0 2018-08-18 18:10:23

刚才进行了下测试，证实了，如果进行NAck，就会进入绑定的死信队列。

那么从逻辑上应该可以给死信队列设置一个过期时间，过期了导向下一个处理的队列A，然后A进行处理。

如果A处理又失败，又从A导给死信队列，继续循环，然后设置一个次数限制，这样就算是一个简单的重试机制了。

@讲师-阿神，不知道实际生产环境上是不是也是这么做的。

Answer 4

提问者 qq_哈之仆_0 2018-08-18 17:38:38

附加一下我的理解

通过课程学习，我认为 ConfirmListener 中的 ack 表示消息是否成功到达消息中间件，ReturnListener 监听消息在消息中间件中有没有找到对应的 Queue。

一开始猜测设置了手工签收的话，可以在业务端进行拒签，然后神铲断的 ConfirmListener 中 ack 会为false，然后生产端可以选择重新发消息。

但是经过实践发现好像不行，那是不是进行 NAck 或者 Reject，消息会进入对应的死信队列???

• 阿神 #1

  如果走死信队列失败后，那么走人工补偿