为什么使用 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:

• 您的应用程序必须与来自小端机器(x86、intel/amd)的大端机器(sparc/powerpc)通信.您的消息传递系统有一些端序假设:去修复它
• 您设计的应用程序不是二进制协议/消息系统，现在它非常慢，因为您花费了大部分时间来解析它(消息数量增加并且解析成为瓶颈):调整它以便它可以传输二进制/固定编码

• 一开始你在一个局域网中有 3 台机器，没有明显的延迟，一切都到达每台机器.您的客户/老板/pointy-haired-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屋！