問題タブ [distributed-system]

ホイ、

分散システムでメッセージを使用しますが、メッセージとはどういう意味ですか?

UDP はメッセージを使用すると言えますが、HTTP は使用しません。理由を教えてください。

どうもありがとう

私はMicrosoftAzureについて学んでいます。私にとっては目新しいものではありませんが、データベースシャーディング、非正規化、nosql、コンテンツ配信ネットワーク、分散キャッシュ（ memcacheのように）、非同期処理、分割システム、負荷分散など...など...

テクニックよりもアプローチについての本を探しています。

問題は、AzureStorageの使用方法やAzureCDNの使用方法について多くのことを読むことができるということですが、正しいアプローチがないと、期待したほど良い結果が得られません。

前もって感謝します。

私は契約に足を踏み入れており、今日、請負業者のポジションについての最初のラウンドの面接を受けました。私は合格しましたが、主にUI開発者であると言われましたが、バックエンドに必要なものの基本のみを取り上げたので、第2ラウンドの前に分散システムについて読む必要があります。

これまでの私のキャリアでは、リアルタイムが必要とされなかったポストオペレーションで働いてきました。あと数日しか残っていないので、カバーする必要のある重要なトピックは何ですか？最初に彼の質問に答えることができ、一般的に分散システムではほぼ適切であると見なされていますか？

問題は、UIにほぼリアルタイムでデータを表示する方法でしたか？バックエンドで何をする必要がありますか？リアルタイムデータフィードのプロデューサー/コンシューマーパターンについて説明しました。彼はそれが好きだったが、彼は2回目のインタビューでもっと必要だと言った。

どんな助けでも本当にありがたいです、

両者の根本的な違いを思いつくことはできません。私は例しか思いつきませんでした：

• BitTorrent は分散 p2p システムですが、ToR は分散型です。
• Web サービスは分散化されていますが、分散型の Web サービスは考えられません。（もしかしてディアスポラ？）

ワーカープロセスを分散させるアプリケーションを作成する予定です。それらの1つは、他のプロセスにタスクを割り当てるリーダーになります。リーダー選出プロセスの設計は非常に簡単です。各プロセスは、同じパスにエフェメラルノードを作成しようとします。成功した人は誰でもリーダーになります。

さて、私の質問は、タスクを均等に分散するプロセスをどのように設計するかです。このためのレシピはありますか？

環境設定について少し詳しく説明します。

10人の労働者の機械があり、それぞれがプロセスを実行し、そのうちの1つがリーダーになるとします。タスクはキューに送信され、リーダーはそれらを取得してワーカーに割り当てます。タスクが送信されるたびに、ワーカープロセスに通知が送信されます。

私は私の友人と、信頼できるマルチキャストライブラリを実装するためのシステムを使用しています。私たちはグループに属する多くのプロセスを扱っています。どのプロセスもグループに参加またはグループから脱退できます。1つがメッセージを送信すると、これは他のすべてによって配信されます。

送信者のクラッシュを処理して、これが発生したときに、すべての受信者がメッセージを配信するか、まったく受信者がメッセージを配信しないようにします。

すべてまたは何もない部分を処理するための優れた戦略（アルゴリズム）を提案できますか？

RMI が Java でどのように機能するかを学習しようとしています (RMI の完全な初心者)。2 つの数値を加算する方法を示すいくつかの例を見てきました。問題は、私が常に netbeans を使用しており (そして引き続き使用したい)、すべての例がコマンド ラインからの Java であることです。netbeans からこのような小さなアプリケーションを実行する方法を知っている人はいますか? (私はビルド 6 を使用しています) よろしくお願いします :) 私が見ているチュートリアルは次のとおりです。 .html

リレーショナル データベースでよく知られているように、トランザクション性の欠如に対処する方法を示す NoSQL アプリの良い例を探しています。ほとんどが読み取り専用のコードの場合、これははるかに簡単な作業であるため、私は主に書き込み集中型のコードに興味があります。NoSQL全般、CAP定理、結果整合性などについて多くのことを読んだことがありますが、それらはデータベースアーキテクチャ自体に集中する傾向があり、それで使用する設計パターンには集中しません。分散アプリ内で完全なトランザクション性を達成することは不可能であることは理解しています。これがまさに、タスクを実行可能にするために、どこでどのように要件を下げる必要があるかを理解したい理由です。

編集：

結果整合性がそれ自体の私の目標であるというわけではありません。今のところ、書き込みが集中する特定の処理に NoSQL を使用する方法がわかりません。説明: オファーがある単純なオークション システムを使用しています。理論的には、オファーを最初に受け入れた人が勝ちます。実際には、勝者が 1 人だけであることと、人々が同じリクエストで結果を取得できることを少なくとも保証したいと思います。おそらく実現不可能です。しかし、実際にそれを解決する方法 - 何かがうまくいかなかったために、リクエストによっては通常よりも時間がかかる場合があります。おそらく、一部のリクエストは自動的に更新されるはずです。これはほんの一例です。

ハブ アンド スポーク トポロジを持つ分散システムを構築しています。低帯域幅 (~10Mbps) WAN 接続で、中央オフィスと中央オフィスに接続されたリモート サイトです。

システムは、どのサイトでも更新できるデータを管理しており、システム全体で複製する必要もあります。

システムは、ネットワークから切断されたときの作業をサポートする必要があります。ネットワークが再接続されると、データが再び同期されます。

データの管理に NoSQL DB の使用を検討しています。しかし、私たちは多くの異なる選択肢に少し圧倒されています.

フィッティング ソリューションに関する提案をお待ちしております。

アプリケーションサーバーがあります。大まかに言うと、このアプリケーション サーバーにはユーザーとグループがあります。ユーザーは 1 つ以上のグループの一部であり、サーバーはすべてのユーザーに自分のグループとグループ内の他のユーザーの状態を認識させます。主な機能は次の 3 つです。

• ユーザーとそのグループに関連するメタデータの更新とブロードキャスト。たとえば、ユーザーがログインすると、サーバーはこのユーザーのステータスを更新し、このユーザーのグループ内のすべてのオンライン ユーザーにブロードキャストします。
• 2 人以上のユーザー間でプロキシとして機能する。クライアントはピアツーピア転送を利用しますが、2 人のユーザーが互いに直接接続できない場合、サーバーはそれらの間のプロキシとして機能します。
• オフライン ユーザーのデータを保存します。クライアントがオンラインでないユーザーにデータを送信する必要がある場合、サーバーはそのデータを一定期間保存し、次にユーザーがオンラインになったときに送信します。

このアプリケーションを変更して、すべてが同じローカル ネットワーク上にあるとは限らず、複数のサーバーに分散できるようにしようとしています。ただし、古いクライアントとの下位互換性が失われないようにする必要があります。基本的に、配布はクライアントに対して透過的である必要があります。

私が抱えている最大の問題は、Server Aに接続しているユーザーがServer Bのユーザーにブロードキャストする必要がある更新を行う場合の処理​​です。

さらに大きな問題は、サーバー Aのユーザーがサーバーをサーバー Bのユーザーとの間のプロキシとして機能させる必要がある場合です。

私の最初のアイデアは、どのユーザーと通信する必要があるかを考慮に入れるアルゴリズムを使用して、各ユーザーに優先サーバーを割り当てようとすることでした。これにより、他のサーバー上のユーザーと通信する必要があるユーザーの数を減らすことができます。

ただし、これは異なるサーバー上のユーザーが通信する必要がある頻度を最小限に抑えるだけです。異なるサーバー上のユーザー間の通信を実現するという問題がまだあります。

これに対して私が思いつく唯一の解決策は、別のサーバーに接続しているユーザーに対処する必要があるときに、サーバーを相互に接続することです。

たとえば、サーバー A に接続していて、サーバー Bに接続している別のユーザーとのプロキシが必要な場合、サーバー Aにこのユーザーへのプロキシ接続を要求します。サーバー Aは、他のユーザーがサーバー Bに接続していることを認識し、サーバー B への「リレー」接続を確立します。この接続は、私の要求をサーバー Bに転送し、応答を私に転送するだけです。

これに伴う問題は、すでに非常に高い帯域幅の使用量が増加することです。残念ながら、他の解決策は見当たりません。

この問題に対するよく知られた、またはより良い解決策はありますか? 分散システムが異なるサーバー上のユーザー間の通信を必要とすることはあまり一般的ではないようです。