アーラントークで言及されたデザインパターンを理解しようとしています。基本的に、スピーカーは、ジョブをプロセスとして使用するのではなく、「メッセージをプロセスとして」使用してワークキューを使用することに言及します。
重要なアイデアは、「プロセスとしてのメッセージ」を使用することにより、シリアル化/逆シリアル化のオーバーヘッドを節約できるということです。
ありがとう
1691 次
1 に答える
16
システム内で送信するメッセージであるErlang Mterm() とします。対処する明白な方法の 1 つは、プロセスとキューのパイプラインを構築することです。パイプラインの最初のワーカーによって処理され、次のキューに送信されます。その後、次のワーカー プロセスによって取得され、再度処理されてキューに入れられます。メッセージが完全に処理されるまで続きます。MM
おそらくそれほど自明ではない方法は、プロセスを定義してPから に渡すMことPです。と表記いたしますP(M)。メッセージ自体はプロセスであり、データではありません。ワーカーがキュー ソリューションで行ったのと同じジョブを実行しますが、バックをキューに貼り付けたり、再度取り出しPたりするというオーバーヘッドを支払う必要はありません。M処理P(M)が完了すると、プロセスは単純に寿命を迎えます。別のメッセージが渡された場合M'は、単純にスポーンP(M')してそのメッセージを同時に処理させます。一連のプロセスを取得したら、[P(M) || M <- Set]それを行います。
同期またはメッセージングを行う必要がある場合P、それはメッセージであるため、メッセージを「偽装」する必要なく行うことができます。ワーカーがそれに伴うメッセージに対して責任を負わなければならないワーカーキューアプローチとは対照的です。エラーがある場合、エラーの影響を受けPたメッセージのみがクラッシュします。P(M)ここでも、パイプラインのクラッシュが他のメッセージに影響を与える可能性があるワーカー キュー アプローチとは対照的です (ほとんどの場合、パイプラインの設計が不適切な場合)。
結論の秘訣は、メッセージをメッセージになるプロセスに変えることです。
このイディオムは「メッセージごとに 1 つのプロセス」であり、Erlang では非常に一般的です。新しいプロセスを作成するコストとオーバーヘッドは、これが機能するほど十分に低いです。ただし、このアイデアを使用する場合は、何らかの過負荷保護が必要になる場合があります。その理由は、同時要求の量に制限を設けて、システムの負荷を制御し、やみくもにサーバーを破壊するのではなく、システムの負荷を制御したいからです。そのような実装の 1 つが、Erlang Solutions によって作成されたJobsです。
Ulf Wiger は次の場所でそれを発表しています。
http://www.erlang-factory.com/conference/ErlangFactoryLiteLA/speakers/UlfWiger
PUlf が話の中で示唆しているように、メッセージを解析して Erlang システムに内部化するために、通常は外部で何らかの前処理を行います。しかし、できるだけ早くメッセージをプロセス ( ) でラップしMてジョブP(M)にします。したがって、Erlang Scheduler のメリットをすぐに享受できます。
この選択には、もう 1 つの重要な影響があります。メッセージの処理に時間がかかる場合、Erlang のプリエンプティブ スケジューラは、処理の必要性が少ないメッセージでも迅速に処理されるようにします。ワーカー キューの数が限られている場合、それらの多くが詰まる可能性があり、システムのスループットが妨げられます。
于 2011-01-03T16:41:41.833 に答える