整合 时，消费端在处理失败时，如果需要进行重试，可以有如下几种重试机制：
方法1（默认）：
当消费端在处理消息时抛出异常，那么默认会在当前线程的3次的Retry。该方法是默认的，可以通过修改配置文件，指定channel下的参数，例如：
其中：
- 如果等于1，就是不重试；
- 如果大于1，其值就是重试次数。
当消息重试超过最大次数，如果未配置启用 ，消息将会被丢弃。该方法默认是无法设置重试的时间间隔的。
方法2：
方法1是在当前线程进行重试，相当于阻塞了后面的消息，有时我们不想阻塞，则可以利用死信队列（Dead Letter Queue， 缩写 ），进行异步重试。
先看一下 的逻辑。
设置 参数为true，将自动创建对应channel的 ，绑定死信交换机（Dead Letter Exchange， 缩写 ）。默认该的名字就是其对应. 后追加 ，同时，该进入该 的消息的 即为原 。
按上面的配置，消息进入 以后，因为没有任何的消费者，消息会一直存储于 中，可以添加 参数设置消息在中生存的时间，在无消费者的情况下，默认到期后会删除该消息。
如果想指定的名称，可以用 参数指定。
重试的逻辑其实就是利用 ，给其设置一个默认的 ，在 时间到期后，消息会再度转到指定的 对应的 中。
为了实现该逻辑，需要配置三个参数：
- 设置为true，启用
- 设置一个死信消息超时时间，变相实现了重试的间隔时间
- 增加该参数后，留空即为设置默认值。在默认值情况下， 中的消息将会按照其的值（也可由参数指定），将消息投递到给名称对应该值的 ，实现消息的重新消费。
例如：
注意：
因为在配置中，设置了 这个参数，当该参数使用时，默认rabbit的 参数是启用的，即该channel的 和 是持久化的，应用退出后，不会自动清除，并且保存创建时的参数。所以当改变了channel的参数后，需要将queue删除，让其自动重建，否则新改的不会生效，则无法实现自动重试。
按照上面配置，删除旧 后重新启动应用，创建 信息如下：
消息重新投递后，在其 里，会增加一些重试的信息，如下图所示：
- 值代表在当前线程的重试次数，即方法一的重试逻辑
- 头记录了重试循环的一些详细信息，尤其是值 记录了经由 异步重试的次数。
但有时，我们想知道上一次错误的具体异常，此时可以增加 参数，当设置为true时，会在消息头里增加详细的异常和异常堆栈信息。
注：
当 设置为不同值时， 的取值逻辑不同。当为false时，取的是 头中第一个的 值；当为true时，取得是 这个Header的值。
此时，该消息将不断重复queue -> DLQ -> queue的循环（假设消费端一直拒绝或抛异常）。如果我们想设置重试次数大于3就不再重试，可以抛出 这个异常，则该消息被丢弃，不再进入。
关于消息的拒绝
前面对于消息的拒绝，都是采用抛异常，但是这个异常不能乱抛。不同的异常，框架处理的方式不同：
- 普通的异常，等同于 ，会导致消息重试
- 这个异常，会导致消息被丢弃不触发重试
有时候，我们不期望在生产的日志中出现重试的ERROR，可以考虑用下面的方案：
- 将消费端的 从默认的自动改为手动，即
- 将channel注入到消费端，手动处理，例如：
版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/rfx/23651.html