我试图了解AMQP。它看起来非常适合应用程序之间的机器间（集群、LAN、WAN）通信，但我不确定它是否适合（在架构和当前实现方面）用作一台机器内的软件总线。
是否值得拔出当前的高性能消息传递框架来用 AMQP 替换它，或者这是否会通过模糊本地和非本地通信之间的区别而落入与 RPC 相同的陷阱？
我也对使用 WAN 技术进行机器内通信的性能影响持谨慎态度，尽管这可能更多的是实现而不是架构问题。
战争故事将不胜感激。
Bwooce
问问题
2160 次
6 回答
3
AMQP 不是 RPC 框架。它提供了构建模块来对共享队列、RPC、pubsub 等事物进行建模，但它并没有规定任何特定的使用方式。
如果您想对应用程序进行分区（使其在途中可分发）并将其与 AMQP 连接在一起，我认为这是正确的技术。虽然可能有更快的替代方案，但可能没有像 AMQP 那样通用。
于 2009-08-15T11:48:48.613 回答
2
AMQP 是一种规范，因此您实际上是在比较苹果和橙子。真的没有那么多生产就绪的 AMQP 提供者。在撰写本文时，主要的消息传递提供程序或供应商都没有支持 AMQP（例如 IBM、Tibco、Sonic、BEA、Oracle、SwiftMQ、MS、Apache ActiveMQ、Sun 的 openmq）——因此所有可用的 AMQP 提供程序都是相当新的。
因此，我建议将您感兴趣的任何 AMQP 提供程序与您的消息传递框架进行比较。仅仅因为它读取和写入字节到套接字的方式，就撕掉一些工作正常的东西是没有意义的:)
于 2008-10-31T09:55:19.653 回答
1
作为可靠、极其灵活（就消息传递模式而言）的基础，它可以用于许多消息传递场景，包括机器内（即进程间）和网络间。它可以从零扩展到庞大的高带宽多网络系统。
我目前正在为一个小型但相对复杂的近实时系统评估它，我们不关心消息传播多远或谁/什么（在合理范围内；）正在消耗它们。如果消费者坐在同一台机器上，那就这样吧。我会试一试，看看你是怎么做的。如果您想拼凑一个原型系统，请使用 python 和Pika库。
于 2009-10-12T21:32:12.897 回答
1
AMQP 标准正在变得成熟，并解决了一些困扰 JMS 等其他消息传递标准的棘手问题。对于您是否值得更换现有解决方案的问题，我想说这取决于。我会非常怀疑，因为大概系统已经在工作，在生产中并且高性能。
如果您遇到以下问题：
- 互操作性不起作用
- 无法轻松扩展
- 性能不够好
- 当前的消息传递解决方案很昂贵（维护）
您应该调查所需的工作并更准确地分析收益。如果您已经满意，更换消息传递框架不会带来投资回报。
于 2010-06-12T07:51:47.700 回答
0
AMQP 看起来更像是为 SOA 提供的可靠传输中间件，而不是内部使用的东西。
于 2008-12-09T15:08:00.060 回答
0
如果您主要对机器内场景中的性能感兴趣，那么问题不在于 AMQP（它只是一个线路级协议），而在于您应该尝试哪种实现。
通过消除网络引入的延迟，您可能会对各种实现的原始性能更加敏感。因此，我会研究用 C++ 实现的产品，例如 Qpid 或 Zeromq。
在一些不错的硬件（四核）上，Qpid 可以轻松达到每秒 400 000 条消息（消息为 1024 字节）。Zeromq 可能会执行得更好，因为您可以拥有对等通道，而 Qpid 使用代理架构（有一个步骤）。
于 2009-12-03T11:55:58.943 回答