私は、エルラン・トークで言及されたデザイン・パターンを理解しようとしています。 本質的に、スピーカーは、プロセスとしてジョブを使用するのではなく、「プロセスとしてのメッセージ」を使用してワークキューを使用することについて言及しています。"プロセスとしてメッセージ"作業キューのErlangデザインパターンとは何ですか？
"プロセスとしてのメッセージ"を使用することで、シリアライゼーション/デシリアライゼーションのオーバーヘッドを節約できます。
おかげ
はMは、我々はシステムに周り送るメッセージあるErlangの用語（）とします。 Mを処理する明白な方法の1つは、プロセスとキューのパイプラインを構築することです。 Mは、パイプラインの最初のワーカーによって処理され、次のキューに送られます。その後、次のワーカー・プロセスによってピックアップされ、再度処理されてキューに入れられます。メッセージが完全に処理されるまで続きます。
おそらくそれほど明白でない方法は、プロセスPを定義してからMをPに手渡すことです。私たちはそれをP(M)とします。ここでメッセージ自体はプロセスであり、データではありません。 Pは、作業者がキューソリューションで行った作業と同じ作業を行いますが、Mを待ち行列に戻して再度取り出すなどのオーバーヘッドを支払う必要はありません。処理P(M)が完了すると、プロセスの寿命は単に終了します。 M'という別のメッセージを渡した場合、単にP(M')を生成して、そのメッセージを同時に処理させます。一連のプロセスがある場合は[P(M) || M <- Set]などとなります。
Pは、メッセージを「偽装する」ことなく、同期またはメッセージングを行う必要があります。はメッセージであるため、です。作業者がそれに沿って来るメッセージに対して責任を負わなければならないワーカー・キュー・アプローチとは対照的です。 Pにエラーがある場合、エラーの影響を受けるメッセージP(M)のみがクラッシュします。ここでも、パイプラインのクラッシュが他のメッセージ（パイプラインがひどく設計されている場合）に影響を与えるワーカー・キュー・アプローチと対照的です。
結論としては、メッセージをになるメッセージに変えて、というメッセージが表示されます。
イディオムは「メッセージごとに1つのプロセス」であり、アーランではかなり一般的です。新しいプロセスを作るための価格とオーバーヘッドは、これが機能するには十分に低いです。しかし、アイデアを使用する場合は、何らかの過負荷保護が必要な場合があります。その理由は、おそらく同時リクエストの量に制限を設定したいからです。制御システムの負荷ではなく、サーバーを盲目的に破壊させるためです。そのような実装では、Erlangのソリューションによって作成されたジョブズ、
を見ているとウルフWigerはでそれを提示している：ウルフは話にヒントとして、私たちは通常ます
http://www.erlang-factory.com/conference/ErlangFactoryLiteLA/speakers/UlfWiger
P以外のいくつかの前処理を行い、メッセージを解析し、Erlangシステムに内部化します。できるだけ早く、メッセージMをジョブにプロセス（P(M)）でラップして作成します。したがって、Erlang Schedulerの利点はすぐに得られます。
この選択には別の重要な影響があります。処理に時間がかかる場合、Erlangのプリエンプティブスケジューラは処理の必要性の低いメッセージを迅速に処理できるようにします。限られた量のワーカー・キューがあると、それらの多くが詰まってしまい、システムのスループットが低下する可能性があります。
お話をするにはどうすればいいですか？ – grifaton
私は話も見たいと思います。私が正しく答えることができると感じる前に、いくつかの文脈があります。 –
12.00分マークhttp://www.erlang-factory.com/conference/SFBay2010/speakers/jackmoffit – user407601