現代の分散アプリケーションでは、サービス要求が処理からなる物理マシンまたは仮想マシンのサーバー・プールです。設計およびそのような実装方法を、通常、サーバプールは巨大であり、サービス能力は、種々の要因ネットワーク、メモリ、CPU、および他の下流サービスを受け、変動し、サーバサービスの容量は動的変化に常に状態を安定させますロードバランシングアルゴリズムシステムは困難な問題です。
需要の背景のアダプティブ負荷分散
ロードバランシングは、主に2つの目的があります。
- 要求応答時間が短く、小さなブロッキング確率を保持します。
- 制御可能なレベルでバランシングアルゴリズムオーバーヘッド負荷は、あまりにも多くのCPU、ネットワークおよびその他のリソースを取ることはありません。
アダプティブ負荷分散がビジー、システムがアイドル状態であるかどうかを意味し、または定常状態システム全体が常に良好なパフォーマンス、無飢餓や過負荷、一顧を維持しているように、ロードバランシングアルゴリズムは、自動的に、能力評価システム、合理的な流れ分布を提供しますマシン。
今日の電気ビジネスシステム、データセンター、クラウドコンピューティングや他の地域のためにこのアルゴリズムに必要な、資源の合理的利用に動的負荷分散を使用し、パフォーマンスを向上させます。例えば、二重11ゼロで、支払指図は、ユーザが、システム全体の要求レートは、ピーク電力会社に到達フォーカス。これらの要求は、フローサーバーのほんの一部に割り当てられている場合、マシンは要求レートが処理速度よりもはるかに多くなります受け取り、新しいタスクの処理時間、タスクが要求蓄積を生成します。
ユーザーの場合は、タスクの蓄積たら遅くなったりしても、タイムアウトを要求し、深刻な衰退を経験し、さらにリードサービスが利用できないでしょう。それが敗北するまでマシンは、原因より多くの深刻な課題の過負荷の蓄積に要求を処理します。アプリケーション全体が使用できなくなるまでの残りはまだ他のマシンのダウンタイムは徐々にこの手順では、システム障害が繰り返されます。
これを防ぐために、我々は共通のアプローチを考えることがあります。オンラインサービス要求率が制限値よりも大きいときサービスは、電流制限値としてボリュームを使用して、圧力測定の前に、事前にオンライン圧力測定を実施し、サービスを保護するために、サービスの新サービス拒否は、常に利用可能です。しかし、このアプローチはまた、問題がある：試験圧力試験は容量が通常保守的であり限定的な実行したとき、異種システムの完全な性能を実現できない。知的能力を応答することができない原因ネットワークに低下し、他の問題に起因する下流サービスの変更システムは、まだダウンタイムのリスクが存在します。
したがって、私たちはより良いトラフィックスケジューリングを割り当てると安定性、極端なパフォーマンスの追求、挑戦を保護し、現場で大ピア・トラフィックのピークを促進するために、適応型負荷分散アルゴリズムの性能を持っている必要があります。
複合ミドルウェアパフォーマンスチャレンジカップのタイトル
我々は予備的なシナリオ「第五ミドルウェアのパフォーマンスの挑戦は」適応負荷分散の設計と実装についての基本的な考え方を一緒に探ることである組み合わせ。
チャレンジシーン、サービス呼び出し側（消費者）と3つの異なる仕様は、プログラム（アリクラウドのパフォーマンス・テスト・PTS）（プロバイダ）コンポーネントによって、サービスプロバイダに圧力をかけます。評価プロセスでは、各プログラムは、最終的な評価結果に影響を与える評価プログラムジッタが得られ、競争のCPU、ネットワーク・リソースを避けるために、異なる物理マシン上に展開されます。
三つの異なる物理仕様、サービスの応答時間と最大同時から、要求を受領して消費者、消費者の要求に責任が異なるプロバイダですBecnhmarker、コールを選択し、結果を返します。どのプロバイダ選択プロセスを実現することが課題でロードバランシングアルゴリズムと呼ばれています。
展開を簡素化し、サービスの登録と発見メカニズムを使用せずに挑戦中の環境性能を向上させるためには。プロバイダ対応する3つのURLを直接消費者に配置されている、開発中の選手と直接テストするには、プロバイダ、小さな等により、対応するプロバイダのホスト名にアクセスします。
タイトルマッチ分析
トピックの記述が非常に簡単で、消費者向け拒否を考慮せずに、シーンは3対1を出すように簡略化することができますが、この決定は、チャレンジ検査では困難かつ重要ですか。
ランダムに選択されたのいずれかから3プロバイダ：デフォルトのアルゴリズムが実装されるようなランダム正式タイトルグループを提供します。シングルのためのディスパッチャ（このレースで消費者に問題がある）シーン均一系、ランダム漸近的には、受信近いプロバイダの総数あたりのバランス要求をロードすることができます。しかし、グローバル状態の欠如にマルチディスパッチャまたは不均一系、ランダムアルゴリズムのために、私たちは、グローバルランダム保証することはできません極端な条件の下で、ディスパッチャは、同時にプロバイダに割り当てられた複数の要求過負荷にするためのシステムおよびプレゼンスサービスのダウンタイムを引き起こす可能性がありリスク;異種システム、異なるサービスプロバイダの実際の容量は自由、安定した、さまざまなサービスの過負荷状態の同じ速度を生成する各プロバイダの要求は、最適なトラフィック分布が達成できない場合でも、異なっているが、応答時間を達成することはできません最小。明白な、ランダムな適応アルゴリズムは、タイトル争いの要件に沿ったものではありません。
だから、どのように適応ロードバランシングそれを達成するには？️次は、私たちは、このアルゴリズムの設計プロセスへの漸進的なアプローチを説明した条件指定されたタイトルを使用します。
適応アルゴリズムは、最初のサービスの能力を評価する方法の問題を解決しなければなりません。
3：2：異なるハードウェア仕様に従ってゲームは、プロバイダは、対応する1ため、小、中、大、および比、CPU、およびメモリの3種類に分けられます。評価プロセスでは、動的に主として応答時間と許容における同時単一変化の最大数に、各プロバイダの処理能力を変更しています。要求レートが消費者から速すぎる場合には、スレッドの数と、キューに入れられた作業スレッド数とスレッドの最大数、スレッドプールの枯渇プロバイダが異常戻ったときに、エンド新しいプロバイダのリクエストは、処理のためにキューに入れられました。実装と調整アルゴリズムの過程では、キューイングを減らすために異常なスレッドプールを回避しようとしてください。ボトルネックの異なる段階を区別するために、良いプログラムとハードウェアの制限をどのように組み合わせるか、難しさの現実的な評価をする能力は、最初のタイトルマッチです。パラメータの場合や、既存の理論だけで使用されるこの主題のコースを変更し、最高を達成するために、ハード練習、選手は完全に質問や構成のパラメータの意味を理解する必要があるので、設計アルゴリズムは、実際のシーンに適しています。
考慮すべき第二の問題は、それはプロバイダのサービス機能に代わって状態を維持するために、どのようにプロバイダのステージは、これらの状態に基づいて意思決定を選択する方法で、どのようにキャパシティ・アセスメントの結果を適用するのですか？
全て均一系で維持ディスパッチャプロバイダによってディスパッチャ従来の単一負荷分散モデル状態は、このアプローチは、漸近最適な負荷分散を実現することができます。しかし、それはまた、明らかな問題である：プロバイダの数が、またメンテナンスDispatcherは指数関数的に増加し、通信コストが増加している必要とする場合、単一の天然ディスパッチャパフォーマンスのボトルネック、貧しい人々スケーラビリティは、指数関数的に増加しています。困難さを軽減する、ないマルチトピックディスパッチャモデルを構築するためにはチャレンジが、より多くのディスパッチャは、マルチプロバイダサービスはダボと実際の運用環境で他のマイクロフレーム、最も一般的な状況です。そのため、高いパフォーマンスと拡張性の良好なバランスアルゴリズムは、素敵なボーナスアイテムになります。
第三の点は、補助インタフェースを使用することです。アルゴリズムの設計思想を限定するものではないために、タイトルマッチは、双方向通信、制限プロバイダの現在のサポートを含む、使用可能な補助インターフェイスの数を、提供します。これらのインタフェースを使用する必要がアルゴリズムの実装に依存している場合でも、これらのインタフェースは、非必須です。
評価環境では、プロバイダのサービス要求率のいずれかが評価プロセスの処理速度よりも小さいです。プロバイダ3つの全体の処理速度がレート要求を下にフロートします。要求の最終結果は成功と失敗した要求からなるTPSの最大数は、傾斜されません。この制限は、サービスが重くロードされていないことを保証するために、最初の2つの方法で解釈することができるため、適切に要求を拒否することができます。第二の点は、合理的な数は、適した過負荷が許可されているプロバイダーの要求の最適なパフォーマンスを確保するために、各サービスプロバイダの能力を作るために必要です。
唯一のより多くの主要なアルゴリズム設計のアイデアとして、プロジェクトに実装優れた負荷分散アルゴリズムも非常に重要なポイントである、ゲーム環境のうち、パフォーマンスのすべてのビットを絞る、適切なデータ構造、メモリとCPUをフルに活用を選択する必要があります。もちろん、評価スコアが大きな割合のためにすべて、良いコードの構造、スタイルと汎用性をコーディングするだけでなく、最終予選の結果アカウントではありません。
レビュートーナメントタイトル
核環境によって評価テーブル4。8Gプレス機、ゲートウェイマシン8Gコア4,4-コア8Gプロバイダ組成物の三。コンシューマとプロバイダプログラムは、各評価タスクのCPUとメモリ使用量が排他5台のマシンになります制限されます。
- 作成、サブ環境を実行する準備ができましたし、ロックされたワークスペース。
- アドレスGitはコードリポジトリプルからコードを提出しました。
- 建物コード、実行最終的な脂肪JARを生成します。
- 3つのプロバイダを起動し、サービスの可用性を検証します。
- 消費者を起動し、サービスの可用性を検証します。
- 30秒間のシステムを予熱。
- 1分の正式な評価。
- 天池はシステムを報告し、最終的なスコアとして成功した要求と最大TPSの総数の正式な評価を取ります。
- 消費者を停止するためによると、3つのプロバイダ。
- クリーニングとドッカーミラーの例。
- ログを収集し、OSSにアップロード。
- 作業領域のロックを解除し、環境をクリーンアップします。
概要
本論文では、第五ミドルウェアパフォーマンスチャレンジトーナメントタイトルの背景、タイトルシーン、ビューの環境・プロセスポイントのタイトルの分析と評価、バランシングアルゴリズムの基本的なデザインのアイデア適応負荷を導入し、期待して学生が持っている競争に参加しますヘルプはまた、私たちの技術的な課題に入学アルゴリズムであなたの思考と実践を共有するためのより多くの学生を歓迎しています。
オリジナルリンク
この記事Yunqiコミュニティのオリジナルコンテンツが許可なく複製することはできません。