私はリクエストの99％がDBコールをブロックするakkaシステムを持っています。ベストプラクティスで説明されているように、別のディスパッチャ\スレッドプールでブロック操作を実行するようなシステムにメリットがあるかどうかは疑問でした。アクカとブロッキング操作
akkaスレッドはアイドル待機中ですが、スレッドプールタスクキューはオーバーフローメモリでも、新しいタスクも拒否することもできます。
これはよくある質問ですが、関連する記事やディスカッションは見つかりません。
AkkaプロジェクトはReactive Manifestoを非常に支持しています。このドキュメントでは、Akkaを使用することによって、Reactive Manifestoに基づいてシステムを構築することにも興味があると仮定しています。
リアクティブマニフェストの重要な部分は、システムが常に応答し続ける必要があるということです。メインのAkkaルーティングインフラストラクチャと同じディスパッチャ/スレッドプールをDB操作のブロックに使用した場合、すべてのAkkaスレッドがDB操作で占有されている可能性があり、システムがデッドロックされる可能性があります。操作が完了しました。これは、このタスクを実行する単一のJVM上の単純なシステムのための問題ではないかもしれませんが、それはこの問題になるだろう新しい機能を考えるのは簡単だ：
別の理由で別のディスパッチャが役立つ可能性があります。おそらく、データベースへのアクセスを制限して、システムがデータベースに過負荷をかけないようにする必要があります。 DBディスパッチャーを固定サイズのスレッドプールにして、データベースリクエストを抑制するための粗いが効果的な方法として使用することができます。代わりにあなたの俳優といくつかのバッファを実装することですが、これは余分なコードがたくさん必要になります（あまりにも多くのタスクなどのためにメモリ不足を心配している場合は、
ありがとう、私は前にハートビートのようなシステムメッセージについて考えなかった。 DBスレッドプールのタスクキューで起こりうるOOMの問題に対処するために、「あなたのアクター内のいくつかのバッファ」について読むことができるところを教えてください。 – lotror
あなたのブロッキングDBのアクター上の限定メールボックスが一方向ですが、リクエスターはタスクが受け入れられたかどうかを知りません。ノンブロッキングアクターに最大サイズの要求キューを維持させることができます。進行中の処理があまり多くなければ、ブロッキングDBアクターに転送したり、キューに追加したり、キューが満杯になった場合に拒否メッセージを送信したりすることができます。 DBアクタが応答すると、元のリクエスタに応答するためにリクエストIDを使用できます。キューからリクエストを削除し、アクティブなリクエストの数を減らします（DBアクタに次のリクエストを転送します）。 – tonicsoft
http://doc.akka.io/docs/akka/2.5/scala/dispatchers.html#blocking-needs-careful-management – chunjef
@chunjefありがとう、私はこれまでに読んだことがありますが、私の質問が「すべての俳優/操作がブロックしている場合に何か利点があるかどうか」をブロックしていない俳優 – lotror