是否有一个企业消息队列可以删除重复消息(保留第一个值)?

发布于 2024-12-21 18:27:41 字数 316 浏览 1 评论 0原文

我正在寻找具有这些要求的消息队列。找不到它;也许最接近的是rabbitmq-lvc插件(但我需要行中的第一个值坚持并保持在前面)。 有人知道支持这些的技术吗?

  • 消息队列是 FIFO 的,
  • 如果正在排队重复的消息,则消息队列本身会拒绝或丢弃它。

例如,生产者按以下顺序将这三个消息(每个消息都有一个鉴别器值)放入队列中:M1(鉴别器= 7654),M2(鉴别器= 2435),M3(鉴别器= 7654)。 现在我希望消息队列看到 M3 具有与 M1 相同的鉴别器值,从而丢弃/拒绝 M3。消费者仅收到:M1、M2。

谢谢 汤姆

I am looking looking for a message queue with these requirements. Couldn't find it; maybe the closest was the rabbitmq-lvc plugin (but I need the first value in the line to stick and stay in front).
Would anyone know a technology to support these?

  • message queue is FIFO
  • if a duplicate message is being enqueued, the message queue itself either rejects or drops it.

For example, producers put these three messages (each with a discriminator value) into the queue in this sequence: M1(discriminator=7654), M2(discriminator=2435), M3(discriminator=7654).
Now I want the message queue to see that M3 has the same discriminator value as M1 and thus drop/reject M3. Consumers receive only: M1, M2.

Thanks
Tom

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

再见回来 2024-12-28 18:27:41

我不知道其他传输,但我知道 WebSphere MQ 不会执行此操作,并且我相信其原因的解释将广泛适用于整个类别。我会非常惊讶地发现任何消息传送实际上都提供了这一点。以下是一些原因:

  • 异步消息应该是原子的。不同的供应商对消息关联性(两个或多个消息之间的关系)做出了自己的调整,但通常应避免消息关联性。您的用例不仅需要传输来处理消息关联性,而且需要在相关消息之间的不确定间隔内执行此操作。
  • 消息有效负载是一个 blob。出于性能原因,WMQ 不会触及消息有效负载,除了压缩或代码页转换等操作。任何需要解析消息负载的事情都是 WebSphere Message Broker、DataPower 或 WebSphere ESB 的工作。我预计任何声称高性能的消息传输都会面临类似的问题,因为解析有效负载会导致更长的代码路径和非线性性能下降。消息属性是个例外,但 WMQ 仅将这些属性用于选择,我预计情况通常如此。
  • 无状态操作。作为传输,应用程序的状态可以存储在持久消息中,但传输层的状态不应依赖于跨不同工作单元的应用程序的状态。同样,当您想要将某些应用程序状态的管理委托给消息传递层时,特别是当此类管理跨越许多工作单元时,ESB 类型的产品是最适合的。
  • 保证交货。 WMQ 旨在永远不会丢失您的持久消息。如果应用明确设置过期时间,消息可能会消失,因为发件人表示可以这样做。如果消息是非持久性的,它可能会消失,但只有在特殊情况下才会消失,并且因为发送者表示可以这样做。您描述的用例可能会导致消息消失,不是因为发件人说可以,甚至不是因为收件人说可以,而是因为与一些不相关的第 3 方进行交互,而这些第三方碰巧用重复值。如果第一条消息存在无效标头或代码页问题并被回滚怎么办?如果我作为攻击者输出带有所有可能的 4 位鉴别器值的垃圾消息怎么办?

正如我所说,我不了解其他消息传递产品,因此可能有一些东西可以满足您的要求,如果是这样,我将有兴趣阅读它。然而,如果没有人回复,这篇文章可能会揭示一些原因。

I don't know the other transports but I know that WebSphere MQ doesn't do this and I believe that the explanation why would apply broadly across the category. I'd be very surprised to find that any messaging transport actually provides this. Here are a few reasons why:

  • Async messages are supposed to be atomic. Different vendors make their own accommodations for message affinity (a relationship between two or more messages) but as a rule, message affinity is to be avoided. Your use case not only requires the transport to deal with message affinity, but to do so over an indeterminate interval between related messages.
  • Message payload is a blob. For performance reasons, WMQ doesn't touch message payloads except for things like compression or code page conversion. Anything that requires parsing the message payload is a job for WebSphere Message Broker, DataPower or WebSphere ESB. I would expect any messaging transport which claims to be performant would face similar issues because parsing payloads results in longer code paths and non-linear performance degradation. The exception is message properties but WMQ uses these for selection only and I expect that is generally the case.
  • Stateless operation. As a transport, the state of the application may be stored in a persistent message but the state of the transport layer should not depend on the state of the application across different units of work. Again, an ESB type of product is best suited when you want to delegate management of some of the application state to the messaging layer and especially when such management spans many units of work.
  • Assured delivery. WMQ was designed to never lose your persistent message. If the app explicitly sets expiry the message might go away because the sender said it was OK to do so. If the message is non-persistent it might go away, but only in an exceptional condition and, again, because the sender said it was OK to do so. The use case you describe might result in a message going away not because the sender said it was OK, or even because the recipient said it was OK but because of an interaction with some unrelated 3rd party who happened to beat you to the queue with a duplicate value. What if that first message has an invalid header or code page problem and gets rolled back? What if I as an attacker spew out garbage messages with all possible 4-digit values for discriminator?

As I said, I don't know the other messaging products so there may be something out there which meets your requirement and if so I'll be interested to read about it. However in the event hat nobody replies, this post may shed some light on the reasons why.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文