最近、akka のアクターと http モジュールをいじり始めました。しかし、私はかなり面倒なちょっとした癖に出くわしました。つまり、singelton アクターを作成することです。
以下に 2 つの例を示します。
1)
私はインメモリ キャッシュを持っています。私のサービスは非常に小さい (むしろアプリです) ので、イン メモリ モデルが本当に気に入っています。ユーザーに関連するほとんどの情報をマップ (リストのマップですが、構造については非常に簡単に推論できます) に保持でき、redis、geode、または aerospike のオーバーヘッドと複雑さは得られません。
唯一の問題は、このメモリ内キャッシュが複数のソースによって変更される可能性があり、その変更が同期的でなければならないことです。この構造の 3 つのアクセス メソッドすべてを同期化する (たとえば、メッセージ キューを構築するか、ロックを実装する) 代わりに、構造とそのアクセス メソッドをアクターにラップし、メッセージ キューを構築し、簡単な receive->send ロジックとスケールアップした場合、専用のメモリ内データベースを介して DA アクターに簡単に置き換えることができます。
2）さまざまなジョブのアクターをディスパッチするために使用する必要がある「サービス」レイヤーがあります（データベースへのアクセス、メモリ内キャッシュへのアクセス、データを使用したこの計算の実行、結果のユーザーへの配信など）。
このサービス層が一種の「シングルトン」であり、いくつかの機能の閉鎖であることは理にかなっているアクター/スレッド/作成する必要があり、リクエストが送信される場所)
ただし、これには次のいずれかが必要です。
a) 両方のオブジェクト シングルトン アクターを作成するか、
b) 両方のオブジェクトを実際の「オブジェクト」にする (そのスコープにクロージャーを持つ関数を持つ単一の名前付きシングルトンを指定する scala オブジェクト表記のように)
b) には多くの問題があります。つまり、サービス レイヤーは、独自のアクターを作成するのではなく、アクター システムを「渡す」必要があります (それがベスト プラクティスかどうかはわかりません)。 「子供」は、グローバルアクターシステムを使用して子供を作成し、メッセージングおよび監視ロジックははるかに厄介で直感的ではありません. また、メモリ内キャッシュには、組み込みのメッセージ que の利点がありません (これを実装するのが難しいと言っているわけではありませんが、これは、「ああ、ジョリー、それは良いことです。私にはアクターがいて、このコードの実装とテストに時間を費やす必要はありません」)
a) akka のドキュメントでは、一般的に文書化が不十分であり、アドバイスされていないという問題があるようです。つまり：
http://doc.akka.io/docs/akka/2.4/scala/cluster-singleton.html
このたわごとを見てください、ドキュメントの半分はそれを使用することに対して警告しています.
それで、ああ。シングルトンアクターを使用するのがなぜ悪いのか説明してくれる人はいますか? シングルトンがアクターになれない場合、どのようにシングルトンを設計しますか? 将来的に大きなダメージを与えないシングルトン アクターを設計する方法はありますか? インスタンス化されるのではなく呼び出される「グローバル」サービスを持つ「サービス」モデル全体は、「un akka like」ですか?