为什么使用 AMQP/ZeroMQ/RabbitMQ

而不是写你自己的图书馆。

我们正在进行一个项目，这将是一个自我分割的服务器池，如果一个部分变得太重，经理将分割它，并把它放在另一台机器上作为一个单独的进程。它还会提醒所有已连接的客户端这会影响到连接到新服务器。

我对在服务器间和行程间通讯中使用 ZeroMQ 感到好奇。我的搭档更喜欢自己卷。我希望社区能回答这个问题。

我自己是一个相当新手的程序员，刚刚学习了消息传递队列。我在谷歌和阅读时发现，似乎每个人都在使用消息队列做各种事情，但是为什么呢？还有什么比自己编写图书馆更好的呢？为什么它们如此普遍，为什么有这么多？

22079 次浏览
小开

还有什么比写自己的图书馆更好的呢？

消息队列系统是事务性的，从概念上讲，它很容易用作客户机，但很难用作实现者，特别是考虑到持久性队列。您可能认为您可以编写一个快速消息库，但是如果没有事务和持久性，您就无法获得消息传递系统的全部好处。

在此上下文中的持久性意味着消息传递中间件将未处理的消息保存在永久存储器(磁盘上)中，以防服务器出现故障; 重新启动后，消息可以被处理，不需要重新传输(发送方甚至不知道存在问题)。事务性意味着您可以以事务性方式从不同队列读取消息并将消息写入到不同的队列，这意味着所有读取和写入都成功，或者(如果一个或多个失败)都不成功。这与与数据库接口的事务处理没有太大区别，而且具有相同的好处(它简化了错误处理; 没有事务，您必须确保每个单独的读/写成功，如果一个或多个失败，您必须回滚那些成功的更改)。

小开
最佳答案

还有什么比写自己的图书馆更好的呢？

当推出你的应用程序的第一个版本时，可能什么都没有: 你的需求是明确定义的，你将开发一个适合你的需求的消息系统: 小功能列表，小源代码等。

这些工具是 非常有用的 之后的第一个版本，当您实际上必须扩展您的应用程序并向其添加更多功能时。 让我给你一些用例:

  • 您的应用程序将不得不与来自 little endian 机器(x86，Intel/amd)的 big endian 机器(Sparc/powerpc)进行对话。您的消息传递系统有一些端点排序假设: 去修复它
  • 你设计了你的应用程序，所以它不是一个二进制协议/消息系统，现在它非常慢，因为你花了大部分时间解析它(消息数量增加，解析成为一个瓶颈) : 适应它，使它能够传输二进制/固定编码

  • 一开始你在一个局域网中有3台机器，没有明显的延迟，所有的事情都到达了每一台机器。你的客户/老板/尖头发-魔鬼老板出现并告诉你，你会安装在广域网上你不管理的应用程序-然后你开始有连接失败，糟糕的延迟等，你需要存储信息和重新尝试发送他们以后: 回到代码和插入这些东西(和享受)

  • 发送的消息需要有回复，但不是全部: 您发送一些参数，并期望得到一个电子表格，而不是仅仅发送和确认，回到代码并插入这些内容(并享受)

  • 有些消息是关键的，接收/发送需要适当的备份/持久性/

还有很多我忘记的用例。

您可以自己实现它，但是不要花太多时间这样做: 您可能会在以后替换它。

小开

这很像是在问: 既然可以编写自己的数据库，为什么还要使用数据库呢？

答案是，使用一个已经存在了一段时间并且在许多不同的用例中都很容易理解的工具，随着时间的推移和需求的发展，会带来越来越多的回报。如果一个项目中涉及多个开发人员，情况尤其如此。如果更改为新项目，是否希望成为队列系统的支持人员？使用工具可以防止这种情况发生。成了别人的问题。

一个很好的例子: 持久性。编写在磁盘上存储一条消息的工具很容易。在许多不同的用例中，编写一个稳定伸缩并执行良好的 还有的持久化器是困难的，而且是可管理的，并且支持成本低廉。如果你想看到有人抱怨这有多难，那么看看这个: http://www.lshift.net/blog/2009/12/07/rabbitmq-at-the-skills-matter-functional-programming-exchange

不管怎样，我希望这能帮上忙。请务必自己编写工具。许多人都这样做了。只要能解决你的问题就好。

小开

我正在考虑自己使用 ZeroMQ ——因此我偶然发现了这个问题。

让我们暂时假设您能够实现满足所有需求的消息队列系统。为什么要采用 ZeroMQ (或其他第三方库)而不是自己滚动的方法？简单的成本。

让我们假设 ZeroMQ 已经满足了您的所有需求。所有需要做的就是将它集成到您的构建中，阅读一些 doco，然后开始使用它。这肯定比你自己动手省力多了。此外，维修负担已转移到另一家公司。由于 ZeroMQ 是免费的，这就好像您刚刚扩展了您的开发团队，使其包括(成为) ZeroMQ 团队的一部分。

如果您经营的是软件开发业务，那么我认为您将平衡使用第三方库的成本/风险和使用您自己的库，在这种情况下，使用 ZeroMQ 将轻而易举地获胜。

也许你(或者更确切地说，你的伴侣)和许多开发人员一样，患有 “不是在这里发明的”综合症？如果是这样，请调整您的态度并重新评估 ZeroMQ 的使用。就个人而言，我更喜欢“在别处找到自豪”的态度带来的好处。我希望我能为找到 ZeroMQ 而自豪... 时间会证明一切。

编辑: 我从 ZeroMQ 开发人员那里偶然发现了这个 视频，他们谈到了应该使用 ZeroMQ 的 为什么。

小开

如果您有一点时间，可以尝试一下，然后推出您自己的实现！这个练习的学习将使你确信使用一个已经测试过的库是明智的。

小开

在编写自己的库之前，请阅读0MQ Guide here: http://zguide.zeromq.org/page:all

您可能要么决定安装 RabbitMQ，要么在 ZeroMQ 之上创建库，因为它们已经完成了所有困难的部分。


提交答案