独自のライブラリを作成するのとは対照的です。
ここでは、自己分割サーバー プールとなるプロジェクトに取り組んでいます。1 つのセクションが重くなりすぎると、マネージャーはそれを分割し、別のプロセスとして別のマシンに配置します。また、これが影響を与えるすべての接続済みクライアントに、新しいサーバーに接続するように警告します。
サーバー間およびプロセス間通信に ZeroMQ を使用することに興味があります。私のパートナーは自分でロールすることを好みます。この質問に答えるコミュニティを探しています。
私自身かなり初心者のプログラマーで、メッセージング キューについて学んだばかりです。私がググって読んだように、誰もがあらゆる種類のメッセージキューを使用しているようですが、なぜですか? 独自のライブラリを作成するよりも優れている点は何ですか? なぜそれらはとても一般的で、なぜそんなにたくさんあるのですか?
独自のライブラリを作成するよりも優れている点は何ですか?
アプリの最初のバージョンをロールアウトするときは、おそらく何もありません。ニーズは明確に定義されており、ニーズに合ったメッセージング システムを開発します: 小さな機能リスト、小さなソース コードなど。
これらのツールは、最初のリリース後、実際にアプリケーションを拡張して機能を追加する必要がある場合に非常に役立ちます。いくつかの使用例を紹介します。
最初はLAN内に3台のマシンがありましたが、すべてがすべてのマシンに到達するのに目立った遅延はありません。client/boss/pointy-haired-devil-boss が表示され、管理していない WAN にアプリをインストールすると通知されます。その後、接続障害や遅延などの問題が発生し始めます。メッセージを保存して送信を再試行する必要があります。後で: コードに戻って、これをプラグインします (そして楽しんでください)。
送信されたメッセージには返信が必要ですが、すべてではありません。送信して確認するだけでなく、いくつかのパラメーターを送信して結果としてスプレッドシートを期待し、コードに戻ってこれをプラグインします (そして楽しんでください)。
そして、私が忘れていた他の多くのユースケース...
自分で実装することもできますが、そうするのに多くの時間を費やす必要はありません。おそらく後で置き換えることになるでしょう。
これは、自分でデータベースを作成できるのに、なぜデータベースを使用するのかという質問に似ています。
答えは、しばらく前から存在し、さまざまなユースケースでよく理解されているツールを使用すると、時間の経過とともに要件が進化するにつれて、より多くの成果が得られるということです。これは、プロジェクトに複数の開発者が関与している場合に特に当てはまります。新しいプロジェクトに変更する場合、キューイング システムのサポート スタッフになりませんか? ツールを使用することで、それを防ぐことができます。それは他人の問題になる。
適切な例: 持続性。1 つのメッセージをディスクに保存するツールを作成するのは簡単です。多くの異なるユースケースで適切かつ安定してスケーリングし、パフォーマンスを発揮し、管理しやすく、サポートが安価な永続化プログラムを作成することは困難です。それがどれほど難しいかについて誰かが不平を言っているのを見たい場合は、これを見てください: http://www.lshift.net/blog/2009/12/07/rabbitmq-at-the-skills-matter-functional-programming-exchange
とにかく、これが役立つことを願っています。ぜひ、独自のツールを作成してください。多くの人がそうしてきました。あなたの問題を解決するものは何でも良いです。
私は自分でZeroMQを使用することを検討しています-したがって、この質問に出くわしました.
ここでは、すべての要件を満たすメッセージ キューイング システムを実装できると仮定しましょう。独自のアプローチではなく、ZeroMQ (または他のサードパーティ製ライブラリ) を採用する理由は何ですか? シンプル - コスト。
ここで、ZeroMQ がすでにすべての要件を満たしていると仮定しましょう。行う必要があるのは、それをビルドに統合し、ドキュメントを読んでから使用を開始することだけです。それはあなた自身を転がすよりもはるかに少ない労力でなければなりません. さらに、メンテナンスの負担は他社に移されました。ZeroMQ は無料なので、ZeroMQ チーム (の一部) を含めるように開発チームを成長させたようなものです。
ソフトウェア開発ビジネスを運営している場合、サードパーティのライブラリを使用するコスト/リスクと独自のライブラリを作成することのバランスを取ると思います。この場合、ZeroMQ を使用すると圧倒的に有利になります。
多くの開発者がそうであるように、あなた (またはあなたのパートナー) は、「Not Invented Here」症候群に悩まされているのではないでしょうか? もしそうなら、あなたの態度を調整し、ZeroMQ の使用を再評価してください。個人的には、誇らしげに他の場所で見つけたという態度の利点をはるかに好みます。ZeroMQ を見つけたことを誇りに思っています... 時間が教えてくれます。
編集: ZeroMQ を使用する理由について説明している、ZeroMQ 開発者によるこのビデオを見つけました。
独自のライブラリを作成するよりも優れている点は何ですか?
メッセージ キューイング システムはトランザクション型であり、概念的にはクライアントとして使用するのは簡単ですが、特に永続的なキューを考慮すると、実装者として正しく理解するのは困難です。簡単なメッセージング ライブラリを作成することで問題を解決できると考えるかもしれませんが、トランザクションと永続性がなければ、メッセージング システムのメリットを十分に享受することはできません。
このコンテキストでの永続性とは、サーバーがダウンした場合に備えて、メッセージング ミドルウェアが未処理のメッセージを (ディスク上の) 永続的なストレージに保持することを意味します。再起動後、メッセージは処理でき、再送信は必要ありません (送信者は問題があったことさえ知りません)。トランザクション対応とは、異なるキューからメッセージを読み取り、異なるキューにメッセージをトランザクション方式で書き込むことができることを意味します。つまり、すべての読み取りと書き込みが成功するか、(1 つ以上が失敗した場合) 何も成功しないことを意味します。これは、データベースとのインターフェースで知られているトランザクション性とあまり変わらず、同じ利点があります (エラー処理が簡素化されます。トランザクションがなければ、個々の読み取り/書き込みが成功することを保証する必要があり、1 つ以上が失敗した場合は、成功した変更をロールバックします)。
独自のライブラリを作成する前に、こちらの 0MQ ガイドをお読みください: http://zguide.zeromq.org/page:all
おそらく、RabbitMQ をインストールすることを決定するか、ZeroMQ がすべての難しい部分を既に行っているため、ZeroMQ の上にライブラリを作成することになります。
少し時間があれば、試してみて、独自の実装を展開してください! この演習で学んだことは、既にテスト済みのライブラリを使用することの賢明さを確信させるでしょう。