最初に書く一般的に、同時実行スレッド間の通信には、データの共有とメッセージの受け渡しという 2 つの戦略があります。共有データを使用した並行プログラミングが直面する最大の問題の 1 つは、データ条件の競合です。さまざまなロックの問題に対処するのは頭痛の種です。 従来、最も人気のある言語の並行性は、書き込みの競合を防ぐための同期メソッドを使用して、複数のスレッド間での共有メモリに基づいています。アクターはメッセージ モデルを使用します。各アクターは一度に最大 1 つのメッセージを処理し、他のアクターにメッセージを送信できるため、個別の書き込み原則が保証されます。これにより、マルチスレッド書き込み競合が巧みに回避されます。共有データ方式と比較して、メッセージ パッシング メカニズムの最大の利点は、データの競合が発生しないことです。メッセージ パッシングには、チャネル ベース (golang で表現) とアクター ベース (erlang で表現) の 2 つの一般的なタイプがあります。 俳優紹介アクター モデル = データ + 動作 + メッセージ。 アクター モデルは、特定の言語やフレームワークに固有のものではなく、一般的な並行プログラミング モデルです。ほぼすべてのプログラミング言語で使用できますが、最も一般的なのは、言語レベルで Actor モデルのサポートを提供する Erlang です。キラー アプリケーション RabbitMQ は Erlang に基づいて開発されています。 よりオブジェクト指向的アクターは、オブジェクト指向プログラミング (OO) のオブジェクトに似ています。各アクター インスタンスは、それ自身の関連状態をカプセル化し、他のアクターから物理的に分離されます。ゲームプレイヤーの例を見てみましょう。各プレイヤーは、アクター システム内のアクター プレイヤーのインスタンスです。各プレイヤーには、ID、ニックネーム、攻撃力などの独自の属性があります。コード レベルは、実際には OO コードとそれほど変わりません。システム メモリ レベルにも複数の OO インスタンスが存在します。
ロックなし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 にも欠点があります。
崇高な
|
<<: クラウドコンピューティングは「クラウドコンピューティング」にはならない
サイトの含め方に関しては、多ければ多いほど良いというのが従来の考え方です。特に友好的なリンクを交換す...
検索エンジン最適化は、技術的コンテンツが最も少ないインターネット サービスであると考えられることがあ...
検索エンジンのアルゴリズムがますます洗練されるにつれて、ウェブサイトの品質に対する要求も高まっていま...
このような問題に遭遇することはよくあります。サイトを最適化するために一生懸命努力すると、すべてが非常...
過去数年間でクラウドの導入が加速しており、多くの組織が従来のデータセンターをクラウドホスト型インフラ...
ますます多くの企業にとって、エンタープライズ ネットワークの「エッジ」が IT 投資の焦点になりつつ...
配布されるもの配布について話すとき、それは集中化を伴わなければなりません。集中化と比較すると、分散と...
鉄歌のこれまでの記事は、完全に彼自身の観察に基づいている。程小勇同志は足の指で誰が書いたかを推測でき...
今年12月現在、中国がWTOに加盟してからちょうど10年が経ちました。また、わが国の対外貿易が急速に...
いわゆるバイラル マーケティングとは、ユーザーの口コミによる宣伝ネットワークを通じて情報がウイルスの...
地理位置情報データは、さまざまな政府機関に必要な情報を提供することができ、法執行機関は位置データを使...
[[359262]]今日の企業は、ビジネスと責任の面でますます大きなプレッシャーにさらされています。...
以前、私はある企業のウェブサイトの SEO 最適化分析を手伝うよう依頼され、このウェブサイトに存在す...
10 年前、Amazon Web Services は、あらゆる規模の環境で一貫して 1 桁のミリ秒...
Pinduoduo が急成長を続けるにつれ、おそらく人々に認識させたのは、ソーシャル e コマース自...