双向消息队列

Question

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

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

Answer 1

使用队列来翻译邮件格式似乎有些过分。这本身听起来效率低下，所以如果你选择以这种方式进行信息翻译，你就已经走错了路，可以选择你喜欢的任何选项，因为它们都不好。

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

Answer 2

类似的词，但意义不同。

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

概念很重要。

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

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

为了你的转型动机问题，一个简单的答案是“没有普遍的魔法可以将任何东西转化为某种东西”。总有一个更大的图景和更广泛的操作环境，您的解决方案必须适应。

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等人会为您提供强大的原型来设计智能所需的所有内容，基于代理的，可扩展的正式通信模式被重用，这将允许您快速原型化并实现特定于域的转换实用程序（无论是单向的，双向的，任何意义上的事务性）。

创建您自己的，特定于域，{ inproc:// | ipc:// | tcp:// | pgm:// | ... }传输无关， { localhost | grid | cloud | GPGPU | FPGA } 异构可分发，性能可扩展{ round-robin | weighted load-balancing }，自我修复的重新实施/ SPOF保护，包括任何其他控制/自我诊断/监控平面，为您在生产中部署所需的任何转换方案增添了强大的力量。 / p>

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

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

最好的下一步？

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

如果对ZeroMQ的妹妹感兴趣，可以检查一下来自Martin SUSTRIK nanomsg.org的更轻量级的框架。