AMQP / ZeroMQ / RabbitMQを使用する理由
独自のライブラリを作成するのではなく。
ここでは、自己分割サーバープールとなるプロジェクトに取り組んでいます。あるセクションが大きくなりすぎると、マネージャーはそれを分割し、別のプロセスとして別のマシンに配置します。また、接続されているすべてのクライアントに、この影響が新しいサーバーに接続するように警告します。
サーバー間およびプロセス間通信にZeroMQを使用することに興味があります。私のパートナーは彼自身を転がすことを好むでしょう。この質問に答えるためにコミュニティを探しています。
私はかなり初心者のプログラマーであり、メッセージングキューについて学びました。私がグーグルで読んだように、誰もがあらゆる種類のことのためにメッセージングキューを使用しているようですが、なぜですか？独自のライブラリを作成するよりも優れているのは何ですか？なぜそんなに一般的で、なぜそんなに多いのですか？
独自のライブラリを作成するよりも優れているのは何ですか？
アプリの最初のバージョンを展開するとき、おそらく何もありません。ニーズは明確に定義されており、ニーズに合ったメッセージングシステムを開発します。小さな機能リスト、小さなソースコードなどです。
これらのツールはvery便利ですafterアプリケーションを実際に拡張して機能を追加する必要がある最初のリリースです。いくつかの使用例を挙げましょう。
- アプリは、リトルエンディアンマシン（x86、Intel/AMD）からビッグエンディアンマシン（sparc/powerpc）と通信する必要があります。メッセージングシステムには、エンディアンの順序付けの前提がいくつかあります。修正してください
- バイナリプロトコル/メッセージングシステムではないようにアプリを設計しましたが、今ではほとんどの時間を解析に費やしているため非常に遅くなっています（メッセージの数が増え、解析がボトルネックになりました）：バイナリ/固定エンコード
最初はLAN内に3台のマシンがありましたが、すべてのマシンに到達するのに顕著な遅延はありません。クライアント/上司/先のとがった悪魔-上司が表示され、アプリをWAN管理していません-そして、接続障害、悪いレイテンシーなどが発生するようになります。メッセージを保存して、後で送信を再試行する必要があります：コードに戻って、このものをプラグインします（お楽しみください）
送信されるメッセージには返信が必要ですが、すべてではありません。送信して確認するだけでなく、いくつかのパラメーターを送信し、結果としてスプレッドシートを期待します。
- 一部のメッセージは重要であり、受信/送信には適切なバックアップ/永続性/が必要です。なぜ聞くの ？監査目的
そして、私が忘れていた他の多くのユースケース...
自分で実装することもできますが、そうするのに多くの時間を費やさないでください。おそらくとにかく後で置き換えるでしょう。
それは尋ねるのと非常によく似ています：自分で書くことができるのに、なぜデータベースを使うのですか？
答えは、しばらく前から存在し、多くのさまざまなユースケースでよく理解されているツールを使用することで、時間の経過とともに要件が進化するにつれて益が増えるということです。これは、プロジェクトに複数の開発者が関与している場合に特に当てはまります。新しいプロジェクトに変更する場合、キューイングシステムのサポートスタッフになりたいですか？ツールを使用すると、それが発生しなくなります。それは他の誰かの問題になります。
適切なケース：永続性。 1つのメッセージをディスクに保存するツールを書くのは簡単です。多くのさまざまなユースケースで安定してandスケーリングし、実行し、管理しやすく、サポートが安価な永続化プログラムを作成するのは困難です。あなたが誰かがそれがどれほど難しいかについて不平を言うのを見たいなら、これを見てください： http://www.lshift.net/blog/2009/12/07/rabbitmq-at-the-skills-matter-functional -programming-exchange
とにかく、これが役立つことを願っています。必ず独自のツールを作成してください。多くの人々がそうしました。あなたの問題を解決するものは何でも良いです。
ZeroMQを自分で使用することを検討しています-したがって、私はこの質問に出くわしました。
現時点では、すべての要件を満たすメッセージキューシステムを実装できると仮定します。 Roll-your-ownのアプローチではなく、なぜZeroMQ（または他のサードパーティライブラリ）を採用するのですか？シンプル-コスト。
ZeroMQがすでにすべての要件を満たしていると仮定しましょう。行う必要があるのは、ビルドにそれを統合し、いくつかのドコを読んでからそれを使い始めることです。それはあなた自身を転がすよりもはるかに少ない労力になるはずです。さらに、メンテナンスの負担が別の会社に移されました。 ZeroMQは無料であるため、ZeroMQチーム（の一部）を含めるように開発チームを成長させたようなものです。
ソフトウェア開発ビジネスを運営している場合、サードパーティのライブラリを使用するコスト/リスクと、独自のライブラリを展開することのバランスを取ると思います。この場合、ZeroMQを使用すると、勝ちます。
おそらく、あなた（またはあなたのパートナー）は、非常に多くの開発者がそうであるように、 "ここでは発明されていません" シンドロームに苦しんでいますか？その場合、態度を調整し、ZeroMQの使用を再評価します。個人的に、私は他の場所で誇らしげに見られる態度の利点を大いに好みます。 ZeroMQを見つけることを誇りに思うことを願っています...時間が経てばわかるでしょう。
編集：私はこれに遭遇しました ビデオ ZeroMQを使用する必要があるwhyについて話すZeroMQ開発者から.
独自のライブラリを作成するよりも優れているのは何ですか？
メッセージキューシステムはトランザクション型であり、概念的にはクライアントとして簡単に使用できますが、特に永続キューを考慮すると、実装者として正しく機能するのは困難です。クイックメッセージングライブラリを作成しても問題ないと思うかもしれませんが、トランザクションや永続性がないと、メッセージングシステムのメリットを十分に享受できません。
このコンテキストでの永続性とは、サーバーがダウンした場合に、メッセージングミドルウェアが未処理のメッセージを（ディスク上の）永続ストレージに保持することを意味します。再起動後、メッセージを処理でき、再送信は必要ありません（送信者は問題があることすら知りません）。トランザクションとは、異なるキューからメッセージを読み取り、トランザクション形式で異なるキューにメッセージを書き込むことができることを意味します。つまり、すべての読み取りと書き込みが成功するか、（1つ以上が失敗した場合）成功しません。これは、データベースとのインターフェイスで知られているトランザクション性と実際にはそれほど変わらず、同じ利点があります（エラー処理が簡素化されます;トランザクションがなければ、個々の読み取り/書き込みが成功することを保証する必要があり、1つ以上が失敗すると、成功した変更をロールバックします）。
独自のライブラリを作成する前に、こちらの0MQガイドをお読みください。 http://zguide.zeromq.org/page:all
RabbitMQのインストールを決定するか、またはすべてのハードパーツを既に実行しているため、ZeroMQの上にライブラリを作成する可能性があります。
少し時間があれば、自分で実装してみてください！この演習の学習は、既にテストされたライブラリを使用する知恵についてあなたを納得させます。