AkkaでActors vs. Remote Actorsはどのように使うべきですか？ローカルとリモートのアクターをいつ使用するのですか？
私は両方ともマシンをスケールアップすることができますが、リモートアクタだけがスケールアウトすることができると理解しています。
リモートアクタの初期セットアップオーバーヘッドがわずかで、通常のアクタのオーバーヘッドに大きなオーバーヘッドがない場合は、リモートアクタを使用すると標準となります出かける生産コードをスケールアウトする必要がない場合でも、オプションを持たせるといいでしょう（荷物が付いていない場合）。
俳優対リモート俳優をいつ使用するかについての洞察は非常に高く評価されます。
リモートアクタはスケールアップできません。リモートアクタは他のマシンのローカルアクタへのリモート参照のみです。
Akka 2.0では、クラスターアクターを導入します。これにより、Akkaアプリケーションを作成し、configのみを使用してスケールアップすることができます。
ローカルアクタは、ローカルプロジェクトでメッセージを送信するときに使用できます。 リモートアクターに関しては、メッセージを送信しているプロジェクトに接続されている依存プロジェクトにメッセージを送信する際に、リモートアクターを使用することができます。
リモートアッカ俳優についてはこちらを参照してください質問は、リモート俳優がわずかな初期セットアップのオーバーヘッドを持っており、任意の他の主要なオーバーヘッドを持っていない場合は、私が使用していることを思うだろう」尋ねます遠隔俳優が標準となります。しかし、Fallacies of distributed computingは、どの技術でもリモート処理にオーバーヘッドがないと仮定することは設計上の誤りであるという点を指摘しています。メッセージをバイトにコピーし、ネットワークインターフェイスを介して送信するオーバーヘッドがあります。また、異なるプロセスの複雑さはすべて、停止、停止、到達不能で、ネットワークには、紛失、複製、並べ替えの原因となっています。
This great articleは、リモートで弾丸を作るのが難しい奇妙なネットワークエラーの実例があります。彼のfree video course about akkaのAkkaプロジェクトのリードRoland Kulnは、1Tのネットワークメッセージが送信されるたびに、彼は腐敗を経験していると言います。 Notes on Distributed Systems for Young Bloodsは、 "分散システムでは実際の、シミュレートされていないバグを流すための配布が必要な傾向がある"と言います。そのため、単体テストでも完璧なシステムにはなりません。リモーティングは「フリー」ではなく、完璧なものになるというアドバイスがたくさんあります。
可用性のためにリモーティングを使用する必要がある場合、または巨大スケールに移動する必要がある場合は、akkaはat-least-onceの可能な複製で配信します。したがって、重複したメッセージが悪い結果をもたらさないようにする必要があります。
リモーティングの使用を開始する瞬間には、Distributed systems for fun and profitで議論されている課題を作成する分散システムがあります。非常に単純に、ステートレスな電卓のように重複したメッセージに冪等があるようなことをしない限り、物事は厄介です。上のリンクのakkaビデオコースの課題の1つは、自分でロジックを書くことによって失われたメッセージを処理できる複製されたキーバリューストアを作ることです。それは簡単な割り当てではありません。異なるプロセス間で分散された状態は非常に困難になり、アクターは状態をカプセル化します。したがって、構築しているシステムの整合性と可用性の要件に応じて、アクターを分散することは非常に困難になります。
これはすべて、リモート処理を避け、達成する必要があるものを達成できれば、回避することをお勧めします。あなたがリモーティングが必要な場合、Akkaはそのlocation transparencyのために簡単にします。だからあなたの仕事であなたと一緒に取るべき素晴らしいツールボックスです。ジョブがすべてのツールを必要としているか、またはボックス内の最も単純なツールだけを必要としているかを再度確認する必要があります。