是什么让他们比编写自己的库更好？
在推出您的应用程序的第一个版本时，可能什么都没有：您的需求已明确定义，您将开发一个满足您需求的消息传递系统：小功能列表、小源代码等。
这些工具在第一个版本之后非常有用，当您实际上必须扩展您的应用程序并为其添加更多功能时。让我给你几个用例：
一开始你在一个局域网内有 3 台机器，没有明显的延迟，一切都到达每台机器。您的客户/老板/pointy-haired-devil-boss 出现并告诉您将在您不管理的 WAN 上安装应用程序 - 然后您开始出现连接失败、延迟不佳等问题。您需要存储消息并重试发送他们稍后：回到代码并插入这些东西（并享受）
发送的消息需要有回复，但不是全部：您发送一些参数并期望电子表格作为结果，而不是仅仅发送和确认，返回代码并将这些东西插入（并享受。）
还有许多我忘记的其他用例......
您可以自己实现它，但不要花费太多时间：无论如何您可能会在以后替换它。
这很像问：既然可以编写自己的数据库，为什么还要使用数据库？
答案是使用一个已经存在了一段时间并且在许多不同的用例中都被很好理解的工具，随着时间的推移和您的需求的发展，会获得越来越多的回报。如果一个项目涉及多个开发人员，则尤其如此。如果你改变一个新项目，你想成为排队系统的支持人员吗？使用工具可以防止这种情况发生。它变成了别人的问题。
举个例子：坚持。编写一个在磁盘上存储一条消息的工具很容易。在许多不同的用例中编写一个可扩展、性能良好且稳定的持久化器，并且易于管理且支持成本低廉，是很困难的。如果你想看到有人抱怨它有多难，那么看看这个：http ://www.lshift.net/blog/2009/12/07/rabbitmq-at-the-skills-matter-functional-programming-exchange
无论如何，我希望这会有所帮助。一定要编写自己的工具。很多很多人都这样做了。无论解决你的问题，都是好的。
我正在考虑自己使用 ZeroMQ - 因此我偶然发现了这个问题。
让我们暂时假设您有能力实现一个满足您所有要求的消息队列系统。为什么你会采用 ZeroMQ（或其他第三方库）而不是自己滚动的方法？简单 - 成本。
让我们暂时假设 ZeroMQ 已经满足您的所有要求。需要做的就是将它集成到您的构建中，阅读一些文档，然后开始使用它。这比滚动你自己的努力要少得多。此外，维护负担已转移到另一家公司。由于 ZeroMQ 是免费的，就好像您刚刚扩大了您的开发团队以包括（部分）ZeroMQ 团队。
如果您经营软件开发业务，那么我认为您会平衡使用第三方库与滚动您自己的库的成本/风险，在这种情况下，使用 ZeroMQ 将赢得胜利。
也许您（或者更确切地说，您的合作伙伴）像许多开发人员一样遭受“非此处发明”综合症的困扰？如果是这样，请调整态度并重新评估 ZeroMQ 的使用。就个人而言，我更喜欢 Proudly Found Elsewhere 态度的好处。我希望我能为找到 ZeroMQ 感到自豪……时间会证明一切。
编辑：我从 ZeroMQ 开发人员那里看到了这个视频，它讨论了为什么应该使用 ZeroMQ。
是什么让他们比编写自己的库更好？
消息队列系统是事务性的，从概念上讲，它作为客户端很容易使用，但作为实现者很难正确使用，尤其是考虑到持久队列。您可能认为编写一个快速消息传递库可以侥幸成功，但如果没有事务和持久性，您将无法获得消息传递系统的全部优势。
在这种情况下，持久性意味着消息传递中间件将未处理的消息保存在永久存储（磁盘上）中，以防服务器出现故障；重新启动后，可以处理消息并且无需重新传输（发件人甚至不知道有问题）。事务性意味着您可以以事务性方式从不同队列读取消息并将消息写入不同队列，这意味着要么所有读取和写入都成功，要么（如果一个或多个失败）没有一个成功。这与与数据库接口已知的事务性并没有太大区别，并且具有相同的好处（它简化了错误处理；没有事务，您必须确保每个单独的读/写成功，如果一个或多个失败，您有回滚那些确实成功的更改）。
在编写自己的库之前，请在此处阅读 0MQ 指南：http: //zguide.zeromq.org/page :all
您可能会决定安装 RabbitMQ，或者您将在 ZeroMQ 之上创建您的库，因为他们已经完成了所有困难的部分。
如果您有一点时间，请尝试一下并推出您自己的实现！本练习的学习将使您相信使用已经测试过的库的智慧。