当前位置: 首页 > 知识库问答 >
问题:

在RabbitMQ中处理死信

丌官晔
2023-03-14

TL;DR:一旦我修复了最初导致消息被拒绝的消费者代码,我需要将死信消息“重放”回其原始队列中。

我已经为RabbitMQ配置了死信交换(DLX),并成功地将拒绝的消息路由到死信队列。但现在我想查看死信队列中的消息,并尝试决定如何处理每个消息。一些(许多?)一旦有问题的消费者代码被修复,这些消息中的所有消息都应该重放(重新排队)到它们的原始队列(在“x-death”标题中可用)。但我该怎么做呢?我是否应该编写一个一次性程序,从死信队列中读取消息,并允许我指定要将消息发送到的目标队列?那搜索死信队列呢?如果我知道一条消息(比如用JSON编码的消息)具有我想要搜索和回放的特定属性,该怎么办?例如,我修复了一个缺陷,我知道该缺陷将允许PacketId为1234的消息立即成功处理。我想我也可以为此编写一个一次性程序。

我肯定不是第一个遇到这些问题的人,我想知道是否还有人已经解决了这些问题。似乎应该有某种瑞士军刀来解决这种事情。我在谷歌和Stack Overflow上进行了相当广泛的搜索,但并没有真正找到太多。我能找到的最接近的东西是铲子,但这似乎并不是真正适合这项工作的工具。

共有1个答案

夹谷英杰
2023-03-14

我是否应该编写一个一次性程序,从死信队列中读取消息,并允许我指定要将它们发送到的目标队列?

总的来说,是的。

您可以使用延迟消息交换插件的组合,设置延迟重试以将消息重新发送回原始队列。

但这只会在一个时间间隔内自动执行重试,并且在重试发生之前您可能尚未解决问题。

在某些情况下,这是可以的——比如当错误是由外部资源暂时不可用引起的。

不过,就你的情况而言,我相信你关于创建一个处理死信的应用程序的想法是最好的办法,原因有几个:

  • 您需要搜索消息,这是不可能的RMQ
  • 这意味着您需要一个数据库来存储来自DLX/队列的消息

因为您正在从DLX/队列中提取消息,所以需要确保从消息中获取所有头信息,以便在时机成熟时可以重新发布到正确的队列。

我当然不是第一个遇到这些问题的人,我想知道是否有其他人已经解决了这些问题。

而你不是!

这个问题有许多解决方案,都归结为您提出的解决方案。

一些较大的“服务总线”实现内置了这种类型的功能。例如,我相信NServiceBus(或其SaaS版本)已经内置了这一功能——尽管我不是100%确定。

如果您想进一步了解这一点,请搜索术语“有毒消息”-这通常是用于这种情况的术语。通过快速搜索,我在谷歌上找到了一些东西,这可能会帮助你走上这条路:

    < Li > http://lists . rabbit MQ . com/piper mail/rabbit MQ-discuse/2013-January/025019 . html < Li > https://web . archive . org/web/20170809194056/http://tafa Kari . co . ke/2014/07/rabbit MQ-poison-messages/ < Li > https://web . archive . org/web/20170809170555/http://kjnilsson . github . io/blog/2014/01/30/spread-the-poison/

希望这有帮助!

 类似资料:
  • 我有以下兔子听者: 我需要将listener配置为在它处理一条消息后等待15分钟,然后再接收下一条消息。不需要在此方法中等待。我所需要的只是在处理完一条后不接收任何消息。可以通过来完成,但我不确定这是否是实现这一点的最佳方法。对于这种情况有没有rabbitmq的配置?

  • 我们已经实现了延迟消息处理,有2个队列和x-死信-交换/x-消息-ttl,在queue1中的消息超时后,它将转到queue2。 现在是否有可能设置RabbitMQ,以便如果在处理来自queue2的消息时,我们将其拒绝为“死信”,那么它将自动转到queue3?我担心的是queue2中的消息已经标记为“已死”,有没有办法区分那些因为被拒绝而死的消息,并自动只将那些放在队列3中?

  • 我有RabbitMQ的工作配置-使用TTL从等待(死信)的主队列中发送消息,并在到期时将其抛出: 对于应用程序中的Spring云流,我不能重复相同的方案。yml公司 我将非常感谢您在应用程序中提供的帮助和工作示例。yml公司

  • 我正在使用Spring AMQP与RabbitMQ一起工作。以下是我的配置: 正如您所看到的,prefetchCount是1000。 我想知道预取的消息是否在消费者中并行处理;也就是说,多个线程调用onMessage(消息消息)方法。或者消息是按顺序处理的;也就是说,一个线程迭代预取的消息,并以连续的方式调用每个消息的onMessage(消息消息消息)方法。 我应该注意到,处理的顺序对我来说并不重

  • 主要内容:1.死锁无知,2.死锁预防,3.避免死锁,4.死锁检测和恢复1.死锁无知 死锁无知是所有机制中使用最广泛的方法。 许多操作系统主要为最终用户使用。 在这种方法中,操作系统假定永远不会发生死锁。 它只是无视死锁。 这种方法最适合用户使用系统仅用于浏览和所有其他常规内容的单个最终用户系统。 正确性和性能之间总是有一个折衷。 Windows和Linux等操作系统主要关注性能。 但是,如果死锁发生的次数是100次,那么系统的性能就会一直下降,如果它始终使用死锁处理

  • 我有一个使用Spring Cloud Streams-RabbitMQ在微服务中交换消息的项目。对我的项目至关重要的一件事是,我不能丢失任何信息。 null 我是这些框架的新手,我希望你能帮助配置我的...