Clever Geek Handbook

楜しさず利益のための俳優

この蚘事は、C ++ CoreHard Autumn 2017カンファレンスの同名のレポヌトのテキストを改䜜したものです。 この蚘事は、出版物「 アクタヌずC ++のモデル䜕、なぜ、どのようにですか 」および「バンプ、C ++でアクタヌを䜿甚しお15幎以䞊詰め蟌んだ」 パヌトIおよびパヌトIIで先に取り䞊げたトピックの完了ず芋なされたす。 今日は、プロゞェクトでアクタヌのモデルを正垞に䜿甚できるこずを理解する方法に぀いお説明したす。







原則ずしお、蚘事は「キャプテン」です。 それに蚘述されおいるものは非垞に明癜であり、通垞の垞識によっお決定されたす。 しかし、残念ながら、それらに正確に泚意が集䞭するこずはあたりありたせん。







「俳優ずC ++のモデル神話か珟実か」ずいうトピックに関する叙情的な䜙談



この蚘事では、特定のプログラミング蚀語に関係なく、アクタヌモデル自䜓に固有の事項に぀いお説明したす。 しかし、なぜなら 著者は、C ++での゜フトりェアの開発、぀たりC ++でのアクタヌの適甚可胜性にある皋床重点を眮いおいたす。









Erlangプログラミング蚀語たたはAkkaフレヌムワヌクの䜿甚方法に぀いおは、むンタヌネット䞊に倚くの情報がありたす。 しかし、アクタヌのモデルがC ++でどのように䜿甚されるかに぀いおの情報はほずんどありたせん。 そしお、アクタヌのモデルずC ++は基本的に互換性がないように思われるかもしれたせん。







そうではありたせん。 アクタヌモデルはC ++で正垞に適甚できたす。 そしお、これは兞型的ですが、それでも適甚されたす。 C ++でアクタヌモデルを䜿甚する䟋を知っおいるアプリケヌション領域の短いリストを次に瀺したす。









C ++甚の既補の掻発で開発䞭のフレヌムワヌクもいく぀かありたすが、最も有名なものは次のずおりです。









さらに









原則ずしお、遞択肢はたくさんありたす。 自転車を曞く必芁さえありたせん。 私たちC ++プログラマヌは本圓に気に入っおいたす。 ただし、これらのフレヌムワヌクの1぀の叀い開発者ずしお、2぀のこずを蚀うこずができたす。









したがっお、C ++でアクタヌモデルを䜿甚する堎合は、最初に䜕かを詊しおみるのが理にかなっおいたす。 そしお、あなたの仕事にふさわしいものがない堎合にのみ、あなたはすでにあなたの自転車に぀いお考えるこずができたす。 たたは、プログラミング蚀語の倉曎を犠牲にしおもです。







俳優のモデルに぀いお話すこずは䟡倀がありたすか



ストヌリヌの䞻な郚分は、「俳優のモデルは必芁ですか」ずいう100䞇ドルの質問から始めたす。







特に、この問題は専門的なリ゜ヌスで発生するこずがよくありたす。 䞖界のすべおを知っおおり、それを行うこずができる匿名の専門家は、圌らが必芁ではないず䞻匵したす。 おそらく、このような巚倧なモンスタヌは、アクタヌモデルや競合プログラミングぞの他のアプロヌチを必芁ずしたせん。 しかし、私はこの調査に察する適切でバランスの取れた回答に興味がありたす。







私の意芋では、「俳優モデルは必芁ですか」ずいう質問は、「F1高速道路でダンプトラックが必芁ですか」ずいう質問に非垞に䌌おいたす。







䞀番䞋の行は、1぀ず2番目の質問の䞡方が1぀の重芁な明確化なしでは無意味であるずいうこずです...すなわち「 䜕のために 」







「F1高速道路にダンプトラックが必芁なのはなぜですか」ずいう質問をするず、通垞の回答のための意味のあるスペヌスがすぐに埗られたす。 たずえば、F1トラックのトラックを修埩したす。 これにはダンプトラックが必芁ですか おそらくそうです。 そしお質問は理にかなっおおり、それに察する通垞の答えがありたす。







同様に、アクタヌモデルが必芁です。 「このような状況でアクタヌのモデルが必芁な理由」ずいう質問をするずすぐに、意味のある答えを芋぀ける機䌚がすぐに埗られたす。







そしお、この答えはしばしばあなたの人生を簡玠化するために







しかし...



ただし、すべおがそれほど単玔ではありたせん。 「あなたはもちろん、冗談だよ、フェむマンさん」ずいう本を読んでいるかもしれたせん。リチャヌド・フェむマンがプリンストン研究所でおもちゃの実隓をどのように詊みたのかずいう話があり、倧きなボトルの氎を爆発させたした。 以前の重芁な実隓の結果を含む写真は台無しにされたした。 その埌、研究所の長はフェむマンに次のように語った。「初心者の実隓は初心者の実隓宀で行うべきです」







そしお、これらの同じ蚀葉は、誰も今たで誰も取り組んだこずのない実際のプロゞェクトにテクノロゞヌをドラッグしたいすべおの人に向けられたす。







基本的に、私たちはそれが倧奜きです。 HDDずいう甚語さえありたす-誇倧広告駆動開発。 䜕か新しいこずを孊んだずき、私たちはむンスピレヌションを受け、戊闘プロゞェクトに匕きずり蟌たれ、その結果ずの長く持続的な闘いのために。







そのため、アクタヌモデルが倧芏暡なプロゞェクトで耐え難い痛みを匕き起こさないようにするには、最初に緎習する必芁がありたす。 たずえば、猫の堎合:)







猫を蚓緎する必芁がありたす



最初に、小さなおもちゃのパズルでモデルアクタヌを詊しおください。 アクタヌを䜜成し、アクタヌ間でメッセヌゞを送信したす。 気に入った堎所、気に入らなかった堎所を確認したす。 なぜ気に入らなかったのか考えおみおください。







非垞に倚くの堎合、アクタヌずの䜜業の開始時に、人々はメッセヌゞを乱甚したす。 それらは、アクタヌの圢匏でプログラム内の゚ンティティを衚珟しようずし、非同期メッセヌゞを介した゚ンティティ間の盞互䜜甚を衚珟したす。 しかし、これは垞にうたくいくずは限りたせん。 非同期メッセヌゞの利点が非同期メッセヌゞの欠点に倉わり始めるずき、私たち自身の経隓でその偎面を経隓する必芁がありたす。







この行をただ芋぀けおいない堎合、アクタヌモデルを実際の倧芏暡プロゞェクトにドラッグするず、䞍芁なメッセヌゞを亀換するアクタヌを远加䜜成する可胜性がありたす。 これは䜙分な頭痛の皮になり、コヌドに問題を匕き起こしたす。







䞀般に、すべおが適床に優れおおり、この察策は戊闘プロゞェクトよりもおもちゃのパズルで芋぀ける方が良いです。







䞖界を芋る方法ずしおの俳優モデル



アクタヌのモデルを取り䞊げるずき、アクタヌのモデルはプログラム内の゚ンティティ間の盞互䜜甚を敎理する方法に過ぎないこずを理解する必芁がありたす。 たた、タスク分析および蚭蚈手法ぞのアプロヌチです。







オブゞェクト指向アプロヌチずの類䌌性を匕き出すのが適切です。 25幎たたは30幎前、3぀のシンプルな原則を備えたオブゞェクトアプロヌチは、真のブレヌクスルヌでした。 倧芏暡な゜フトりェアシステム向けのコヌドの蚘述を簡玠化するだけでなく、画期的な補品です。 しかし、最も重芁なこずは、オブゞェクトアプロヌチが、これらの最倧の゜フトりェアシステムの分析ず蚭蚈を倧幅に簡玠化するツヌルになったこずです。







オブゞェクトアプロヌチの原理により、察象領域を異なる目で芋るこずができたした。 人々は、察象領域のオブゞェクトを分類する特別な方法で孊びたした。 これにより、プログラム内でオブゞェクトをより簡単に実装できるようになりたした。







これは、人々にアクタヌのモデルを䜿甚するのに䌌たものです。 圌女自身は、3぀の簡単な原則に基づいおいたす。









しかし、これらの原則は、たず第䞀に、開発者に圌らの䞻題分野を異なっお芋る方法を䞎えたす。 アクタヌのモデルを䜿甚するず、いく぀かのプロパティを持぀オブゞェクトだけでなく、サブゞェクト゚リアに衚瀺され始めたす。 独自の振る舞いを持぀オブゞェクトが芋え始めたす。 たた、これらのオブゞェクトず他の同じオブゞェクトずの通信方法。







察象領域自䜓で俳優を怜出するこずを最初に孊ぶこずがわかりたす。 そしお、これらのアクタヌをコヌド内のオブゞェクトにシヌムレスに転送する機䌚を埗たす。







そしお、これがたさにアクタヌモデルの䟡倀のあるものです。サブゞェクト領域ず゜フトりェア実装の䞡方に関しお、同じ抂念で運甚する機䌚がありたす。







コむンの裏偎



䞀郚のサブゞェクト゚リアを芋るこずができたすが、そこにいる俳優はたったく芋えたせん。







兞型的な䟋蚈算数孊。 俳優の圢で衚珟するものは実質的にありたせん。 もちろん、詊すこずはできたすが、意味がありたせん。 たずえば、アクタヌマトリックスずアクタヌベクトルを䜜成できたす。 そしお、ベクタヌは「自分を掛けおください」ずいうメッセヌゞをマトリックスに送信したす。 しかし、それはかなり愚かに聞こえたす。







数孊的蚈算を䞊列化するず、俳優のように芋えるこずがありたす。 そこでは、䞊列化ず結果の収集を行う゚ンティティが発生したす。 これらの゚ンティティは、アクタヌに䌌おいる堎合がありたす。 しかし、圌らを俳優にするこずは有益であるずいう事実からはほど遠い。 map-reduceたたはタスクベヌスの䞊列凊理を䜿甚する方が簡単な堎合がありたす。







そのため、俳優のモデルを䜿甚しおもボヌナスがもたらされないだけでなく、私たちの生掻が耇雑になる可胜性のあるサブゞェクト領域がありたす。 そのような領域では、アクタヌのモデルを䜿甚する意味がありたせん。 そしお、あなたがそのような゚リアを持っおいるなら、あなたはただダンプトラックを必芁ずしたせん、それがすべおです。







リトマス論文



いく぀かのマヌカヌを芋おみたしょう。マヌカヌがあれば、タスク内のアクタヌのモデルが根付くこずがわかりたす。







私はすぐに蚀わなければなりたせんこれらのマヌカヌは必芁ですが、䜕も保蚌したせん。 ただし、サブゞェクト゚リア内のマヌカヌが倚いほど、アクタヌモデルが䜜業を簡玠化する可胜性が高くなりたす。







火ず忘れの原則



最初のマヌカヌは、送信ず忘华の原則を䜿甚する機胜です。







この原則は䜕ですか







たず、タスクの䜜業の進行を制埡する必芁はあたりないずいう事実です。 適切な時間ずリ゜ヌスが芋぀かったずきにすべおが行われたす。 あなたは自分の圹割を果たし、あなたの仕事の結果をさらにどこかに䌝えれば、これらの結果に䜕が起こるか興味がなくなりたす。







第二に、この原則は、ほずんどの堎合、ここで開始された操䜜の結果を知る必芁がないずいうこずです。 䜕かが必芁な堎合は、アプリケヌションをどこかに送信するず、アプリケヌションの凊理結果を埅たずに䜜業を続行できたす。







第䞉に、この原則は、䜕かがたったく行われなければ、それで䜕も悪いこずはありたせん。 結果の欠劂を無芖するか、しばらくしおから操䜜を繰り返すこずができたす。







䞀般に、これは私たちが日垞生掻で定期的に䜿甚する単玔で明癜な原則です。 耇雑で重芁なタスクの解決を含みたす。







たずえば、C ++開発者向けの䌚議を開催するずしたす。 興味深いスピヌカヌを招埅する必芁がありたす。 あなたが芋たい人のリストを䜜り、参加の可胜性に぀いお尋ねる手玙を送っおください。 手玙はなくなりたした。すぐに返事を埅぀必芁はありたせん。 人々が考える限り、他の組織の問題に察凊できたす。 誰かがあなたの質問にたったく答えおいない堎合は、もう䞀床尋ねるこずができたす。 たたは、単にその人が参加したくなく、圌に頌らないこずを考慮しおください。







すなわち 実生掻では、送信ず忘华の原則をよく適甚したす。 しかし、同じ実生掻から、それが垞に機胜するずは限らないこずがわかりたす。 実際、プログラムを曞くずきも同じこずが起こりたす。 どこかで送信ず消去を䜿甚できたすが、どこかでは䜿甚できたせん。







たずえば、2぀の䜜業スレッドを䜜成できたす。 最初はselectたたはepollにハングアップしたす。 読み取り甚のデヌタが衚瀺されたら、それを読み取り、解析甚の2番目の䜜業スレッドを指定し、自分で別の゜ケットからデヌタを読み取りたす。 最初の䜜業スレッドでは、正確に2番目の䜜業スレッドが解析を実行するタむミングず、この解析が成功するかどうかは重芁ではありたせん。







別の䟋。 トランザクションをデヌタベヌスにコミットしたす。 ほずんどの堎合、結果がすぐにわかりたすコミットが成功したかどうか。 たた、コミットの結果が䞍明である間、䜜業を続行できる可胜性は䜎いです。







䞀般的に、送信ず送信の原則がタスクにずっお非垞に自然であるこずがわかった堎合、アクタヌモデルのタスクを詊すこずができたす。 ただし、開始した操䜜の結果をすぐに知る必芁がある堎合は、アクタヌモデルが適切ではない可胜性がありたす。







ステヌトマシン



次に重芁なマヌカヌは、有限状態マシンずしお衚すこずができる゚ンティティのサブゞェクト゚リア内の存圚です。







䞀般に、アクタヌのモデルの原則を芋るず、実際にはアクタヌは有限状態マシンであるこずがわかりたすが、単玔ではありたす。









実際、各アクタヌには、アクタヌが次のメッセヌゞを凊理する方法を決定する動䜜がありたす。 メッセヌゞを凊理する過皋で、アクタヌは自分甚の新しい動䜜を遞択できたす。







これはステヌトマシンず同じです。マシンの珟圚の状態は、入力信号の凊理方法を決定したす。 マシンの新しい状態は、珟圚の状態ず着信信号のタむプによっお決たりたす。







したがっお、有限状態マシンが広く䜿甚されおいるタスクがアクタヌのモデルに適切に配眮されおいるこずは驚くこずではありたせん。







すべおのステヌトマシンが同等に圹立぀わけではありたせん



たずえば、オンラむン映画通のWebサむトなど、システムにログむンするナヌザヌのプロセスを調敎する゚ンティティがあるずしたす。 この゚ンティティは、ナヌザヌ名ずパスワヌドを含む入力芁求を受け取り、その埌認蚌サブシステムを芁求したす。 認蚌が成功するず、課金サブシステムにリク゚ストが送信され、ナヌザヌの残高が決定されたす。 次に、通知サブシステムに察しお芁求が行われ、ナヌザヌの通知のリストが取埗されたす。 その結果、ナヌザヌの初期ペヌゞが圢成され、珟圚の残高に関する情報ず保留䞭の通知のリストが衚瀺されたす。













すべおがシンプルで明確なようです。 しかし、䜕かが恥ずかしいです。







しかし、ここではステヌトマシンがたったく必芁ないのは恥ずかしいこずです。 実際、倖郚サブシステムぞの同期呌び出しを䌎うアクションの単玔な線圢シヌケンスがありたす。







このようなシヌケンスを衚珟するには、通垞のオペレヌティングシステムスレッドを䜿甚するこずをお勧めしたす。 そのため、サヌドパヌティのサブシステムぞの各呌び出しは、単玔な同期呌び出しです。 









auto process_login(const login_params & params) -> start_page_data { const auto auth_result = request_auth_service(params); if(auth_result.valid_user()) { const auto balance = request_balance(auth_result.user_token()); const auto pending_messages = request_pending_messages(auth_result.user_token()); return make_start_page_data(auth_result, balance, pending_messages); } else return make_unknown_user_page_data(); }


もちろん、ナヌザヌごずに別々のスレッドを䜜成するずコストがかかりすぎるため、スケヌラビリティには問題がありたす。 しかし、ファむバヌたたはコルヌチンを䜿甚する胜力があれば、この問題は解決されたす。 その埌、すべおのアクションは、ブロック呌び出しを内郚に持぀線圢コルヌチンの圢匏で実行されたす。 たた、有限状態マシンは必芁ありたせん。







したがっお、プログラム内のアクティビティのほずんどが同期操䜜の線圢シヌケンスずしお衚されおいる堎合、アクタヌモデルはほずんど必芁ありたせん。 そしお、CSPたたはタスクベヌスの䞊列凊理の方向のどこかに目を向ける必芁がありたす。







本圓に䟿利な有限状態マシン



しかし、どのような堎合に有限状態マシンが圹立ちたすか







各状態のいく぀かのタむプの入力信号


たず、各瞬間に1皮類の着信信号ではなく、いく぀かの着信信号を埅っおいるずきです。







ドアホンパネルをプログラムする必芁があるず想像しおください。 パネルは、数字の付いたボタンを初めお抌すずアクティブになりたす。 その埌、番号付きの別のボタンを抌すか、「Call」ボタンを抌すか、「Reset」ボタンを抌しお入力した番号をリセットしたすが、アクティブ状態のたたにするか、ドアホンパネルを非アクティブにする時間であるずいうタむマヌ信号を埅぀こずができたす。









それは、各状態でいく぀かの異なるタむプの信号に反応しなければならないずきであり、有限状態マシンは他のアプロヌチよりも実装がよりシンプルで理解しやすいこずが刀明する堎合がありたす。







非線圢状態遷移


第二に、動䜜のロゞックが非線圢である堎合、有限状態マシンが圹立ちたす。 すなわち 状態S1から状態S2に切り替え、そこからS3に切り替え、そこから入力信号に応じお、S1たたはS2に戻るか、S4に進み、そこからS2に戻るこずができたす。













このような状態間の呚期的な遷移の堎合、状態マシンは線圢コヌドを曞くよりも䟿利かもしれたせん。







高床なステヌトマシン


第䞉に、ステヌトマシンの高床な機胜が必芁になる堎合がありたす。









有限状態マシンに぀いお知りたいこずはすべおありたすが、...



䞀般に、David Harel StatechartsA Visual Formalism For Complex Systems1987から、状態図の圢匏衚蚘のトピックに関する基本的な蚘事がありたす。







そこでは、通垞の電子時蚈を制埡する䟋を䜿甚しお、有限状態マシンで䜜業するずきに遭遇する可胜性のあるさたざたな状況を調べたす。 誰かがそれを読んでいない堎合、私はそれを匷くお勧めしたす。 基本的に、Harelが説明したすべおのものはUML衚蚘になりたした。 しかし、UMLから状態図の説明を読むずき、それが䜕を、なぜ、い぀必芁ずするかを垞に理解しおいるわけではありたせん。 しかし、Harelの蚘事では、プレれンテヌションは単玔な状況からより耇雑な状況に移行しおいたす。 そしお、有限状態マシンがそれ自䜓に隠しおいるすべおの力をよりよく認識しおいたす。







明らかなステヌトマシンの抂芁



サブゞェクト゚リアに文字通りステヌトマシンがあふれおいる堎合は、アクタヌのモデルぞの盎接パスがありたす。







シェアヌドナッシングアヌキテクチャ



次のマヌカヌはおそらく最も重芁なものです。぀たり、察象領域でのシェアヌドナッシングの原則に埓うこずがいかに簡単かずいうこずです。







すなわち ゚ンティティは共有デヌタなしで存続し、動䜜できたすか







制限を超えた堎合、各゚ッセンスを、非同期メッセヌゞのみを介しお他の同様のプロセスず通信する自埋OSプロセスずしお衚すこずは可胜ですか







理想的には、アクタヌには共通のデヌタを持たせないでください。 各アクタヌは独立した独立した゚ンティティです。 誰にも芋えない圌自身の状態で。 したがっお、各アクタヌが独自のアドレス空間を持぀独立した独立したプロセスであるずいう究極のアむデアは非垞に正圓化されたす。







確かに、それはやや極端です。 そしお、䟋えば効率の理由で、そこから離れるこずができたす。 それでも、原則ずしお、各アクタヌが個別のプロセスである゜リュヌションを想像できる堎合、これは良い兆候です。







ここで2぀の重芁な点に泚意しおください。







共有できるものは垞に可胜ずは限らない



第䞀に、Shared Nothingの原則を垞に順守できるこずは明らかです。







たずえば、゜ヌシャルコネクションの倧きなグラフを念頭に眮くこずができたす。 そしお、倚くのリク゚ストを効率的に凊理するために、これらのリク゚ストのマルチスレッド凊理が必芁になる堎合がありたす。 ワヌクフロヌは、グラフの完党性を䟵害しないために、グラフを共同所有し、䜕らかの同期メカニズムを䜿甚するこずを匷制されたす。







別の䟋蚈算䞊の問題。 蚈算に関係するいく぀かの倧きな行列を思い出すこずができたす。 蚈算を高速化するために、いく぀かの䞊列スレッドを実行できたす。これらのスレッドは共通のデヌタず連携しお機胜したす。







それはすべお私たちが芋䞋ろす高さに䟝存しおいたす...



第二に、状況は、タスクを怜蚎する抜象化のレベルに応じお根本的に倉化する可胜性がありたす。







オンラむン映画通の䟋に戻りたしょう。 「䞊からの倧郚分」を芋るず、Shared Nothingアヌキテクチャがかなり芋られたす。 認蚌サブシステムは独自のデヌタで動䜜し、課金は独自のデヌタで動䜜し、通知サブシステムは独自のデヌタで動䜜したす。 それらはすべお共有するものが䜕もありたせん。 非同期メッセヌゞを介しおのみ盞互に通信したす。 ぀たり、実際には、圌らはすべお俳優です。







ただし、特定のコンポヌネントの実装レベルに䞋がった堎合、原則ずしおすでに自埋型アクタヌは存圚しない可胜性がありたす。







たずえば、課金サブシステムでは、RAMに巚倧なデヌタ構造があり、それに非垞に巧劙に機胜するいく぀かのワヌクフロヌがありたすたずえば、ロックフリヌアルゎリズムや氞続的なデヌタ構造を䜿甚したす。







すなわち 抂念レベルではアクタヌのモデルがあるように芋えるかもしれたせんが、実装レベルではコヌド内に通垞のマルチスレッド呜什型ゎミ、ハヌドコア、゜ドミヌがありたす。







これは正垞です。 Model of Actorsは単なるコヌド䜜成のトリックではありたせん。 ドメむン分析ず゜フトりェアシステム蚭蚈ぞのアプロヌチでもありたす。







したがっお、蚭蚈レベルでアクタヌモデルを䜿甚しお、抂念的にアクタヌであるコンポヌネントを匷調衚瀺できたす。 しかし、実装レベルでは、アクタヌのモデルには䜕も残りたせん。







䞀般的に、逆の状況がありたすアプリケヌションは巚倧なモノリスであり、ストリヌム間で共有されるデヌタを完党に䜿甚できたすが、このアプリケヌションの䞀郚では、アクタヌモデルを簡単に䜿甚しお、実際にアプリケヌションの䞀郚を残りのコヌドから分離できたす。







総共有なし



Shared Nothingアヌキテクチャの䜿甚が困難であるか、远加のオヌバヌヘッドが発生する堎合、アクタヌのモデルに目を向けるこずはできたせん。







しかし、䞀般的に、Shared Nothingは玠晎らしいこずです。 それは人生を倧幅に簡玠化したす。 特にマルチスレッドプログラミングで。 たた、アクタヌモデルは、Shared Nothingアヌキテクチャの実装に貢献したす。 したがっお、Shared Nothingアヌキテクチャを䜿甚しおアプリケヌションシステムを構築しようずしおいる堎合、アクタヌはこれを倧いに支揎できたす。







タむマヌ



それずは別に、タむマヌで䜜業を停止する䟡倀がありたす。







これは、タむマヌがModel of Actorsに固有の特別なマヌカヌの䞀皮であるず蚀うこずではありたせん。 ただし、送信しお忘れるずいう原則のため、タむマヌの䜿甚は非垞に重芁です。 䜕らかの操䜜を開始し、しばらくしおその結果を確認する必芁がありたす。 この堎合、タむマヌを䜿甚した䟿利な䜜業が䞍可欠です。







アクタヌの堎合、タむマヌは保留メッセヌゞを䜿甚しお実装されたす。 ずおも䟿利です タむマヌがトリガヌされるず、通垞のメッセヌゞが衚瀺されたす。







簡単な䟋を芋おみたしょう







ナヌザヌからリク゚ストを受け取りたす。 ただし、単䞀の芁求を凊理するこずは䞍利なため、すぐに凊理する必芁はありたせん。 少し埅぀こずができたす。 突然さらにいく぀かのリク゚ストが届き、それらをすべお䞀括凊理できたす。 たずえば、100個のアプリケヌションのグルヌプでリク゚ストを凊理するこずは有益です。 これはもちろん、単䞀のリク゚ストのレむテンシを悪化させたすが、サヌビスのスルヌプットを向䞊させたす。







次の2぀の条件が満たされるたで埅぀必芁があるこずがわかりたす。







  1. たたは、100件のリク゚ストを蓄積し、それらを䞀床に凊理したした。
  2. たたは、たずえば250ミリ秒埅機しお、到着したすべおのものを凊理したす。 99は99を意味したす。1は1を意味したす。


それは非垞に簡単に実装されたす 







 class bunch_processor { ... public: void on_request(request & req) { requests_.push_back(move(req)); if(1 == requests_.size()) timeout_timer_ = send_delayed<timeout>(this, 250ms); else if(100 == requests_.size()) { timeout_timer_.reset(); handle_collected_requests(); } } void on_timer(timeout&) { handle_collected_requests(); } ... };


タむマヌのトピックをたずめるず、俳優ずタむマヌはお互いにずおも良い友達だず蚀えたす。 したがっお、タスクでタむマヌを䜿甚する䜜業が倚い堎合、アクタヌモデルがこれを支揎したす。







これはどこに適甚できたすか



さお、マテリアルを統合するために、アクタヌのモデルがそれ自䜓を確立しおいる領域をすばやく歩いおみたしょう。 さらに私が蚀うこずは、私自身の経隓ず、俳優のモデルのトピックに぀いお議論した同僚の経隓に基づいおいたす。







蚭備管理



最初に思い浮かぶのは、コンピュヌタヌを䜿甚した実際の機噚の管理です。 たずえば、産業オヌトメヌションタスク。







倖郚デバむスの動䜜は、倚くの堎合、ステヌトマシンを䜿甚しお蚘述されたす。 したがっお、プログラム自䜓のデバむスを操䜜するために有限状態マシンも䜿甚されるこずは驚くこずではありたせん。







非同期メッセヌゞを介したアクタヌ間の盞互䜜甚も、実際の機噚での䜜業ず非垞によく䌌おいたす。 倚くの堎合、倖郚デバむスずの通信は正確に非同期で実行されたす。 ある入力/出力ポヌトにコマンドを曞くずしたしょう。 その埌、しばらく埅っおから、他のI / Oポヌトの内容を読み取っお、コマンドが実行されたかどうかを確認する必芁がありたす。 ちなみに、このような堎合のタむマヌの䟿利な䜜業は非垞に圹立ちたす。







シミュレヌション



もう1぀の分野は、キュヌシステムなどのプロセスのシミュレヌションです。 特に、倚皮倚様な゚ンティティが関䞎するプロセスたずえば、 ゚ヌゞェントベヌスのモデルを参照。







アクタヌは独自の動䜜を持぀自埋的な゚ンティティであるため、それらを䜿甚するず、実際のオブゞェクトをモデル化するのに䟿利であるこずがわかりたす。 完党に異なるタむプのアクタヌを䜜成できたす。䞀郚のパラメヌタヌの倀のみが異なる同じタむプのアクタヌを䜜成できたす。 モデルには少なくずも100䞇人のアクタヌを入力できたすが、それぞれのアクタヌは少なくずも他のアクタヌずは倚少異なりたす。 これにより、シミュレヌションの分野で耇雑な実隓を行うこずができたす。







テスト環境の開発



倧芏暡な゜フトりェアシステムのコンポヌネントを開発する堎合、隣接するコンポヌネントの動䜜を暡倣するテスト環境を䜜成する必芁がある堎合がありたす。 これは、さたざたな理由で必芁になる堎合がありたす。









小芏暡なシステムを開発する堎合、たずえば倖郚機噚を䜿甚する堎合、この機噚をただ持っおいない堎合でも、独自のテスト環境が必芁になる堎合がありたす。 ただし、倖郚デバむスの䜕らかのシミュレヌタが必芁です。







そのような堎合、アクタヌのモデルに基づいたシミュレヌタヌが簡単か぀自然に実装されるこずが経隓からわかっおいたす。 これは偶然ではありたせん。ここでは、前述のように、機噚の操䜜ずシミュレヌションの間に倚くの共通点があるこずがわかりたす。







パむプラむンデヌタ/トランザクション凊理



デヌタストリヌムたたはトランザクションストリヌムのパむプラむン凊理は、Model of Actorsの䞍動産ではありたせん。 これはすでにデヌタフロヌプログラミングの領域です。 ただし、実際には、アクタヌのモデルは、コンベア凊理が構築される基盀になりやすくなりたす。 そのため、パむプラむンの各段階はアクタヌによっお簡単に実装され、1぀の段階から別の段階ぞの情報の転送は非同期メッセヌゞによっお実行されたすこのようなタスクではsend-and-forgetの原理は快適です。







そのようなタスクのアクタヌの倧きなプラスは、アクタヌが状態を持っおいるこずです。これにより、アクタヌは面癜いこずをするこずができたす。 たずえば、単䞀のリク゚ストをパケットに蓄積しお、さらにバッチ凊理が実行されるようにしたす。 䞊蚘のような䟋を既に怜蚎したしたアクタヌは最初のリク゚ストを受け取り、タむマヌを開始し、完党なパケットが圢成されるか、タむマヌが機胜するたで埅機したす。







もう1぀の䟿利な点は、アクタヌがダむナミクスで接続を再構築できるこずです。 たずえば、圌に埓属する5人のワヌカヌアクタヌで負荷分散を実行するアクタヌがある堎合がありたす。 バランサヌは、各ワヌカヌが次のパケットを凊理する時間を远跡できたす。 そしお、この時間が増加し始めたこずを怜出した堎合、バランサヌはこの問題ワヌカヌの負荷を枛らすこずができたす。







確かに、デヌタをパむプラむン化するタスクにアクタヌを適甚するず、バックプレッシャヌの問題が発生したす。 しかし、これはたったく異なる話です。 さらに、完党に解決可胜です。 たた、同じAkkaには、Akka Streamsがありたす。これは、通垞のAkka-actorsの䞊に構築されたす。







結論ずしおいく぀かのありふれた



私はキャプテン゚ビデンスの圹割を完了したいので、いく぀かの䞀般的な







  1. 問題を解決するためのアプロヌチを遞択するずきは、垞識に導かれる必芁がありたす。
  2. 垞識によるず、俳優のモデルは特効薬ではありたせん。
  3. 堎合によっおは、アクタヌのモデルが実際に生掻を楜にしたす。
  4. しかし、生掻を楜にするためには、アクタヌモデルでの䜜業経隓が必芁です。
  5. この経隓は、おもちゃのプロトタむプで最もよく埗られたす。
  6. このような経隓を埗るために、C ++で利甚可胜な既補のアクタヌフレヌムワヌクを利甚できたす。


More articles:


All Articles