为什么要使用AMQP/ZeroMQ/RabbitMQ [英] Why use AMQP/ZeroMQ/RabbitMQ

问题描述

与编写自己的库相反.

我们正在这里的一个项目中进行工作，该项目将是一个自划分服务器池，如果其中一个区域变得太重，经理将对其进行划分并将其作为单独的进程放置在另一台计算机上.它还会警告所有连接的客户端，这会影响到新服务器的连接.

We're working on a project here that will be a self-dividing server pool, if one section grows too heavy, the manager would divide it and put it on another machine as a separate process. It would also alert all connected clients this affects to connect to the new server.

我很好奇将ZeroMQ用于服务器间和进程间通信.我的伴侣更愿意自己动手​​.我希望社区能够回答这个问题.

I am curious about using ZeroMQ for inter-server and inter-process communication. My partner would prefer to roll his own. I'm looking to the community to answer this question.

我本人是一个相当新手的程序员，刚刚了解了消息队列.当我搜索和阅读时，似乎每个人都在使用消息传递队列处理各种事情，但是为什么呢?是什么使它们比编写您自己的库更好?为什么它们如此普遍，为什么那么多?

I'm a fairly novice programmer myself and just learned about messaging queues. As i've googled and read, it seems everyone is using messaging queues for all sorts of things, but why? What makes them better than writing your own library? Why are they so common and why are there so many?

推荐答案

是什么使它们比编写自己的库更好?

what makes them better than writing your own library?

推出应用程序的第一个版本时，可能什么都不做:您的需求得到了很好的定义，并且您将开发出满足自己需求的消息传递系统:小的功能列表，小的源代码等.

When rolling out the first version of your app, probably nothing: your needs are well defined and you will develop a messaging system that will fit your needs: small feature list, small source code etc.

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

Those tools are very useful after the first release, when you actually have to extend your application and add more features to it. Let me give you a few use cases:

• 您的应用程序必须与一台小型Endian机(x86，intel/amd)与一台大型endian机(sparc/powerpc)进行通信.您的消息传递系统具有一些字节序排序假设:请对其进行修复
• 您设计的应用程序不是二进制协议/消息系统，现在它非常慢，因为您花费了大部分时间来解析它(消息数量增加，并且解析成为瓶颈):对其进行调整以使其能够传输二进制/固定编码

• 一开始，您在一个局域网内有3台计算机，所有设备到达每个计算机的延迟都没有明显的延迟.您的客户端/老板/pointed-hair-devil-boss出现并告诉您，您将在不受管理的WAN上安装该应用程序-然后开始出现连接失败，延迟时间长等问题，您需要存储消息并重试发送稍后:返回代码，并将其插入(并享受)

• your app will have to talk to a big endian machine (sparc/powerpc) from a little endian machine (x86, intel/amd). Your messaging system had some endian ordering assumption: go and fix it
• you designed your app so it is not a binary protocol/messaging system and now it is very slow because you spend most of your time parsing it (the number of messages increased and parsing became a bottleneck): adapt it so it can transport binary/fixed encoding

• at the beginning you had 3 machine inside a lan, no noticeable delays everything gets to every machine. your client/boss/pointy-haired-devil-boss shows up and tell you that you will install the app on WAN you do not manage - and then you start having connection failures, bad latency etc. you need to store message and retry sending them later on: go back to the code and plug this stuff in (and enjoy)

消息需要答复，但不是全部答复:您在其中发送一些参数，并期望得到电子表格，而不仅仅是发送并确认，然后返回代码并将其插入(并享受.)

messages sent need to have replies, but not all of them: you send some parameters in and expect a spreadsheet as a result instead of just sending and acknowledges, go back to code and plug this stuff in (and enjoy.)

还有我忘记的许多其他用例...

And many other use cases that I forgot ...

您可以自己实现它，但不要花很多时间:反正以后您可能会替换它.

You can implement it yourself, but do not spend much time doing so: you will probably replace it later on anyway.

这篇关于为什么要使用AMQP/ZeroMQ/RabbitMQ的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！