双向消息队列

Question

这似乎是一个常见问题解答中的问题，但我无法说出这个问题来找到它的答案。
无论如何，我目前正在研究消息队列（在 ZeroMQ、RabbitMQ 教程上进行了介绍），我认为 MQ 非常适合转换数据流 - 在 Q1 上侦听 F1 格式的消息，转换为 F2 并将转换后的消息放在 Q2 上。如果转换本质上是双向的并且没有明确定义的消费者和生产者（例如yamljson 转换器？

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

• 有两个不同的输入输出队列，在本例中转换为 4：json.in、json.out、yaml.in、yaml.out；
• 将转换器连接到 JSON 队列的两端，以区分原始 json 和从 yaml 转换而来的消息，将消息包装在消息中，指定这是传入消息还是传出消息。但因此，转换器现在会收到大量消息，必须对其进行解析并重新插入队列 - 听起来效率极低。

前一个解决方案听起来像是一条路，除非后者以某种形式委托给 MQ 代理（例如消费者/生产者 ID：json.out, id = connect_produce("json", null); json.in = connect_consume("json", id);），并且如果消息是由同一个实体。据我了解，任何类型的过滤都归结为消息标记（RabbitMQ 中的主题交换），这需要多个队列。

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

Answer 1

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

就选择队列设计而言，无论您使用它做什么，从逻辑上讲，双向队列与两个单向队列相同。选择适合您使用的队列实现的任何一种即可。

Answer 2

相似词，但含义不同。

虽然许多软件使用“队列”、“套接字”、“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 保护，包括任何额外的控制/自我诊断/监控平面，为您需要在生产中部署的任何转换方案增加了强大的能力。

---

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

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

---

最好的下一步？

To see a bigger picture on this subject 包含更多参数、简单的信​​号平面图片和指向 Pieter HINTJENS 必读书籍的直接链接。

如果对 ZeroMQ 的妹妹 nanomsg 感兴趣，请查看来自 Martin SUSTRIK nanomsg.org 的更轻量级框架。