akka / erlangでアクターを使用するのが良くないのはいつですか？

私はakkaで毎日7〜8か月働いています。私が始めたとき、私はアプリケーションに取り組んでおり、ほとんどのオブジェクト間で通信するために、アクターは基本的にアクターシステム内のどこででも使用されることに気付きました。だから私は同じことをした-x / y / zの別のアクターをスピンアップする。

これはあまりにも無差別で、必要のないところに複雑さを加えているように思えます-しかし、アクターとプレーンを介した同期、または先物を介した非同期ロジックを使用する必要がある場所についての議論は見つかりません。同僚が似たようなことを言った後、私は自分のスタンスを熟考し始めました。最近、タスクを熟考し、不変の実装で同じ結果を安全に達成できるため、別のアクターの作成を避けたいくつかのケースを実現しました。たとえば、非常に頻繁にアクセスするデータベースまたはファイルから設定値を取得するようなものです結果を待つのが実際のユースケースです。

特に、不変の状態で遊んでいる場合、アクターは複雑さを生み出し、スループットを制限します。たとえば、オブジェクトの純粋な関数は、並行性のレベルを問わず、リスクなしで同時に呼び出すことができます。アクターは一度に1つのメッセージしか処理できません。別の考慮事項は、futureの使用を開始しない限り、結果を待つ必要がある場合にスレッドを保留することですが、非同期メッセージングやスケールを心配する必要がない場合は、アクターを採用するのはやり過ぎかもしれません。

だから私の質問は-俳優を使用するのに悪い時間はありますか？アーランがどのように見えるのか興味があり、他の人の洞察が本当に欲しいです。または、アクターの使用に関するいくつかの原則がある場合。

これは私が興味を持っている質問であり、私はいくつかの研究を行ってきました。他の視点については、Noel Walshによるこのブログ投稿またはStack Overflowに関するこの質問を参照してください。私が提供したい意見があります：

• Akkaはメッセージを処理するため、「プッシュマインドセット」を促進すると思います。多くの場合、並行性のために、これはあなたが望むものではないと主張します。プルははるかに安全です。たとえば、分散システムの一般的なパターンの1つは、キュー内の情報を処理するワーカーのセットです。Akkaでこれが可能であることは明らかですが、人々が試みる最初のアプローチであるとは限りません。Akkaは耐久性のあるメールボックスも提供しますが、その使用方法によって異なります。単一の共有キューは、作業の分散/再割り当てのためにワーカーキューごとよりもはるかに柔軟です。
• クラスをアクターに置き換えるという考え方に簡単に入ります。実際、一部の人々は、俳優はただ一つのことをするべきだと言って、それを主張しているようです。すべてのクラスがアクターである場合、それは多くの余分なメッセージと受信/送信ブロックであるため、Jasonが説明するように、これは論理的な結論に達すると、コードの複雑さが増します。また、インターフェイスの形式が失われるため、コードの理解とテストが難しくなります。コメントがこれの解決策であるとは確信していません。また、Akkaの伝説的な効率性にもかかわらず、アクターの増殖はパフォーマンス上賢明なアイデアではないと思います。Javaスレッドを使用する場合、それらは貴重であり、それに応じて保存されることがわかります。
• これは前のポイントに関連していますが、もう1つの面倒な点は、NoelとPinoが強調している型情報の損失です。これにはいくつかの方法がありますが、それらは非標準、推奨されていない、または実験的なものです。
• 最後に、「クラッシュさせる」という考え方があったとしても、並行性は困難です。代替のプログラミングモデルは役立ちますが、問題を解決することはありません-それらを変更します- それが正式にそれらについて考えるのが良い理由です。また、Joe Averageの開発者がRabbitMQ、Storm、Hadoop、Spark、Kafka、NoSQLデータベースなどの既製のツールに手を伸ばす理由でもあります。Akkaにはあらかじめ構築されたツールとコンポーネントがありますが、それは非常に低レベルであると感じられるため、分散システムの一般的な要素をより簡単に構築することで、開発者はシステムを正しく構築できます。

ジェイソンのように、私はここで他の人の洞察を聞きたいです。上記の問題のいくつかに対処し、Akkaをよりよく使用するにはどうすればよいですか？

アクターモデルの用途を検討する価値があります。アクターモデルは

1. 並行性モデル
2. 可変状態への同時アクセスを回避します
3. 非同期通信メカニズムを使用して並行性を提供します。

特に、同期状態を維持する必要がある共有状態の異なるコンポーネント間に関係がある場合、複数のスレッドから共有状態を使用することは非常に難しくなるため、これは有益です。ただし、次のドメインコンポーネントがある場合：

• 並行性を許可しない、または
• 可変状態（関数型プログラミングなど）を許可しない、または
• 同期通信メカニズムに依存する必要がありますが、

その場合、アクターモデルは（もしあれば）多くの利点を提供しません。

お役に立てば幸いです。

あなたの直感は正しいです、私見。どこでも俳優を使用することは、ことわざのハンマーを持って釘だけを見るようなものです。

Erlangのベストプラクティスは、同時に発生するすべてのアクティビティにプロセス/アクターを使用することです。つまり、実際の生活と同じです。適切な粒度を見つけるのが難しい場合もありますが、ほとんどの場合、モデル化されたドメインを見て、少し常識を使って知るだけです。私はそれよりも良い方法はないのではないかと心配していますが、それが役立つことを願っています。

入出力メッセージの順序：

私は最近、アクターモデルが実際に同時実行の問題を引き起こしたakkaベースのアプリケーションに出会いました。負荷がかかった場合は、より単純なモデルで十分でした。

問題は、着信メッセージが（異なるアクターパスを介して）異なる「レーン」で移動しているが、コードは、メッセージが到着した順序と同じ順序で最終宛先に到着すると想定したことです。データが十分に長い間隔で到着する限り、これは機能します。これは、宛先に競合する競合するメッセージが1つしかないためです。間隔が短くなったとき、彼らは順不同で到着し始め、奇妙な行動を引き起こしました。

問題は少し少ないアクターで正しく解決できたかもしれませんが、それらを使いすぎた場合に犯すのは簡単な間違いです。

私の意見では、アクターには2つのユースケースがあります。ポートなどの共有リソース、および大規模な状態。最初のものはこれまでの議論で十分にカバーされてきましたが、大きな状態も正当な理由です。

すべてのプロシージャ呼び出しで渡される大きな構造体は、多くのスタックを使用できます。この状態を別のプロセスに入れ、構造をプロセスIDに置き換え、そのプロセスを必要に応じて照会できます。

mnesiaなどのデータベースは、クエリプロセスの外部に状態を保存していると考えることができます。