問題タブ [akka-cluster]

私は新しくリリースされた Akka.Net 1.0 (リリースおめでとうございます!) で遊んでいるので、私にとってはまったく新しいものですが、JVM Akka の経験がある人なら誰でも参加できると確信しています。質問。

大規模なシステム/アプリケーションの一部であるいくつか (例として 2 つ) の個別のサービスを考えてみましょう。これらのサービスは通常、独自の処理を行いますが、サービス間の呼び出しが必要になる場合があります。Service 2スタンドアロンにすることができ、GetStuffアクションがあるとしましょう。最初にアクションの結果を取得する必要がService 1あるアクションがあります。DoSomethingGetStuff

両方のサービスを別々に異なるマシンに展開できる場合、そのような状況を処理するための推奨される方法は何ですか?

私が言ったように、私は Akka についてあまり知りませんが、例、ドキュメント、およびソースを掘り下げると、2 つのオプションが見つかりました。

1. リモーティング。リモートホストRemotingから取得するために使用する独自のサービスでアクターシステムを分離します。ActorSelectionこれはRemoting docs exampleとほぼ同じですが、2 つのアクター システムが「クライアント」に等しいという点だけです。
2. クラスタリング。私はそれについて頭を悩ませようとしていますが、現在理解できることは、クラスターシステムをセットアップするだけの別のクラスターサービスをセットアップし、シードノードが適切に動作するように単純なリスナーアクターを作成することです。初期化（？）。次に、独自のサービスで作成されたすべての個別のアクター システムが、異なるロールの下で前述のクラスター システムに参加します。

私が気付いていない別の解決策があるかもしれません...？

個人的には、クラスタリング ソリューションは一見、把握してセットアップするのが難しいように見えますが、今は見えない大きな利点がいくつかあるのかもしれません。

繰り返しますが、このような状況に対処するための推奨される方法は何ですか?また、何に注意する必要がありますか?

Akka と Spray を使用して RESTful API を構築しています。Typesafe Akka Cluster Sample プロジェクトを使用しています...

( http://www.typesafe.com/activator/template/akka-sample-cluster-scala )

参考までに。ルートのプールとクラスター対応ルーティングを使用するクラスターがあります。API へのインターフェイスは、クラスターのフロントエンドとして機能し、クラスターのアクティビティ (新しいノード、ダウンしたノードなど) を監視するアクター (ClusterClient) を作成するスプレー フロントエンドを介して行われます。スプレー ルートにリクエストが届くと、クラスター対応ルーターを介してクラスター バックエンド ワーカーに作業を委任します。

ここでの私の希望/目標は、必要に応じてバックエンド ワーカー ノードとルートを追加することで、システムのパフォーマンスを向上できることです。また、ロード バランサー経由でアクセスされるフロントエンド (スプレー) ノードを追加することもできます。パフォーマンスとスケーラブルなものを構築しようとしています。

これはすべてうまくいきます。現時点では、ワーカー アクターはテスト用の文字列を返すだけです。

先に進む前に、アプリケーションのストレス テストを行って、現在のクラスターのパフォーマンスを把握したいと思いました。だから私はいくつかの簡単なテストを行うために apache ベンチを使用しています。

すべてのテストは、私のローカル開発マシン (16 GB RAM を搭載した QuadCore Macbook Pro) で行われています。アプリケーションはスプレー缶で実行されています。フロントエンド (スプレー) とバックエンド ノードは、異なるポートを使用して、同じマシン上の個別の JVM で開始されています。

奇妙なことに、クラスターにバックエンド ノードを追加すると、パフォーマンスが低下するように見えます。これが私のテストと結果です。より良い平均を得るために、各テストを約10回実行しました...

1 つのバックエンド ノード

2 つのバックエンド ノード

3 つのバックエンド ノード

これは期待されていますか？つまり、バックエンド/ワーカー ノードを追加することでパフォーマンスを向上させるべきだと考えるのは間違っていますか? 上記の数値に基づくと、クラスターに追加するノードが増えるほど、パフォーマンスが低下します。これは、同じマシンでテストを実行する際の問題でしょうか?

ありがとう

1 つのアクターから複数のアクターに akka-cluster で約 200MB のサイズの大きなメッセージを送信する必要があります。akka メッセージを使用してみましたが、時間がかかるためタイムアウトします。

これを実装する最良の方法は何ですか? このようなタスクには Akka IO を使用する必要があるとどこかで読んだことがありますが、使用方法に関する十分なドキュメントが見つかりませんでした。

Play をフロントエンドとして、akka クラスターをバックエンドとしてアプリを構築しています。現在、両方とも同じ sbt プロジェクトの下にあります。sbt の "dist" では、再生を開始するスクリプトと akka クラスターを含む .zip パッケージを 1 つしか取得できませんでした。したがって、それぞれを簡単にデプロイできるように、Play 用、akka クラスター用などの複数のパッケージを生成する方法があるのではないかと考えています。または、この種のプロジェクトに推奨されるグッド プラクティスはありますか?

私は Akka を初めて使用し、多くのリモート ノードを持つクラスター システムを構築しています。リモート ノードはワーカーと呼ばれます。ワーカーは、リモート ルーターのチェーンを作成します。

ルーターを作成する親 (ワーカー) には、ルーターのすべてのルートからメッセージを取得する統計ウォッチャーがあります。

qn is : Is は、ルーターのコンストラクター引数としてルーターを作成するときに statswatcher actorRef を渡すか、単に statswatcher のアクター パスをコンストラクター引数として渡し、メッセージを伝えるためにルーターでユーザー アクターの選択を渡すことをお勧めします。

**************** アップデート ********

akka メーリング グループからの返信によると、アクター ref をコンストラクター引数として渡すことは悪い習慣ではありません。アクター選択は、リモート アクター ルックアップに役立ちます。

Akka のドキュメントで、クラスター シングルトンを使用する場合は自動停止の使用を避けるべきであると読みました。その場合、ダウンをどのように構成する必要があるかわかりません。クラスター メンバーシップ イベントにサブスクライブし、それらのメッセージに従って戦略を計画できることを理解しています。ただ、オートダウンとの実質的な違いはよくわかりません。

ノードがクラスターから何らかの形で分割されている場合、自動ダウンが使用されている場合、分割されたノードはクラスター全体が失われたと「考え」、独自のクラスターを (独自のシングルトンで) 開始します。しかし一方で、クラスターが収束に達しない (新しいノードが参加できない) ため、到達不能ノードを到達不能状態に永遠に保つことはできず、分割されたノードがシングルトン自体である場合は新しいシングルトン ノードになります。割り当てられないため、私の理解によれば、残された唯一のことは、一定の猶予時間の後に到達不能なノードを削除することです。これは、まさに自動ダウンが行うことです。

ここで何が恋しいですか？

ClusterSystemという名前の AKKA クラスター システムがあります。このクラスターの各ノードには、アクターActorAがあります。アクターに送信されたメッセージを、クラスター内で実行されているすべてのActoraAにブロードキャストする方法が必要です。

誰かがJavaで例を投稿できれば、非常に役立ちます。