アクターモデルはトランザクションの代替手段ですか？
トランザクションがロックを使用することを知っています。アクター 共有状態とロックから私たちを解放する
すべてのクラッシュがクリーンシャットダウンと同じであることを確認してください。これは、シェアードナッシングやシングルアサインメント（プロセスのメモリを分離する）、_ avoiding_locks_などの方法で実行できます。
アクターモデルはトランザクションの代替手段ですか？それは私たちを取引から解放しますか？
Reactive Akkaが並列プログラミングに革命を起こしたと読みましたが、ロックをアトムに分割して、アセンブラー言語のような低レベルのものを提供し、（カスタムタイムアウトを使用して）必要なロックを自分で構築できるようになりました。私が理解しているように、タイムアウトを追加できるという事実は、呼び出しのブロックとロックをフォールトトレラントにします。ただし、低レベルで手動で作成する必要があります。
ここで何がそんなに革命的ですか？トランザクションから救われていますか？他のアクターが干渉しないように、一部のアクターが1つ以上の他のアクターをロックして、いくつかの更新を送信する必要がある場合があることがわかりました。これは、「共有状態」、「ロック」、およびトランザクションと呼ばれます。アクターモデルがどのように私たちを彼らから救い、何かに革命を起こすのか理解できません。
または、単純なアクターモデル（複数のプロセッサアクター+メモリアクター）を検討してください。ロックなしでどのようにプログラムしますか？残念な例だと思います。しかし、どうすれば幸運な人が常にいることを確認できますか？宝石職人のモデルの言い回しの横で私が理解するのを手伝ってください。
共有された可変状態を処理するには、トランザクションとロックが必要であると正しく述べます。また、アクターシステムには、共有された可変状態はありません。ですから、あなたはすでにあなた自身の質問に答えているようです。
他のアクターが干渉しないように、一部のアクターが1つ以上の他のアクターをロックして、いくつかの更新を送信する必要がある場合があることがわかりました。
私はここであなたを完全にフォローしていません。なぜこのようなシステムを設計するのですか？
これは、「共有状態」、「ロック」、およびトランザクションと呼ばれます。
いいえ、この結論は正しくないと思います。状態はアクター内にカプセル化されており、このアクターにメッセージを送信することによってのみ変更できるため、この状態は共有とは見なされません。アクターが所有しているため、誰とも共有しません。メッセージを送信してこの状態を更新する場合、ロックやトランザクションは必要ありません。同時変更は、アクターの順次メッセージ処理によって除外されます。これは、「シングルスレッドイリュージョン」と呼ばれることもあります。
アクターモデルがどのように私たちを彼らから救い、何かに革命を起こすのか理解できません。または、単純なアクターモデル（複数のプロセッサアクター+メモリアクター）を検討してください。
繰り返しますが、これは非定型の設計のようです。 「記憶アクター」とは何でしょうか？なぜ処理を状態から分離するのですか？
既存のソリューションを根本的に異なるアーキテクチャに移行しようとしているように感じますが、これは間違いなく失敗します。アクターを慣れ親しんだ方法で動作させるのではなく、別のアプローチが必要になることを受け入れる必要があります。アクターベースのシステムの設計について何かを読むことは価値があると思うかもしれません。 " リアクティブデザインパターン "。
アクターモデルは、すべての問題を魔法のように解決するわけではありません。それは、ソリューションについての推論を助ける並行プログラミングのそのような抽象化を行うだけです。
アクターモデルには2つの主要な側面があり、私の練習で非常に役立ちます。
まず、ITがビジネス上の問題を解決するとき、ITが行うことは、ビジネスプロセスとルールをコンピューターの言語に効果的に変換することです。しかし、ビジネスプロセスは、いくつかの組織構造の人々を中心に構築されています。そして、アクターは、内部状態や監視を共有するのではなく、監督によってこの構造を適切にモデル化します。次に、ビジネスプロセスは人によって人のために構築されます。したがって、ビジネスプロセスは人による推論を前提としており、通常は非常に理解しやすいものです。したがって、アクターを使用したモデリングは、ビジネス上の問題と非常によく一致し、人間の脳に適合します。
第二に、アクターは、タイムアウト、危険なタスク、短絡、指数関数的な再試行などのモデリングに非常に役立ちます。繰り返しますが、監視と監視が役立ちます。
トランザクションに関する限り、最初に述べた側面はそれらをカバーします。トランザクションは、人間の世界で使用されているのと同じように、アクターを使用してモデル化できます。考える 二人の将軍問題 。アクターの通信は非同期です。アクターを使用する場合-あなたはそれと一緒に住んでいます。したがって、少なくとも1回の配信（確認応答を追加した場合）または最大1回の配信（Akkaのデフォルト）のいずれかがあります。したがって、問題に適合するものを選択し、それを使用してトランザクションをモデル化します。おそらくコードの行数が増えることで終わりますが、利点は、抽象化が簡単で、すぐに使用できるスケーラビリティです。
また、アクターモデルのすべての言及された品質により、イベントソーシングの有無にかかわらず、ヘキサゴナルアーキテクチャに基づくドメイン駆動設計に理想的に適合していることを付け加えておきます。私のAkkaの使い方はそれだけです。そして、DDDはドメイントランザクションについて非常に懸念しています。
Akkaのようなフレームワーク、またはイベント駆動型同時実行モデルに基づくより広範なフレームワークは、主に、最も効率的な方法でワークロードを並列化することにより、処理能力の使用を最適化します-スレッド間のコンテキスト切り替え、I/O操作のブロック、およびCPUバウンドタスクで飽和したCPUあたりのスレッドサイズのプールを維持します。
Akkaの場合、共有の可変状態へのアクセスの問題もありませんが、単一のアクターの境界内に限られます（事実上、アクターは、ロックの処理やスレッドのブロックを必要とせず、デッドロックの可能性のない同期リソースです）。これは、アクセスをシーケンシャルにすることで実現します。もちろん、共有された可変状態を一貫した方法で処理し、複数のアクター間で操作のアトミック性を処理するという問題は残ります。
したがって、アクターモデルが共有状態の問題を完全に解決するわけではないという点であなたは正しいですが、誰も実際にそう考えていないので、あなたはあなた自身の主張を否定しています。