問題タブ [actor-model]

私はしばらくアクター モデルを研究しており、それを RESTful API と正しく組み合わせる方法を見つけようとしています。ask-pattern または Actor-per-request を使用して、両方のレイヤーの責任を分離する方法に苦労しています。どちらのパターンでも、リクエストとリプライのセマンティクスがアクター モデルに漏れており、これはアンチ パターンのように見えます。HTTP 要求によって開始され、アクターに送信されるほとんどのメッセージには、応答が必要です。受信側のアクターには、リクエストを実行できない API を通知する必要がある複数の条件があります。

さらに、入力の検証に関して良い習慣と見なされるもの。これを HTTP の一部として実装する必要があります (たとえば、フィールド X が有効な電子メール アドレスである場合、フィールド Y が整数を保持している場合)。また、複雑なドメイン ロジックの場合、(事前) 条件が失敗した場合、アクターは送信者にどのように通知する必要がありますか?

私は Akka と Actor Model について読んでいますが、疑問が邪魔になります。各アクターが 1 人以上の受信者を持つことができることを知っています。私の質問は、受信者を複数のアクター間で共有できますか?

私のチームは、アクターをどの程度細かくするべきかについて議論しています。

例として、json 文字列をオブジェクトに逆シリアル化する役割を担うアクターがあります。アクターにすることを支持する議論は、逆シリアル化によってエラーが発生する可能性があり、アクターとその監視モデルが制御フローに使用される可能性があるというものです。

このタスクやその他の小さなタスクにアクターを使用することは良い考えですか?

AKKA.NET 受信関数内で SaveChangesAsync を使用してデータベースに変更を保存する際に問題があります。誰かが何が起こっているのか説明できますか?

詳細: 私はこの受信ブロックを持っています:

このように SaveChanges を使用するようにコードを変更すると、機能します。

using-block は新しい Autofac 依存関係注入コンテナー スコープを作成するため、using ブロックが終了すると、db-object が破棄されることに注意してください。これが問題だと感じています。ただし、それについて何をすべきか、dbcontext-object の有効期間を適切に延長する方法がわかりません。

現在のメッセージが処理されるのを必ずしも待たずにアクターを停止できるかどうか、または単にキャンセルできるかどうか疑問に思っていました。

ここでそれを行う方法を説明します

https://petabridge.com/blog/how-to-stop-an-actor-akkadotnet/

しかし、それらはすべて現在のメッセージが処理されるのを待ちます。

アクターを停止します。

現在のメッセージの処理が終了した直後にアクターを停止します。

アクターを殺す:

これにより、ログに記録されて処理される ActorKilledException がスローされます。アクターは、現在のメッセージの処理が完了するとすぐに停止します。

アクターに PoisonPill を送信します。

アクターは現在メールボックスにあるメッセージの処理を終了し、停止します。

Erlang は同時実行性をサポートするためにアクター モデルを使用し、Erlang プロセスはアクターと同じであることを知っています: メッセージを送信し、不変などです。しかし、Carl Hewitt によれば、アクター モデルで重要なことの 1 つは、不確定性とアービターです (アービターが与えられた場合、複数の入力 (I0 と I1 など) を同時にアービターに入れることができますが、考えられる結果 (O0 など) の 1 つだけです)。または O1) が反対側に出てきます)。

興味深いことに、Erlang はこの概念をどのように実装したのでしょうか? また、Erlang の同時実行モデル/アクター モデルの実装におけるアービターの役割には何が使われているのでしょうか?