为什么要使用AMQP / ZeroMQ / RabbitMQ
而不是写自己的图书馆。
我们正在开发一个项目，这个项目将是一个自我分割的服务器池，如果一个部分变得太重了，那么pipe理员会把它分开，并把它作为一个单独的进程放在另一台机器上。 它也会提醒所有连接的客户端，这会影响连接到新的服务器。
我很好奇使用ZeroMQ进行服务器间和进程间通信。 我的合作伙伴宁愿推出自己的。 我期待社区回答这个问题。
我自己是一个相当新手的程序员，只是了解消息队列。 正如我已经google和阅读，似乎每个人都在使用消息队列的各种事情，但为什么？ 是什么让他们比写自己的图书馆更好？ 他们为什么这么常见，为什么这么多？
是什么让他们比写自己的图书馆更好？
在推出应用程序的第一个版本时，可能什么都不是：您的需求已经定义好，您将开发一个适合您需求的消息系统：小function列表，小源代码等。
这些工具在第一次发布之后 非常有用，当时你实际上需要扩展你的应用程序并增加更多function。 让我给你几个用例：
- 你的应用程序将不得不与一台小型机器（x86，intel / amd）的大型机器（sparc / powerpc）进行通信。 你的消息系统有一些endian有序的假设：去解决它
- 你devise的应用程序，所以它不是一个二进制协议/消息系统，现在它是非常缓慢的，因为你花大部分时间parsing它（消息的数量增加，parsing成为一个瓶颈）：适应它，所以它可以传输二进制/固定编码
-
一开始你有一台局域网里面有3台机器，没有明显的延迟，一切都到达每台机器。 你的客户/老板/尖头老头老板出现并告诉你，你将在你不pipe理的广域网上安装应用 – 然后你开始有连接失败，延迟等等，你需要存储消息并重试发送他们后来：回到代码并插入这个东西（并享受）
-
发送的消息需要有回复，但不是全部：发送一些参数，期望一个电子表格作为结果，而不仅仅是发送和确认，返回到代码并插入这些东西（并享受）。
- 一些消息是关键的，并且接收/发送需要正确的备份/持久性/。 你为什么问 ？ 审计目的
还有很多我忘记的用例
你可以自己实现它，但是不要花太多的时间这么做：你可能会在稍后取代它。
这很像问：为什么使用数据库，当你可以写自己的？
答案是，使用一个已经存在一段时间并且在许多不同用例中已经很好理解的工具，随着时间的推移，随着您的需求的变化，付出的代价将越来越大。 如果一个项目涉及多个开发人员，情况尤其如此。 如果你改变一个新的项目，你想成为排队系统的支持人员吗？ 使用工具可以防止发生这种情况。 这成为别人的问题。
例如：持久性。 编写一个工具将一条消息存储在磁盘上很容易。 在许多不同的使用情况下，编写一个能够很好地，稳定地进行扩展和执行的可执行文件，并且易于pipe理，而且价格便宜。 如果你想看到有人抱怨有多难，那么看看这个： http : //www.lshift.net/blog/2009/12/07/rabbitmq-at-the-skills-matter-functional-programming-exchange
无论如何，我希望这有助于。 通过一切手段写你自己的工具。 许多人都这样做了。 无论如何解决你的问题，是好的。
我正在考虑自己使用ZeroMQ – 因此我偶然发现了这个问题。
现在假设您有能力实现符合您所有要求的消息排队系统。 你为什么会采用ZeroMQ（或其他第三方库）来处理自己的方法？ 简单 – 成本。
让我们暂时假设ZeroMQ已经满足您的所有要求。 所有需要做的就是将它集成到你的构build中，阅读一些doco，然后开始使用它。 这比滚动你自己的努力要less得多。 此外，维护负担已经转移到另一家公司。 由于ZeroMQ是免费的，就像您刚开发的开发团队包括（部分）ZeroMQ团队一样。
如果你运行一个软件开发业务，那么我认为你会平衡使用第三方库的成本/风险，而这种情况下，使用ZeroMQ将胜出。
也许你（或者更确切地说，你的伴侣）像“这里没有发明”这样的综合症一样受到很多开发者的影响？ 如果是这样，调整你的态度，并重新评估ZeroMQ的使用。 就我个人而言，我更喜欢Proudly Found Elsewhere态度的好处。 我希望我能为findZeroMQ感到自豪…时间会告诉你。
编辑：我从ZeroMQ开发人员遇到这个video ，谈论为什么你应该使用ZeroMQ。
是什么让他们比写自己的图书馆更好？
消息队列系统是事务性的，在概念上很容易用作客户端，但作为一个实现者很难正确使用，特别是考虑到持久队列。 你可能会认为你可以通过编写一个快速的消息库来逃避，但是没有事务和持久性，你就没有消息系统的全部好处。
在这种情况下的持久性意味着消息中间件在服务器closures的情况下将未处理的消息保持在永久存储器（在磁盘上） 重启后，消息可以被处理，不需要重发（发送者甚至不知道有问题）。 事务性意味着您可以读取来自不同队列的消息，并以事务性方式将消息写入不同的队列，这意味着所有读写操作都成功或者（如果一个或多个失败）都不成功。 这与从数据库接口中获得的事务性没有多大区别，并且具有相同的好处（它简化了error handling;如果没有事务处理，则必须保证每个单独的读写成功，如果有一个或多个失败，回滚那些成功的改变）。
在编写自己的库之前，请阅读0MQ指南：http: //zguide.zeromq.org/page : all
有可能你会决定安装RabbitMQ，否则你会在ZeroMQ之上build立你的库，因为他们已经完成了所有的难题。
如果你有一点时间试一试，推出你自己的实现！ 这个练习的知识将使你相信使用已经testing过的库的智慧。
