Akkaが同時実行性に優れているのはなぜですか？
私はアッカと俳優のフレームワークに不慣れです-明らかな何かが欠けていると確信しています。事前に謝罪を受け入れてください。
Akkaを選択する際の主なポイントの1つは、同時実行性を管理する方法であることを私は読み続けています。
Akkaがなぜ特別なのかははっきりしません。私は非常に軽くて速い小さな俳優がたくさんいることを理解しています。ただし、2人のユーザーが同時にフォームを保存するときに、これはどのように役立ちますか？
なんらかの並行処理ロック（悲観的/楽観的/その他）はまだ必要ではないでしょうか？
アクターやエージェントなどのメッセージ処理モデルの利点の1つは、従来の同時実行の問題（主に共有状態の同期）が問題ではなくなったことです。アクターはプライベートな状態を保持し、ロックなしで自由に更新できます。アクターフレームワークは、一度に1つのメッセージのみが処理されるようにします。シリアライズされた処理により、コードはロックフリーの方法で記述できます。
ユーザーがフォームを保存する例では、アクターが各フォームからのデータのリストを保持していると想定すると、フレームワークは一度に1つのフォームのみが処理されることを保証するため、アクターはロックなしでリストを更新できます。従来は、リストアクセスをロックするか、同時リストを使用する必要がありました。
並行性戦略は少し異なる問題であり、依然として責任があります（最も一般的な戦略は戦略ではありません）。例を少し変更するために、両方のユーザーが同じフォームインスタンスを同時に更新しようとしているとしましょう。並行性戦略がないと、一方の変更が他方を上書きします（おそらく最後の方が勝つでしょう）。それは問題ありませんが、せいぜいこれにより、変更が上書きされたユーザーに予期しない動作が発生します。変更したばかりのフォームを表示すると、（他のユーザーからの）予期しない値になります。最悪の場合（フォームの更新だけでなく、注文の発送などについても）、さまざまな種類（時間、収益など）の損失が発生する可能性があります。
同時方式を使用すると、これらのケースを識別し、ビジネスルールに基づいてそれらを解決できるようになります。たとえば、Optimistic Concurrencyは、更新しているフォームのバージョンをユーザーに送信させます。アクターが変更を処理しようとすると、最初のユーザーの更新により、フォームが実際にバージョン6であるときに、2番目のユーザーがバージョン5を更新していると考えていることに気付きます。これで、少なくとも2人目のユーザーに、フォームの編集を開始してからフォームが既に変更されていることを通知できます。あるいは、企業がそこで施行したい規則は何でも。
フォームを更新する場合は、おそらく同時実行性についてそれほど気にする必要はありません（おそらく、私は推測します）。しかし、他の場合では、少なくとも違反をチェックして処理できることが非常に重要な場合があります。ユーザーが別のセクションを変更した場合（フォームの類推を続けるため）など、同時実行違反を無視することもできます。または、変更がビジネスに大きな影響を与える場合（大きな注文）、それを受け入れて、後で小さな競合を解決する必要があります（たとえば、毎年の連絡先情報の更新が完了していません）。
Akkaには、障害の処理方法や監督者など、開発者にとって重要な考慮事項である他の多くの側面があると思います。
古典的なロックベースの同時実行性やきちんとしたトランザクションメモリなどの他の同時実行性モデルと比較して、アクターモデル（Akkaだけでなく）全般について書きます。
利点
理解と使用が容易なコンセプト
ロックベースの同時実行は困難です。ロック、セマフォ、スレッド、同期、相互排除、メモリバリアなど、正確かつ効率的になるために理解して使用する多くの概念があるため、これを正しく理解することは特に困難です。
一方、アクターはより抽象的な概念です。メッセージを送受信するアクターがあります。記憶障壁などの低レベルの概念を把握して使用する必要はありません。
不変性を強制する
- 可変性は、プログラミング、特にマルチスレッドアプリケーションでの多くのエラーやバグの原因です。アクターモデルは、不変性を適用することでこの問題を解決します。
エラーが発生しにくい
- 上記の2つの理由により
効率的
- 優れた書き込みロックベースほど効率的ではありませんが、一般にソフトウェアトランザクションメモリよりも効率的です。
簡単に拡張可能
- 少なくとも理論的には、アプリケーションは、より多くのアクターを追加してジョブを実行することにより、かなり適切にスケーリングする必要があります。ロックベースでは、スケーリングがかなり困難です。
短所
すべての言語が簡単に不変性を強制するわけではありません。
- 最初にアクターを普及させた言語であるErlangは、その核心に不変性がありますが、JavaおよびScala（実際にはJVM））は不変性を強制しません。
まだかなり複雑
- アクターはプログラミングの非同期モデルに基づいていますが、これはそれほど単純ではなく、すべてのシナリオで簡単にモデル化できません。エラーや障害のシナリオを処理することは特に困難です。
デッドロックや飢餓を防止しない
- 2人のアクターは、互いにメッセージを待つ状態になる可能性があります。したがって、デバッグの方がはるかに簡単ですが、ロックと同じようにデッドロックが発生します。ただし、トランザクションメモリを使用すると、デッドロックが発生しないことが保証されます。
それほど効率的ではない
- 不変性が強制されているため、および多くのアクターが同じスレッドアクターを使用して切り替える必要があるため、ロックベースの同時実行性ほど効率的ではありません。
結論
ロックベースの同時実行が最も効率的ですが、プログラミングが難しく、エラーが発生しやすくなります。ソフトウェアトランザクショナルメモリは、最も明確でプログラムしやすく、エラーが少ない傾向がありますが、効率も最も低くなります。アクターは、これら2つのモデルの中間のどこかにあり、プログラミングのしやすさ、効率、エラーの発生しやすさなど、あらゆる側面を備えています。