アクターモデルについて少し読みましたが、実際の状況でアクターを使用する方法、つまりアクターの問題をモデル化する方法がよくわかりません。
誰か説明していただけますか?簡単な例や例へのリンクをいただければ幸いです。
アクターは、アクションをモデリングするという意味で、メッセージなどを使用して、いくつかの便利なアイテムを提供するソフトウェアをモデリングする方法です...
アクターはシングルスレッドで実行できるため、大量のロックマジックを行わなくても、スレッドセーフでない/非並行操作を実行できます。俳優は、受信トレイのメッセージに応答します。コマンドを処理したい場合は、メッセージを送信すると、受信した順に処理されます。通常のキューと同じように。スレッドセーフはここではキラーであり、私はこれを、私が取り組んでいる多くのオープンソースプロジェクトで使用しています。
一部の言語では、Scalaたとえば、単一のプロセスでアクターベースのコードを分散システムに変換するのは簡単です。アクターを分解し、それらが通信するチャネルをリモートチャネルに変換します。この変更により、実装間でどれほど簡単かはわかりますが、すばらしい機能です。
CRUDイベントではなく、タスクベースのイベントに焦点を当てるのに役立ちます。 CRUDは単純ですが、ファイリングキャビネットとやり取りするのと同じです。私たちが作成するソフトウェアよりも多くの価値を提供できるとしたら、なぜそれを行うのですか?タスクベースのシステムで複数のアクションを単一の「更新」コマンドに結び付けることは、単にDBに保存するよりも便利です。これはCQRSなどにも当てはまります。
トラビスの答え はしっかりしています。並行性について話し始めると、リソースの問題を解決しようとしています。スレッドとロックの同時実行は、間違いを犯しがちです。アクターモデルは、コードの並行部分を、別のコードに依存せずに並行して実行できる自己完結型ナゲットとして強制的にプログラムするのに役立ちます。競合状態やデッドロックなどの卑劣さを回避しようとしています。
この会話では、俳優はあなたと私に似ています。あなたはただ私の脳に到達できず、私がタイプしているものを選ぶことができません。 「なぜ私たちは存在するのですか?」私はいくつかの番号を座ってクランチし、「私はそう思うので私はそうだ」と返信しました。あなたが私と一緒に持っている唯一の連絡先は、私たちがやり取りするメッセージを介することです。
編集:
どの言語に慣れているかは言いませんでしたが、自分の言語にアクターの実装があるかどうかを確認してください。多分最も簡単なのは、Pythonのアクターライブラリの一部です。しかし、おそらくErlangの方が学習に適しています。言語は少し荒いですが、ニュアンスを乗り越えたら、それは良い言語です。