アクターモデルは分散型の高並列処理に非常に適しています

最初に書く

一般的に、同時実行スレッド間の通信には、データの共有とメッセージの受け渡しという 2 つの戦略があります。共有データを使用した並行プログラミングが直面する最大の問題の 1 つは、データ条件の競合です。さまざまなロックの問題に対処するのは頭痛の種です。

従来、最も人気のある言語の並行性は、書き込みの競合を防ぐための同期メソッドを使用して、複数のスレッド間での共有メモリに基づいています。アクターはメッセージ モデルを使用します。各アクターは一度に最大 1 つのメッセージを処理し、他のアクターにメッセージを送信できるため、個別の書き込み原則が保証されます。これにより、マルチスレッド書き込み競合が巧みに回避されます。共有データ方式と比較して、メッセージ パッシング メカニズムの最大の利点は、データの競合が発生しないことです。メッセージ パッシングには、チャネル ベース (golang で表現) とアクター ベース (erlang で表現) の 2 つの一般的なタイプがあります。

俳優紹介

アクター モデル = データ + 動作 + メッセージ。

アクター モデルは、特定の言語やフレームワークに固有のものではなく、一般的な並行プログラミング モデルです。ほぼすべてのプログラミング言語で使用できますが、最も一般的なのは、言語レベルで Actor モデルのサポートを提供する Erlang です。キラー アプリケーション RabbitMQ は Erlang に基づいて開発されています。

よりオブジェクト指向的

アクターは、オブジェクト指向プログラミング (OO) のオブジェクトに似ています。各アクター インスタンスは、それ自身の関連状態をカプセル化し、他のアクターから物理的に分離されます。ゲームプレイヤーの例を見てみましょう。各プレイヤーは、アクター システム内のアクター プレイヤーのインスタンスです。各プレイヤーには、ID、ニックネーム、攻撃力などの独自の属性があります。コード レベルは、実際には OO コードとそれほど変わりません。システム メモリ レベルにも複数の OO インスタンスが存在します。

クラスPlayerActor
    {公共  int ID { 取得;セット; }
パブリック文字列名前{get;セット; }
    }

ロックなし

Java や C# などの言語を並行プログラミングに使用する場合、ロックやメモリのアトミック性などの一連のスレッドの問題に特別な注意を払う必要があります。アクター モデルの内部状態はそれ自体で維持されます。つまり、その内部データはそれ自体でのみ変更できます (状態の変更はメッセージの受け渡しを通じて実行されます)。そのため、並行プログラミングにアクター モデルを使用すると、これらの問題を適切に回避できます。 Actor は、Redis と同様に内部的にシングルスレッド モードで実行されるため、分散ロックに似たアプリケーションを完全に実装できます。

非同期

各アクターにはメッセージを受信するための専用のメールボックスがあり、これはアクターが非同期操作を実現するための基盤でもあります。 Actor インスタンスが別の Actor にメッセージを送信する場合、Actor のメソッドを直接呼び出すのではなく、対応する MailBox にメッセージを渡します。それは、郵便配達員が、受取人に直接郵便物を配達するのではなく、各家庭の郵便受けに入れて、すぐに次の仕事に取り掛かれるようなものです。したがって、Actor システムでは、Actor がメッセージを送信するのは非常に高速です。

このような設計の主な利点は、アクターを分離できることです。数万のアクターがそれぞれ独自のペースで同時に実行され、メッセージの送受信がブロックされることはありません。

分離

各 Actor インスタンスは独自の状態を維持し、他の Actor インスタンスから物理的に分離されています。マルチスレッド + ロック モードのように共有データに基づくものではありません。アクターはメッセージ モードを通じて他のアクターと通信します。 OO スタイルのメッセージ パッシング方法とは異なり、アクター間のメッセージ パッシングは、実際に物理的なメッセージ パッシングです。

自然に分布する

各 Actor インスタンスの場所は透過的であり、Actor アドレスがローカルであるかリモート マシン上にあるかはコードに対して同じに見えます。各 Actor インスタンスは非常に小さく、最大でも数百バイトしかないため、1 台のマシンに数十万の Actor インスタンスを簡単に配置できます。 Golang コードを書いたことがあるなら、Actor は重量級という点では Goroutine と非常によく似ていることに気づくでしょう。位置の透明性により、アクター システムは並行処理に対応するために自由に水平方向に拡張できます。呼び出し元にとって、呼び出された Actor の場所はローカルです。もちろん、これは Actor システムの強力なルーティング システムによるものでもあります。

ライフサイクル

各 Actor インスタンスには、C# Java の GC メカニズムと同様に、独自のライフ サイクルがあります。排除する必要があるアクターについては、システムの継続性を確保するために、システムはメモリやその他のリソースを破棄して解放します。実際、アクター システムでは、アクターの破壊を手動で介入することも、システムを自動的に破壊することもできます。

フォールトトレランス

Actor のフォールト トレランスに関しては、かなり驚くべきことだと言わざるを得ません。従来のプログラミング方法は、システムの安定性を確保するために、将来例外が発生する可能性がある例外をキャプチャすることです。これはいわゆる防御プログラミングです。しかし、防御プログラミングにも欠点はあります。現実と同様に、防御側は将来起こり得るすべてのコード欠陥に対して 100% 防御することはできません。たとえば、Java コードでは、変数が nil かどうかを判断する必要がある場所が多数あります。これらは防御的コーディングの典型的な例です。ただし、Actor モデル プログラムは防御プログラミングを実行せず、「クラッシュさせる」という哲学に従い、Actor マネージャーがこれらのクラッシュに対処できるようにします。たとえば、アクターがクラッシュした後、マネージャーは新しいインスタンスを作成するか、ログを記録するかを選択できます。各アクターのクラッシュまたは例外情報はマネージャーにフィードバックできるため、各アクター インスタンスを管理する際のアクター システムの柔軟性が確保されます。

デメリット

世の中に完璧な言語は存在しません。フレームワークやモデルも同様です。分散環境における一種の並行モデルとして、Actor にも欠点があります。

1. 同じタイプの Actor オブジェクトは複数のホストに分散されているため、複数の Actor のコレクションを取得することは弱点となります。たとえば、電子商取引システムでは、製品はアクターの一種です。ほとんどの場合、製品リストのクエリは、次のプロセスを経ます。まず、クエリ条件に従って一連の製品 ID がフィルタリングされ、次に製品 ID に従って製品アクター リストが取得されます (es または他の検索エンジンのいずれを使用しても、製品検索サービスが生成される可能性が高くなります)。ボリュームが非常に大きい場合、ネットワーク ストームが発生するリスクがあります (ただし、その可能性は非常に小さいです)。リアルタイム要件がそれほど高くない場合は、実際に製品アクターのリストを分離し、MQ を使用して製品情報の変更のシグナルを受信し、データの一貫性の問題を処理することができます。
2. 多くの場合、アクター モデルに基づく分散システムでは、キャッシュはインプロセス キャッシュになる可能性が高く、つまり各アクターは実際にはプロセス内に独自の状態情報を保存します。業界では通常、このタイプのサービスをステートフル サービスと呼びます。ただし、各アクターには独自のライフサイクルがあります。これによって何か問題が起きるでしょうか?ハハ、そうかもね。考えてみてください。依然としてコモディティを例に挙げると、環境が非アクター同時実行モデルである場合、コモディティ キャッシュは LRU 戦略を使用して非アクティブなコモディティ キャッシュを削除し、メモリが過剰に使用されないようにすることができます。アクター モデルに基づくインプロセス キャッシュの場合、各アクターは実際にはキャッシュ自体であり、アクターのアクティブ状態が不明であるため、LRU 戦略を使用してメモリ使用量を確保するのはそれほど簡単ではありません。
3. 分散トランザクションの問題は、実際にはすべての分散モデルが直面する問題であり、アクターが原因で発生するものではありません。製品アクターを例にとると、製品を追加する場合、製品アクターと製品をカウントするアクター (多くの場合、実際には 2 種類のアクター サービスとして設計されています) は、物事の整合性とデータの一貫性を確保する必要があります。多くの場合、最終的な一貫性を確保するために、リアルタイムの一貫性が犠牲になることがあります。
4. 各アクターのメールボックスは蓄積されたりいっぱいになったりすることがあります。このような場合、新しいメッセージは破棄されるか待機されます。したがって、アクターシステムを設計する際には、メールボックスの設計に注意を払う必要があります。

崇高な

1. 上記の紹介から、アクターは場所に対して透過的であるため、どのアクターも他のアクターに対してローカルであるのと同じです。この機能に基づいて、さまざまなことが可能になります。従来の分散システムでは、サーバー A がサーバー B と通信する場合、RPC 呼び出し (http 呼び出しは一般的に使用されません) を使用するか、MQ システムを使用します。しかし、Actor システムでは、サーバー間の通信が非常にエレガントになります。これは本質的には RPC 呼び出しですが、コーダーにとってはローカル関数を呼び出すようなものです。実際、ストリーミング方式の方が現在は人気があります。
2. アクター システムの実行モデルはシングル スレッドで非同期であるため、フラッシュ セールなど、リソースの競合を伴う同様の機能はアクター モデルに非常に適しています。
3. 上記の紹介に基づくと、アクター モデルは本質的に設計レベルで負荷分散をサポートし、水平拡張を非常に適切にサポートします。もちろん、アクターの分散システムにはサービス登録センターも必要です。
4. Actor はシングルスレッド実行モデルですが、各 Actor がスレッドを占有する必要があるわけではありません。実際、Actor 上で実行されるタスクは、Golang の goroutine と同様に軽量にすることができます。さらに、ホスト上のすべてのアクターはスレッド プールを共有できるため、最小限のスレッド リソースを使用しながらビジネス コードが最大限に量子化されることが保証されます。