問題タブ [akka-cluster]

私は、scala と Akka で書かれた Minecraft サーバーであるはずの bc 論文プロジェクトに取り組んでいます。サーバーは、クラウドまたはクラスターに簡単に展開できる必要があります (適切な用語を使用するかどうかはわかりません...複数のノードで実行する必要があります)。しかし、私はakkaの初心者であり、そのようなことをどのように実装するのか疑問に思っていました. 私が今理解しようとしている問題は、異なるノードのアクター間で状態を共有する方法です。私の最初のアイデアは、Minecraft クライアントから tcp ストリームを読み取り、それをロード バランサーに送信して、リクエストを処理するノードを選択し、tcp 経由でクライアントに応答を送信する Camel アクターを用意することでした。ユーザーによって提供された資格情報が有効かどうかをチェックする AuthenticationService 実装アクターがあるとしましょう。すべてのノードにはそのようなアクター (またはおそらくそれ以上) があり、すべてのアクターは常にユーザーのまったく同じデータベース (または状態) を持つ必要があります。私の質問は、この状態を維持するための最良のアプローチは何ですか? 考えられるいくつかの解決策を思いつきましたが、このようなことは何もしていないので、欠点を指摘してください:

解決策 #1: データベースに状態を保持します。これは、状態がユーザー名とパスワードのリストなどによってのみ表されるこの認証の例ではおそらく非常にうまく機能しますが、状態に整数や文字列に簡単に分割できないオブジェクトが含まれている場合はおそらく機能しません。

解決策 #2: 特定のアクターに状態を変更するリクエストがあるたびに、アクターはリクエストを処理した後、同じタイプの他のすべてのアクターに変更に関する情報をブロードキャストします。元のアクターによって送信された情報。これは非常に非効率的で、かなりぎこちないようです。

解決策 #3: 特定のノードを一種の状態ノードとして機能させ、サーバー全体の状態を表すアクターを配置します。そのようなノードのアクターを除く他のアクターは状態を持たず、データが必要になるたびに「状態ノード」のアクターに問い合わせます。これも非効率的で、一種のフォールト・ノンプルーフのようです。

それで、あなたはそれを持っています。私が実際に気に入っている唯一の解決策は最初の解決策ですが、私が言ったように、おそらく非常に限られた問題のサブセットでのみ機能します (状態を redis 構造に分割できる場合)。より経験豊富な教祖からの応答は非常に高く評価されます。よろしく、トーマス・ハーマン

2.0-SNAPSHOT Akka クラスター機能をテストすることにかなり興味がありますが、私の目的のためにこれを Java で実行したいと考えています。

ここで例を読みました: http://letitcrash.posterous.com/clustered-actors-with-cloudy-akka

しかし、API は十分に変更されているようで (Cluster.startLocalCluster() はもう存在しませんか?)、ドキュメントは (予想されるように) 十分にまばらであるため、私のいじくり回しは非常に遅くなります。

Java で Akka クラスタリングを介していくつかのローカル ノードを立ち上げる小さなサンプル アプリケーションを知っている人はいますか?

どうもありがとう。

私は最近、Akka とアクターベースのシステムの概念に頭を悩ませようとしています。Akka の基礎についてはかなりよく理解できましたが、クラスタリングとリモート アクターに関してはまだいくつか苦労しています。

Play Framework 2.0 に付属する WebSocket チャットの例を使用して、この問題を説明しようとします。WebSocket を保持し、現在接続しているユーザーのリストを保持するアクターがあります。アクターは基本的に、技術的にも論理的にもチャット ルームを表します。これは、単一のサーバーで単一のチャット ルームが実行されている限り、問題なく機能します。

ここで、サーバーのクラスター (単一ノードが追加または削除された状態) で実行されている多くの動的チャット ルーム (新しいルームはいつでも開閉できる) について話しているときに、この例をどのように拡張する必要があるかを理解しようとしています。現在の需要による）。このような場合、ユーザー A はサーバー 1 に接続し、ユーザー B はサーバー 2 に接続できます。両方が同じチャット ルームで話している可能性があります。各サーバーには、イベント (メッセージ) を受信して​​適切なユーザーに公開する WebSocket インスタンスを保持するアクター (チャット ルームごと?) が引き続き存在します。しかし、論理的には、サーバー 1 またはサーバー 2 のいずれかに、現在接続しているユーザー (または同様のタスク) のリストを保持するチャット ルーム アクターは 1 つだけ存在する必要があります。

できれば「純粋な akka」で、ZeroMQ や RabbitMQ などの追加のメッセージング システムを追加せずに、これをどのように達成しますか?

これは私がこれまでに思いついたものです。これが意味をなすかどうか教えてください:

1. ユーザー A がサーバー 1 に接続し、彼の WebSocket を保持するアクターが割り当てられます。
2. アクターは、アクティブなチャット ルームの「チャット ルーム アクター」が接続されたクラスター ノードのいずれかに存在するかどうかを (Router? EventBus? 何か他のものを使用して?) チェックします。そうではないので、何らかの方法で新しいチャット ルーム アクターの作成を要求し、このアクターとの間で将来のチャット メッセージを送受信します。
3. ユーザー B はサーバー 2 に接続し、彼の WebSocket にもアクターが割り当てられます。
4. また、要求されたチャット ルームのアクターがどこかに存在するかどうかを確認し、サーバー 1 で見つけます。
5. サーバー 1 のチャット ルーム アクターは、指定されたチャット ルームのハブとして機能し、すべての「接続された」チャット メンバー アクターにメッセージを送信し、受信したアクターを配布します。

サーバー 2 がダウンした場合、チャット ルーム アクターをサーバー 2 で再作成するか、サーバー 2 に移動する必要がありますが、これは現在の私の主な関心事ではありません。アクターのこの動的な発見が、Akka のツールセットを使用して、さまざまな基本的に独立したマシンにどのように広まったかについて、私は最も疑問に思っています。

私はかなり長い間 Akka のドキュメントを見てきました。もしそうなら、私に教えてください:-)

私は Java/scala akka の概念実証を書いていますが、現在、クラスター環境でのアクターの概念をいじっています。

仕様

システムが同じメッセージを複数のノードに送信する特定の状況があります。私の仕事は、これらのメッセージをドロップせず、1 つのメッセージだけをバックエンド システムに渡すことです。負荷分散/フェイルオーバー機能を備えた独自のフィルターのように。

考え

私は 2 つのノードで 2 つの「フロントエンド」アクターを使用することを考えていました。システムは、バックエンドに送信するフロントエンド アクターに送信するフロントエンド ルーター (ラウンド ロビンとしましょう) にメッセージを送信します。

もう 1 つのフォールバック ソリューションは、リーダーだけがバックエンドに送信するシステムを使用することです。このシステムでは、全員が同じメッセージを受け取り、リーダーだけがそれを転送します。

問題

私が直面している問題 (コードを参照) は、ルーターが既存のフロントエンド アクターをクラスターのルートとして使用することです。これは、サンプル コードでは失敗します。これは、ルーターがroutees-path (config 設定) によってルートをローカルでのみ検索し、何も見つからずに終了するためです。

ルーターがクラスターノードにルートを展開する構成でも成功していません。常にローカルに展開します。

ここにサンプルコードがありますhttp://ge.tt/2UHUqoQ/v/0?c。2 つのエントリ ポイントがあります * TransformationSample.App2 - コマンドライン パラメータ 2551 と 2552 をそれぞれ使用して 2 つのインスタンスを実行します (シード ノード) * TransformationSample.App1 - コマンドライン パラメータを使用せずに 1 つのインスタンスを実行します

App1 は、ルーターを作成して通信しようとするものですが、フロントエンド ルーターをローカルで見つけることができないため、ルーターは終了します。問題は akka.cluster.routing.ClusterRouteeProvider クラスの createRoutees メソッドの行 178 https://github.com/akka/akka/blob/releasing-2.1.0-RC1/akka-cluster/src/main/scalaに固定されています/akka/cluster/routing/ClusterRouterConfig.scala .

最後に

私はおそらくここで何か間違ったことをしているので、私の scala を許してください (これは私が書いている最初のプロジェクトです)。

このルーターが機能することを望んでいる理由は、概念実証の次のステップは、フロントエンド アクターが送信する (別の) バックエンド クラスター ルーターと通信する同様の設定でバックエンド システムの負荷を分散することであるためです。バックエンド アクターに対してラウンド ロビンで動作します。

これはオーバーエンジニアリングですか？フロント部分のフェイルオーバーとバック部分の負荷分散が必要です。

のINFOメッセージは何ですか

in a Akka cluster とはどういう意味ですか? ドキュメントに何も見つからないようです。テスト マシンでアクターを使用して多数の JVM を実行すると、これがかなり見られますが、何らかの Akka または Linux のチューニングが必要な悪い兆候であるかどうかはわかりません。

Oracle JDK 1.7 上の Akka 2.1.4

更新: @cmbaxter のアドバイスに従って、ハートビートを調整するためのオプションを調査しました。ハートビートに関連付けられたタイミングを増減しても、「ハートベスト接続の削除」メッセージの存在に影響がないことがわかりました。ただし、「monitored-by-nr-of-members」構成設定に気付きました。メッセージは、特定のノードからのハートビートの監視が、ある ActorSystem から別の ActorSystem に渡されていることを示していると思います。したがって、それらは現在のシステムが、接続に関する警告を示すのではなく、もはやそれ自体の責任ではないと単に述べていることを示しています。実際、システムの起動時に、最初のノードは大量の「最初のハートビート」を受け取りますが、「monitored-by-nr-of-members」設定に従って、それらのほとんどを削除します。

多くのマシンにデプロイする akka アプリケーションがあります。これらの各アプリケーションが、分散パブリッシュ/サブスクライブ イベント バス機能を使用して相互に通信できるようにしたいと考えています。

ただし、クラスタリング用にシステムをセットアップすると、あるアプリケーションのアクターが、開始したノードとは別のノードに作成されるのではないかと心配です。

アクターは、それが属するアプリケーションが起動されたマシン上でのみ作成されることが非常に重要です。

基本的に、アクターの弾力性やクラスタリングは必要ありません。分散型のパブ/サブが必要なだけです。ここで言及されているシングルトンやロールなどのオプションを見ることができますhttp://letitcrash.com/tagged/spotlight22が、これを行うための推奨される方法は何だろうと思いました。

1 台の PC で複数の akka ノードを実行するにはどうすればよいですか? 現在、私は自分のapplication.confファイルをフォローしています。システムごとに異なるポート番号を追加しましたが、複数のインスタンスを開始できません。エラーは、Address already in use failed to bind.

application.confファイル

更新:複数のakkaノードは、akkaを使用してリモートマスターノードと通信するさまざまなスタンドアロンサーバーアプリケーションを持っていることを意味します。