双向消息队列-Java 学习之路

这似乎是一个属于常见问题解答的问题，但我无法用短语来回答这个问题 .
无论如何，我目前正在研究消息队列（通过ZeroMQ，RabbitMQ教程），我认为MQ非常适合转换数据流 - 在Q1上收听格式为F1的消息，转换为F2并将转换后的消息放在Q2上 . 如果转换本质上是双向的并且没有明确定义的消费者和生产环境者，例如，如果发生了什么，则会出现自然的问题 . yaml < - > json转换器？

据我所知，消息队列本质上是单向的，对于双向消息传递，我看到两个“解决方案”：

有两个不同的输入输出队列，在本例中转换为4：json.in，json.out，yaml.in，yaml.out;
将转换器连接到JSON队列的两端，以区分原始json和从yaml转换，在消息中包装消息，指定这是传入消息还是传出消息 . 但结果是，转换器现在得到了大量的消息，它必须解析并重新插入队列 - 听起来效率低得离谱 .

前一种解决方案听起来像是一种方法，除非后者以某种形式（例如，消费者/ 生产环境者ID： json.out, id = connect_produce("json", null); json.in = connect_consume("json", id); ）委托给MQ代理，而且如果消息是由同一实体生成的，则经纪人只是想出不向消费者发送消息 . 正如我所理解的那样，任何类型的过滤都将归结为消息标记（RabbitMQ中的主题交换），这需要多个队列 .

所以我的问题是这在实践中是如何完成的？坚持多个队列或某些框架实现双向队列？或者也许我错过了一些明显的东西？

2 回答

0

使用队列来翻译消息格式似乎有点矫枉过正 . 这本身听起来效率低下，所以如果你选择以这种方式进行消息翻译，那么你已经走错了路，可以选择你喜欢的任何选项，因为它们都很糟糕 .

在选择队列设计方面，与您使用它的方式无关，逻辑上双向队列与两个单向队列相同 . 只需使用您使用的队列实现中的任何一个 .

回复于 2024-04-25T08:03:03+08:00
0
相似的词，但意义不同 .

虽然许多软件使用像“queue”，“socket”，“MQ”这样的单词，但相同的拼写不能保证相同的含义 .

概念很重要 .

作为命名的两者之间的巨大差异，ZeroMQ是一个无经纪人 .

下一个重要问题是了解景观的全球 Map ，并涵盖相关技术的概念 .

为了你的转型动机问题，一个简单的答案是“没有普遍的魔法可以将任何东西转化为某种东西” . 总有一个更大的图景和更广泛的操作环境，您的解决方案必须适应 .
```
def mainloop():
    while True:
          ...
          if aRealTimeSCHEDULER.permitsXFORM1to2:
             try:
                 aMessage1 = Q1.recv( NOBLOCK )
                 if aMessage1 != EMPTY:
                    try:
                        aMessage2 = transform( aMessage1 )
                        Q2.send( aMessage2 )
                    except:
                        ...
                    finally:
                        ...
             except:
                 ...
             finally:
                 ...
```
但是，如果您不需要持久性/日志记录代理（另一方面是风险性能奇点），ZeroMQ / nanomsg等人会为您提供强大的原型来设计智能，基于代理的所需的所有内容，可重复使用的可扩展的正式通信模式，这将允许您快速原型化并实现特定于域的转换实用程序（无论是单向，双向，任何意义上的事务） .

Creating your own ，特定于域， { inproc:// | ipc:// | tcp:// | pgm:// | ... } 与传输无关， { localhost | grid | cloud | GPGPU | FPGA } 异构可分布式，性能可扩展 { round-robin | weighted load-balancing } ，自我修复重新实施/ SPOF保护，包括任何其他控制/自诊断/监视平面（s ），为您需要在生产环境中部署的任何转换方案添加强大功能 .

json.in，json.out，yaml.in，yaml.out之间的胶水逻辑？

只有一张图片，图60来自下面提到的书：

最好的下一步？

To see a bigger picture on this subject有更多的参数，一个简单的信号平面图片，以及与Pieter HINTJENS必读书籍的直接链接 .

如果对ZeroMQ的妹妹感兴趣，那就是来自Martin SUSTRIK nanomsg.org的更轻量级的框架 .
回复于 2024-04-25T08:03:03+08:00

双向消息队列

2 回答

相似的词，但意义不同 .

概念很重要 .

json.in，json.out，yaml.in，yaml.out之间的胶水逻辑？

最好的下一步？

相关问题