目次
分散トラフィック保護 - フロー制御効果のコールド スタート
分散トラフィック保護_サーキットブレーカーのダウングレードの呼び出しが遅い
分散トラフィック保護 - フロー制御効果のコールド スタート
ウォームアップはウォームアップ モードとも呼ばれ、サービスのコールド スタートに対する解決策です。
ケーススタディ
要件: リソース /payment/index の現在の制限を設定します。最大 QPS は 10、ウォームアップ効果を使用し、ウォームアップ時間は 5 秒です。
Jmeterテスト
結果ツリーを表示する
注: QPS は 10 です。開始したばかりのときは、ほとんどのリクエストが失敗し、成功したリクエストは 3 つだけでした。これは、QPS が 3 に制限されていることを示しています。時間の経過とともに、成功率はますます高くなっています。
リアルタイムのエフェクトフィードバック
1. Sentienl フロー制御効果のコールド スタートは、主に _____ 問題を解決します。
ソース構成項目の場合は A
B 失敗が早い
Cサービスは開始されたばかりで、すべてのリソースが初期化されていません
上記はすべて間違いです
2. Sentienl フロー制御効果のコールド スタートは ____ モードとも呼ばれます。
ウォーミングアップ_
B 失敗が早い
C協会
Dリンク
分散トラフィック保護_キューイングとフロー制御効果の待機
キューイングとは、すべてのリクエストをキューに入れ、しきい値で許可された時間間隔に従って順番に実行することです。後続のリクエストは、前の実行が完了するまで待機する必要があり、リクエストの予想待機時間が最大時間を超える場合は拒否されます。
動作原理
例: QPS しきい値は 5 で、これはキュー内のリクエストが 200 ミリ秒ごとに処理され、タイムアウト期間が 2 秒であることを意味します。現在 100 個のリクエストがあり、サーバーは最大 5 個まで処理でき、残りはゆっくりとキューに入れられます。
キューイングモードを使用しない場合、現在 12 個のリクエストが来ており、最初の 1 秒間で同時に 10 個のリクエストが受信されますが、次の 1 秒間で受信されるリクエストは 1 つだけであり、このときの QPS カーブは次のようになります。
フロー制御にキュー モードを使用する場合、すべての受信リクエストはキューに入れられ、200 ミリ秒の固定間隔で実行される必要があり、QPS は非常にスムーズになります。
注: 滑らかな QPS 曲線は、サーバーにとってよりフレンドリーです。
アプリケーションシナリオ
注: この方法は主に、メッセージ キューなどの断続的なバースト トラフィックを処理するために使用されます。特定の秒間に大量のリクエストが到着し、その後の数秒間がアイドル状態になるシナリオを想像してください。最初の 1 秒間で冗長なリクエストを直接拒否するのではなく、システムが次のアイドル期間中にこれらのリクエストを徐々に処理できることを期待します。
ケース
要件: リソース /payment/queue の現在の制限を最大 QPS 10 で設定し、キューイングのフロー制御効果を使用し、タイムアウト期間を 5 秒に設定します。
Jmeterテスト
QPSは15で、設定した10を上回りました。以前の高速障害およびウォームアップ モードの場合、超過リクエストはエラーを直接報告する必要があります。ただし、キュー モードの実行結果を見てみましょう。
リアルタイムのエフェクトフィードバック
1. Sentienl フロー制御エフェクトのキューアップは主に _____ 問題を解決します。
均一な流量
B 安定した大流量
Cバーストトラフィック
上記のDはすべて間違っています
分散トラフィック保護_ホットスポットパラメータの電流制限
以前の電流制限は、特定のリソースにアクセスするすべてのリクエストをカウントし、それが QPS しきい値を超えているかどうかを判断することでした。ホットスポットパラメータの電流制限は、同じパラメータ値を持つリクエストを個別にカウントし、QPSのしきい値を超えているかどうかを判断します。
グローバルパラメータの電流制限
たとえば、ID で製品をクエリするためのインターフェイスは次のとおりです。
/goods/{id} へのアクセス要求では、id パラメーターの値が変更され、ホットスポット パラメーターの電流制限により、パラメーター値に応じて QPS が個別にカウントされます。統計結果は次のとおりです。
id=1 のリクエストによってしきい値が制限される場合、id 値が 1 以外のリクエストは影響を受けません。
構成例:
注: ホット リソースのパラメータ 0 (最初のパラメータ) に関する統計を作成します。同じパラメータ値に対する1 秒あたりのリクエスト数は 5 を超えることはできません。
ホットスポットパラメータの電流制限
先ほどの設定では、製品を問い合わせるインターフェイスのすべての製品が同等に扱われ、QPS は 1 に制限されます。実際の開発では、フラッシュセール商品などの人気商品もあるかもしれませんが、そのような商品の QPS 制限は他の商品とは異なり、より高いことが望まれます。次に、ホットスポット パラメータの電流制限の詳細オプションを設定する必要があります。
注: 前の設定と組み合わせると、ここでの意味は番号 0 のロング型パラメータの電流を制限することであり、同じパラメータの QPS は 2 つの例外を除いて 5 秒あたり 5 を超えることはできません。パラメータ値が 100 の場合、1 秒あたりの許容 QPS は 10 です。パラメータ値が 101 の場合、1 秒あたりの許容 QPS は 15 です。
ケースの要件
ホットスポット パラメーターの現在の制限をリソース /order/findById に追加します。ルールは次のとおりです。
デフォルトのホットスポット パラメータ ルールでは、1 秒あたりのリクエスト数は 2 を超えてはなりません。
パラメータ 102 に例外を設定します。1 秒あたりのリクエスト数は 4 を超えてはなりません。
パラメータ 103 に例外を設定します。1 秒あたりのリクエスト数は 10 を超えてはなりません。
注: ホットスポット パラメーターの現在の制限は、デフォルトの SpringMVC リソースに対して無効であり、リソースをマークするには @SentinelResource アノテーションを使用する必要があります。
@RestController
@RequestMapping("goods")
public class GoodsController {
/**
* 热点key限流
* @param id
* @return
*/
@GetMapping("findById")
public String getGoods(String id){
return id;
}
}ホットスポットパラメータの電流制限ルール
Jmeterテスト
リアルタイムのエフェクトフィードバック
1. Sentienl ホットスポット キーの電流制限は主に _____ 問題を解決します。
均一な流量
B 上流インターフェースの電流制限
Cインターフェース電流制限
D同じパラメータ値を持つリクエストの個別の統計
2. Sentienl リソースを構成してホットスポット キー電流制限ルールを構成し、電流制限に特定のパラメーター値を 102 として指定する方法_____。
パラメータ設定
B フロー制御ルール
Cヒューズのルール
D 権限ルール
分散トラフィック保護_スレッド分離
スレッド分離 (バルクヘッド モード)
1. スレッドプールの分離
2. セマフォ分離 (Sentinel はデフォルトで使用します)
知らせ：
スレッド プールの分離: 各サービス呼び出しビジネスにスレッド プールを割り当て、スレッド プール自体を使用して分離効果を実現します。
セマフォ分離: スレッド プールを作成する代わりに、カウンター モードを使用してビジネスで使用されるスレッド数を記録し、セマフォの上限に達すると、新しいリクエストが禁止されます。
センチネルのスレッド分離
スロットリング ルールを追加する場合、次の 2 つのしきい値タイプを選択できます。
知らせ：
QPS: 1 秒あたりのリクエスト数
スレッド数: このリソースで使用できる Tomcat スレッドの最大数。つまり、スレッドの数を制限することで、スレッドの分離 (バルクウォール モード) が実現されます。
流量制御テスト
新しいスレッドグループ
次のように、新しいスレッド グループを作成し、開始時に同時に 10 個のリクエストを送信します。
新しいHTTPリクエスト
ビュー結果ツリーの作成
リアルタイムのエフェクトフィードバック
1. Sentienl テクノロジーでセマフォ スレッド分離を実装する方法____。
閾値タイプ設定QPS
Bしきい値タイプはスレッド数を設定します
C ホットスポット ルールを選択する
上記のDはすべて間違っています
分散トラフィック保護_ヒューズのダウングレード
ヒューズのダウングレードは、雪崩問題を解決する重要な手段です。その考え方は、サーキット ブレーカーがサービス コールの異常な割合と遅いリクエストの割合をカウントし、しきい値を超えるとサービスが中断されるというものです。つまり、サービスへのアクセス要求はすべて傍受され、サービスが復元されると、サーキット ブレーカーはサービスへのアクセス要求を解放します。
サーキット ブレーカーの制御の溶断と解放は、ステート マシンを通じて行われます。
ステート マシンは 3 つの状態で構成されます。
1. クローズ: クローズ状態。サーキット ブレーカーはすべてのリクエストを解放し、例外と遅いリクエストの割合のカウントを開始します。閾値を超えるとオープン状態に切り替わります
2. open: オープン状態では、サービス呼び出しが中断され、中断されたサービスへのアクセス要求は拒否され、すぐに失敗し、ダウングレード ロジックに直接進みます。オープン状態で5秒後、半オープン状態になります。
3. ハーフオープン: ハーフオープン状態ではリクエストが解放され、実行結果に応じて次の動作が判断されます。リクエストの成功: クローズ状態への切り替え リクエストの失敗: オープン状態への切り替え
サーキットブレーカーのダウングレード戦略
遅い通話
サービス応答時間 (RT) が指定された時間を超えるリクエストは、低速通話リクエストとみなされます。指定された時間内に、リクエストの数が設定された最小数を超え、低速コールの割合が設定されたしきい値より大きい場合、サーキット ブレーカーがトリガーされます。
異常な比率、異常な数
指定時間内のコール数をカウントし、コール数が指定リクエスト数を超え、かつ異常の割合が設定した割合のしきい値に達した場合（または指定の異常数を超えた場合）、サーキットブレーカーが作動します。
リアルタイムのエフェクトフィードバック
1. Sentienl テクノロジーでは、以下はサーキット ブレーカーのダウングレード戦略に属します。____ です。
遅い通話
B 異常な比率
C例外数
上記はすべて正しいです
2. Sentienl テクノロジーのヒューズ ダウングレードにより、__ の問題が解決されます。
サービスの単一障害点
B サービスの高可用性
C サービスの応答が遅い
Dサービスアバランチ
分散トラフィック保護_サーキットブレーカーのダウングレードの呼び出しが遅い
平均応答時間 1 秒以内に 5 つのリクエストが入力され続け、その時点の平均応答時間 (第 2 レベル) がしきい値を超えると、次の時間枠内で、このメソッドへの呼び出しは自動的に中断されます (DegradeException がスローされます)。
新しいインターフェース
@GetMapping("/testC")
public String testC(Integer id){
if (id = 1){
try {
TimeUnit.SECONDS.sleep(1);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
return "------------testC";
}RT構成を追加しました
パラメーター: 50 ミリ秒を超えるリクエストは低速リクエストとみなされ、異常率が 40% に達すると、サーキット ブレーカーが開き (ヒューズがトリップ)、マイクロサービスが利用できなくなり、ヒューズがトリップして電源が切断されます。5 秒後、サーキットブレーカーがオープン状態から半オープン状態になり、いくつかのリクエストが届きます。
ジェメーターストレステスト
スレッドグループの作成
HTTPリクエストパスを設定する
テスト
-Jemeterを使用しないTest/testCインターフェース
Jemeter との Test/testC インターフェイス。
結果アクセスに失敗しました
注: 後で Jmeter を停止しました。それほど大量のアクセスはなく、サーキット ブレーカーが閉じられ (ヒューズが回復し)、マイクロサービスは正常に再開されました。
分散トラフィック保護_ヒューズ劣化率の異常
概要
1 秒あたりのリソース例外の総数とスループットの比率がしきい値を超えると、リソースは劣化状態に入ります。外れ値比率のしきい値範囲は [0.0,1.0] です。
新しいインターフェース
/**
* 测试异常比例
* RT 平均响应时间
* @return
*/
@GetMapping("testD")
public String testD(Integer id) {
if (id == 1){
throw new RuntimeException("故意抛出异常，触发异常比例熔断。");
}
return "testD";
}
サーキットブレーカーのルールを設定する
注: 5 つのリクエストでは、例外比率が 0.4 を超える限り、つまり 2 つ以上の例外がある限り、サーキット ブレーカーがトリガーされます。
ジェメーターストレステスト
スレッドグループの作成
HTTPリクエストを構成する
テストインターフェース
リクエストの送信 localhost:8001/testD?id=2
分散トラフィック保護_ヒューズ劣化数の異常
コンセプト
例外の数: 過去 1 分間のリソース内の例外の数がしきい値を超えると、サーキット ブレーカーが実行されます。
新しいインターフェース
/*
* 测试异常数
*/
@GetMapping("/testF")
public String testF()
{
int age = 10/0;
return "------testF 测试异常数";
}
外れ値ルールを構成する
注: 例外番号 5 を設定します。
テスト
http://localhost:8001/testF をリクエストすると、除数をゼロにすることはできないため、最初のアクセスでは間違いなくエラーが報告され、エラー ウィンドウが表示されます。
ただし、エラーレポートが 5 件に達すると、ヒューズに入った後、ダウングレードされます。
