0

現在、ロードバランサーを実装しようとしていますが、少しスピードバンプにぶつかっています。状況は次のとおりです（簡略化）。

  • worker_aによって処理されるリクエストqueue_aのキューがあります
  • worker_bによって処理されるリクエストqueue_bの 2 番目のキューがあります。
  • そして、いずれかのワーカーに送信できる3 番目のリクエスト キューqueue_cがあります。

この種のセットアップの理由は、各ワーカーにはそのワーカーだけが処理できる固有の要求があるためですが、誰でも処理できる一般的な要求もあります。

基本的に、 C5 IntervalHeapの 3 つのインスタンスを使用してこれを実装するつもりでした。各ワーカーは、そのローカル キューと、その一部である共有キューにアクセスできます (たとえば、worker_a は queue_a と queue_c を見ることができます)。

この考え方の問題点は、ローカル キューに要求があり、共有キューに同じ優先度の要求がある場合、どちらを最初に処理する必要があるかを判断できないことです (通常、IntervalHeap は先着順です)。その場合は先着順）。

編集: IntervalHeap が同じ優先度の要求を持つ先着順サーバーではないように見えることを発見しました!

比較的高いスループットと時間に敏感になるため、キュー全体のロックを最小限に抑えたいと考えていますが、現時点で私が考えることができる唯一の方法は、3 番目のキューが削除され、共有リクエストが両方に配置されるという、より多くの複雑さを伴います。 queue_a と queue_b。リクエストが吸い上げられると、それが共有リクエストであることがわかり、他のキューから削除する必要があります。

それが十分に明確に説明されていることを願っています!

4

2 に答える 2

1

ワーカーを同期すると、リソースの同じプールとプライベート キューを共有できます。ワーカー 1 のキューには 1 つのアイテムがあり、共有キューには 1 つのアイテムがあります。ワーカー 1 が最初に共有キューのアイテムを取得すると、並列実行が制限されるため、残念です。むしろ、worker 1 が最初にプライベート アイテムを取得するようにしますが、これは新しい警告につながります。1 つは、worker 1 と worker 2 の両方がプライベート アイテムの処理に忙しいため、古い共有アイテムは取得されないということです。

複雑さを抑えようとしても、これらの問題に対処するソリューションを見つけることは非常に困難です。簡単な実装は、プライベート キューが空の場合にのみ共有アイテムを処理することです。これは、高負荷のシナリオで優先順位が正しく処理されない部分には対処しません。(たとえば、プライベート キューが常にいっぱいであるため、共有キューが処理されない場合)。このバランスをとるために、他のワーカーのプライベート キューが空の場合にのみ、最初にプライベート キューを処理することをお勧めします。共有アイテムよりもプライベート キュー アイテムが優先されるため、これはまだ完全な解決策ではありません。この問題に再び対処するには、複数の戦略を設定することで達成できますが、ここではさらに複雑になります。

それはすべてあなたの要件に依存します。

于 2012-07-11T02:50:02.540 に答える
1

どのように配置しても、最悪の場合、2 つのワーカーだけで同じ優先度の 3 つのことを実行することになります。次のタスクを取得するキューを選択するために、優先度を超えて適用できるタイ ブレーク基準は何ですか?

以下に 2 つのアイデアを示します。

  1. キューをランダムに選択します。すべての優先順位は同じであるため、どちらを選択しても問題ありません。最悪の場合の平均では、すべてのキューがほぼ同じ速度で処理されます。

  2. 要素数が最大のキューから取得することで、キューの長さを最小限に抑えます。これにより、1 つのキューのフィル レートが他のキューより一貫して高い場合、他のキューが枯渇する可能性があります。

HTH

于 2012-07-10T06:49:47.853 に答える