Akkaが同時実行性に優れているのはなぜですか？

私はアッカと俳優のフレームワークに不慣れです-明らかな何かが欠けていると確信しています。事前に謝罪を受け入れてください。

私は、Akkaを選択する際の主なポイントの1つが、並行性の管理方法であることを読み続けています。

Akkaがなぜそれほど特別なのかははっきりしません。私は非常に軽くて速い小さな俳優がたくさんいることを理解しています。ただし、2人のユーザーが同時にフォームを保存する場合、これはどのように役立ちますか？

なんらかの並行処理ロック（悲観的/楽観的/その他）はまだ必要ないのでしょうか？

アクターやエージェントなどのメッセージ処理モデルの利点の1つは、従来の同時実行性の問題（主に共有状態の同期）が問題ではなくなったことです。アクターはプライベートな状態を維持し、ロックなしで自由に更新できます。アクターフレームワークは、一度に1つのメッセージのみが処理されるようにします。シリアル化された処理を使用すると、ロックフリーの方法でコードを記述できます。

ユーザーがフォームを保存する例では、アクターが各フォームの一部のデータのリストを保持していると想定すると、フレームワークは一度に1つのフォームのみが処理されることを保証するため、アクターはロックなしでリストを更新できます。従来、リストアクセスをロックするか、同時リストを使用する必要がありました。

並行性戦略は少し異なりますが、それでも責任があります（最も一般的な戦略は戦略ではありません）。例を少し変更するために、両方のユーザーが同じフォームインスタンスを同時に更新しようとしているとしましょう。並行性戦略がないと、1つの変更が他の変更を上書きします（おそらく最後の1つが優先されます）。それは問題ありませんが、せいぜいこれにより、変更が上書きされたユーザーに予期しない動作が発生します。変更したばかりのフォームを表示すると、（他のユーザーからの）予期しない値になります。最悪の場合（フォームの更新だけでなく、注文の発送などについても）、さまざまな種類（時間、収益など）の損失が発生する可能性があります。

同時方式を使用すると、これらのケースを識別し、ビジネスルールに基づいてそれらを解決できるようになります。たとえば、Optimistic Concurrencyは、更新中のフォームのバージョンをユーザーに送信させます。アクターが変更を処理しようとすると、最初のユーザーの更新により、フォームが実際にバージョン6であるときに、2番目のユーザーがバージョン5を更新していると考えていることに気付きます。これで、少なくとも2人目のユーザーに、フォームの編集を開始してから既にフォームが変更されていることを通知できます。あるいは、企業がそこで施行したい規則は何でも。

フォームを更新する場合、おそらく同時実行性についてそれほど気にする必要はありません（おそらく、私は推測します）。しかし、他の場合では、少なくとも違反をチェックして処理できることが非常に重要な場合があります。ユーザーが別のセクションを変更した場合（フォームの類推を続けるため）のように、同時実行違反を無視することもできます。または、変更がビジネスに大きな影響を与える場合（大きな注文）、それを受け入れて、後で小さな競合を解決する必要があります（例：連絡先情報の年次更新が完了していない）。

Akkaには、障害の処理方法や監督者など、開発者にとって重要な考慮事項である他の多くの側面があると思います。

古典的なロックベースの同時実行やきちんとしたトランザクションメモリなどの他の同時実行モデルと比較して、（Akkaだけでなく）一般的にアクターモデルについて書きます。

メリット

1. 理解と使用が容易なコンセプト

   • ロックベースの同時実行は困難です。ロック、セマフォ、スレッド、同期、相互排除、メモリバリアなど、正確かつ効率的になるために理解して使用する多くの概念があるため、これを正しく理解することは特に困難です。

   • 一方、アクターはより抽象的な概念です。メッセージを送受信するアクターがあります。記憶障壁などの低レベルの概念を把握して使用する必要はありません。

2. 不変性を強制する

   • 可変性は、プログラミング、特にマルチスレッドアプリケーションでの多くのエラーやバグの原因です。アクターモデルは、不変性を適用することでこの問題を解決します。

3. エラーが発生しにくい

   • 上記の2つの理由により

4. 効率的

   • 優れた書き込みロックベースほど効率的ではありませんが、一般にソフトウェアトランザクションメモリよりも効率的です。

5. 簡単に拡張可能

   • 少なくとも理論的には、アプリケーションはより多くのアクターを追加してジョブを実行することでかなり適切にスケーリングする必要があります。ロックベースでは、スケーリングがかなり困難です。

短所

1. すべての言語が簡単に不変性を強制するわけではありません。

   • 最初にアクターを普及させた言語であるErlangは、コアに不変性がありますが、JavaとScala（実際にはJVM）は不変性を強制しません。

2. まだかなり複雑

   • アクターはプログラミングの非同期モデルに基づいていますが、これはそれほど単純ではなく、すべてのシナリオで簡単にモデル化できません。エラーや障害のシナリオを処理することは特に困難です。

3. デッドロックや飢餓を防止しない

   • 2人のアクターは、互いにメッセージを待つ状態になることができます。したがって、デバッグの方がはるかに簡単ですが、ロックと同じようにデッドロックが発生します。ただし、トランザクションメモリを使用すると、デッドロックが発生しないことが保証されます。

4. それほど効率的ではない

   • 不変性が強制されているため、および多くのアクターが同じスレッドアクターを使用して切り替える必要があるため、ロックベースの同時実行ほど効率的ではありません。

結論

ロックベースの同時実行が最も効率的ですが、プログラミングが難しく、エラーが発生しやすくなります。ソフトウェアトランザクショナルメモリは、最も明確でプログラムしやすく、エラーが少ない傾向がありますが、効率も最も低くなります。アクターは、これら2つのモデルの中間にあり、プログラミングの容易さ、効率性、エラーの傾向など、あらゆる側面を備えています。