AMQP / ZeroMQ / RabbitMQを使用する理由

Question

独自のライブラリを作成するのではなく、

ここでは、自己分割サーバープールとなるプロジェクトに取り組んでいます。1つのセクションが大きくなりすぎると、マネージャーはそれを分割し、別のプロセスとして別のマシンに配置します。また、接続しているすべてのクライアントに、これが新しいサーバーへの接続に影響することを警告します。

ZeroMQをサーバー間およびプロセス間通信に使用することに興味があります。私のパートナーは彼自身のロールを好むでしょう。この質問に答えてくれるコミュニティを探しています。

私はかなり初心者のプログラマーであり、メッセージングキューについて学びました。私がグーグルで読んだように、誰もがあらゆる種類のメッセージキューを使用しているようですが、なぜですか？独自のライブラリを作成するよりも優れているのは何ですか？なぜそんなに一般的で、なぜそんなに多いのですか？

Answer 1

  

独自のライブラリを書くよりも優れているのは何ですか？

アプリの最初のバージョンを展開するとき、おそらく何もありません：ニーズは明確に定義されており、ニーズに合ったメッセージングシステムを開発します：小さな機能リスト、小さなソースコードなど

これらのツールは、実際にアプリケーションを拡張し、より多くの機能を追加する必要がある場合に、最初のリリース後非常に便利です 。 いくつかの使用例を挙げましょう：

• アプリは、リトルエンディアンマシン（x86、intel / amd）からビッグエンディアンマシン（sparc / powerpc）と通信する必要があります。メッセージングシステムには、エンディアンの順序付けの前提があります。修正してください
• バイナリプロトコル/メッセージングシステムではないようにアプリを設計しましたが、今ではほとんどの時間を解析に費やしているため非常に遅くなっています（メッセージの数が増加し、解析がボトルネックになっています）：トランスポートバイナリ/固定エンコード

• 最初はLAN内に3台のマシンがありましたが、すべてのマシンに到達するのに顕著な遅延はありません。クライアント/上司/先のとがった悪魔-上司が表示され、管理していないWANにアプリをインストールすることを伝えます-そして、接続障害、悪い待ち時間などが発生し始めます。メッセージを保存して送信を再試行する必要があります。それらを後で：コードに戻り、このものをプラグインします（そして楽しんでください）

• 送信されるメッセージには返信が必要ですが、すべてではありません。送信して確認するだけでなく、いくつかのパラメータを送信し、結果としてスプレッドシートを期待し、コードに戻ってこのものを接続します。）

• 一部のメッセージは重要であり、受信/送信には適切なバックアップ/永続性/が必要です。なぜ聞くの ？監査目的

そして私が忘れていた他の多くのユースケース...

自分で実装することもできますが、そうするのにあまり時間をかけないでください。おそらくとにかく後で置き換えるでしょう。

Answer 2

それは非常によく似ています：独自のデータベースを作成できるのに、なぜデータベースを使用するのですか？

答えは、しばらく前から存在し、多くのさまざまなユースケースで十分に理解されているツールを使用することで、時間の経過とともに要件が進化するにつれて成果が上がるということです。これは、プロジェクトに複数の開発者が関与している場合に特に当てはまります。新しいプロジェクトに変更する場合、キューシステムのサポートスタッフになりたいですか？ツールを使用することで、それが起こらないようにします。それは他の誰かの問題になります。

インケース：永続性。 1つのメッセージをディスクに保存するツールを書くのは簡単です。多くのさまざまなユースケースで安定して拡張および実行できる永続性を作成し、管理しやすく、サポートが安価であるのは困難です。あなたがそれがどれほど難しいかについて不平を言っているのを見たいなら、これを見てください： http://www.lshift.net/blog/2009/12/07/rabbitmq-at-the-skills-matter-functional-programming-exchange

とにかく、これが役立つことを願っています。必ず独自のツールを作成してください。多くの人々がそうしました。問題を解決するものは何でも良いです。

Answer 3

ZeroMQを自分で使用することを検討しています-したがって、この質問に出くわしました。

ここでは、すべての要件を満たすメッセージキューシステムを実装できると仮定します。 Roll-your-ownのアプローチではなく、なぜZeroMQ（または他のサードパーティライブラリ）を採用するのですか？シンプル-コスト。

ZeroMQがすでにすべての要件を満たしていると仮定しましょう。行う必要があるのは、ビルドにそれを統合し、いくつかのドコを読んでから使用を開始することだけです。それはあなた自身のものを転がすよりもはるかに少ない労力になるはずです。さらに、メンテナンスの負担は別の会社に移されました。 ZeroMQは無料であるため、ZeroMQチーム（の一部）を含めるように開発チームを成長させたようなものです。

ソフトウェア開発ビジネスを運営している場合、サードパーティのライブラリを使用するコスト/リスクと、独自のライブラリを展開することのバランスを取ると思います。この場合、ZeroMQを使用すると、勝ちます。

おそらく（多くの開発者がそうであるように）＆quot; Not Here＆quot; 症候群を発明しましたか？その場合、態度を調整し、ZeroMQの使用を再評価します。個人的には、他の場所で誇らしげに見られる態度の利点を大いに好みます。 ZeroMQを見つけることを誇りに思うことを願っています...時間が経てばわかるでしょう。

編集： ZeroMQ開発者からのビデオ。なぜ ZeroMQを使用する必要があるかについて説明しています。

Answer 4

  

独自のライブラリを書くよりも優れているのは何ですか？

メッセージキューシステムはトランザクション型であり、クライアントとして概念的には簡単に使用できますが、特に永続キューを考慮すると、実装者として適切に取得するのは困難です。クイックメッセージングライブラリを作成しても問題ないと思うかもしれませんが、トランザクションや永続性がないと、メッセージングシステムのメリットを十分に享受できません。

このコンテキストでの永続性とは、サーバーがダウンした場合に、メッセージングミドルウェアが未処理のメッセージを（ディスク上の）永続ストレージに保持することを意味します。再起動後、メッセージを処理でき、再送信は不要です（送信者は問題があることすら知りません）。トランザクションとは、異なるキューからメッセージを読み取り、トランザクション形式で異なるキューにメッセージを書き込むことができることを意味します。つまり、すべての読み取りと書き込みが成功するか、（1つ以上の失敗の場合）成功しません。これは、データベースとのインターフェイスで知られているトランザクション性と実際にはそれほど変わらず、同じ利点があります（エラー処理を簡素化します;トランザクションがなければ、個々の読み取り/書き込みが成功し、1つ以上が失敗した場合、成功した変更をロールバックします）。

Answer 5

独自のライブラリを作成する前に、ここで0MQガイドをお読みください： http://zguide.zeromq.org/ page：all

チャンスは、RabbitMQをインストールすることを決定するか、すでにすべてのハードパーツを実行しているため、ZeroMQの上にライブラリを作成することです。

Answer 6

少し時間があれば、自分で実装してみてください！この演習の学習は、すでにテストされたライブラリを使用する知恵についてあなたを納得させます。