SpringCloud Alibaba - Sentinel 電流制限ルール (ケース + JMeter テスト分析)

ソースの場合: デフォルトは、すべてのリクエストに対して有効です。通常、ここでは変更は行われません。
しきい値の種類: ここでは、1 秒あたりに処理されるリクエストの最大数である qps を使用します。
単一マシンのしきい値: 1 秒あたりに処理されるリクエストの最大数を設定します。
トラフィックモード: ここには 3 つのタイプがあります。現在、最初のタイプを見ていきます。これは、現在のリソース要求をカウントすることです。単一マシンのしきい値を超えると、フローが制限されます。
フロー制御効果: 高速失敗がデフォルトです。これは、しきい値に達すると、新しいリクエストが直ちに拒否され、FlowException がスローされることを意味します。

ここでは、単一マシンのしきい値が 5 に設定されています。

次に、JMeter テストツールを使用して 1 秒あたり 10 リクエストを送信し、合計 2 秒間継続します。

HTTPリクエストの設定

スクリプトを開始して実行結果を観察すると、ほぼ 5 つの項目が成功し、5 つの項目が失敗していることがわかります。

Sentinel で QPS の合格および拒否ステータスを観察できます。

1.2.2. 関連するフロー制御モード

アソシエーションモード:現在のリソースに関連する別のリソースをカウントするために使用され、しきい値がトリガーされると、現在のリソースが制限されます。

例えば、タオバオで何かを購入する場合、支払い完了後に注文ステータスを変更し、同時に注文内容も確認しますが、クエリと変更がデータベースのロックを競合するため、競合が発生します。業務ニーズに応じて、更新順業務を優先し、その後にユーザクエリ業務を実行するため、オーダー業務トリガ閾値を変更する場合には、クエリ順業務を制限する必要がある。

関連するフロー制御モードの適用可能なシナリオが次の条件を満たしていることがわかります。

2 つのリソースは競合しています。
1 つは優先度が高く、もう 1 つは優先度が低いです。

ビジネスを実装せずに OrderController に /order/query と /order/update の 2 つのエンドポイントを作成し、フロー制御ルールを設定する /order/update リソースへの QPS アクセス数が 5 を超えると、 /order/query リクエストの現在の制限。

具体的な実装手順は次のとおりです。

a) OrderController に 2 つの新しいエンドポイントを作成します。

/order/query エンドポイントと /order/update エンドポイントを作成します。

    @RequestMapping("/query")
    public String queryOrder() {
        return "订单查询成功！";
    }

    @RequestMapping("update")
    public String updateOrder() {
        return "订单修改成功！";
    }

b) Sentinel コンソールの注文クエリエンドポイントでフロー制御を実行する

単一マシンのしきい値を 5 に設定し、フロー制御モードとして「関連付け」を選択し、関連付けられたリソースは /order/update です。

つまり、/order/update がしきい値に達すると、/order/query リクエストを送信すると例外がスローされます。

c) JMeter を使用したテスト

1 秒あたり 10 リクエスト、合計 1,000 リクエストを送信するように設定します。

ここで /order/update にリクエストを送信してください。

d) 分析結果

JMeter の実行中に、/order/query リクエストを手動で送信すると、リクエストが失敗することがわかります。

これは、この時点で /order/update がしきい値を超えているためであり、このときに再度 /order/query リクエストが送信されると、2 つのリクエストの合計もしきい値を超える必要があるため、「フロー制御効果」が発生します。はすぐに失敗するように設定されているため、ここで例外がスローされます。

1.2.3. リンクフロー制御モード

リンクモード: 指定されたリンクから現在の指定されたリソースにアクセスするリクエストについてのみ統計が作成されます。しきい値を超えると、現在のリンクはフロー制限されます。

たとえば、現在 2 つのリクエストリンクがあります。

/test1 -> /tools
/test2 -> /tools

/test2 から /tools に入るリクエストのみをカウントしたい場合は、しきい値を超えると (しきい値が 5 であると仮定して)、この行のみがフロー制限され、次のように構成できます。

既存の問い合わせ注文と作成注文のビジネスの両方が製品ビジネスをクエリする必要がある場合の例を示します。デマンドとは、クエリ注文のリクエストをカウントし、製品をクエリし、フロー制御を設定することを指します (しきい値は 2)。

具体的な実装手順は次のとおりです。

a) OrderService に queryGoods メソッドを追加します (ビジネスを実装する必要はありません)。

クエリ注文ビジネスと作成注文ビジネスの両方がアクセスする必要があるクエリ製品ビジネスを表すために使用されます。

    @SentinelResource("goods") //设置资源名称
    public void queryGoods() {
        //使用 err 是为了高亮显示，方便观察日志信息
        System.err.println("查询订单成功！");
    }

知らせ！！！

1. Sentinel のデフォルト値では、コントローラー内のメソッドのみがリソースとしてマークされます。他のメソッドをマークしたい場合は、 @SentinelResource アノテーションを使用してリソース名を識別する必要があります。

2.プラス！デフォルトでは、Sentinel はコントローラー内のメソッドのコンテキストのみを統合するため、リンクモードのフロー制御が失敗します。次の設定を application.yml に追加する必要があります。

spring:
  cloud:
    sentinel:
      web-context-unify: false # 关闭context整合

2 つのエンドポイントをトリガーすると、次のように「クラスターポイントリンク」で商品が 2 つのエンドポイントリソースのサブリソースであることがわかります。

b) OrderController に 2 つのエンドポイント、つまり /order/query と /order/save を作成します。

両方のエンドポイントで、Order Service の queryGoods メソッドを呼び出す必要があります。

    @RequestMapping("/query")
    public String queryOrder() {
        orderService.queryGoods();
        return "订单查询成功！";
    }

    @RequestMapping("/save")
    public String saveOrder() {
        orderService.queryGoods();
        return "保存订单成功！";
    }

c) queryGoods の電流制限ルールを設定する

/order/query -> queryGoods へのリンクのフローをしきい値 2 で制限します。

d) JMeter を使用したテスト

JMeter を使用して両方のエンドポイントに 1 秒あたり 4 つのリクエストを送信します。

/order/save -> Goods リンク内のすべてのリクエストが成功したことがわかります。

/order/query -> Goods のリンクはフロー制御モードにより制限されています。

コンソールで商品の QPS 拒否ステータスを確認することもできます (8 QPS のうち 2 個が拒否され、拒否されたのは /order/query リンクのしきい値を超えるリクエストです)。

1.3. フロー制御効果

1.3.1. 高速障害

高速失敗: しきい値に達すると、新しいリクエストは直ちに拒否され、FlowException 例外がスローされます。これがデフォルトの処理方法です。

この方法は、デモのフロー制御モードでこの効果を実現するために使用されるため、ここでは詳しく説明しません。

1.3.2、ウォーミングアップ

ウォームアップ: ウォームアップモード。しきい値を超えるリクエストも拒否され、例外がスローされます。ただし、このモードのしきい値は動的に変化し、比較的小さな値から設定された最大しきい値 (ウォームアップ時間) まで徐々に増加します。ここで設定する必要があります)。

リクエストしきい値の初期値は設定された最大しきい値/coldFactor で、coldFactor のデフォルト値は 3 です。

たとえば、qps の最大しきい値を 10 に設定し、ウォームアップ時間を 5 秒に設定した場合、初期しきい値は 10 / 3 となり、四捨五入後の値は 3 になり、5 秒後には 10 まで徐々に増加します。

ここでは、リソース /order/{orderId} に現在の制限を設定し、最大 QPS は 10、ウォームアップ効果を使用し、ウォームアップ時間は 5 秒であるというケースを例に説明します。

具体的な手順は次のとおりです。

a) 電流制限ルールを設定する

b) テストに JMeter を使用する

c) 分析結果

コンソールでわかるように、最初の qps パスは 3 (最初のしきい値の計算後に取得) のみを通過しましたが、これは期待どおりです。5 秒以内に、qps パスの数は、qps パスの数 = 10 になるまで徐々に増加しました。そして安定しました。

1.3.3. 列に並んで待つ

このキューに入れて待機する方法では、リクエストが qps しきい値を超えた場合、例外は直接スローされず、余分なリクエストはまずキューに入れられ、キューに入れられ、許可された時間間隔に従って順番に実行されます。キュー内のすべてのリクエストが、リクエストの処理時間の合計が待機時間とまったく同じである場合、その時点での新しいリクエストは拒否されます。

たとえば、qps = 5 に設定すると、キュー内のリクエストが 200 ミリ秒ごとに処理されることを意味し、タイムアウトを 2000 ミリ秒に設定すると、キューにリクエストが 10 件あると時間がいっぱいになることを意味します。新しいリクエストが来た場合は拒否されます。

以下は、リソース /order/{orderId} の現在の制限を設定し、最大 qps は 10、キューイングのフロー制御効果を使用し、タイムアウトを 5 秒に設定するケースです。

a) フロー制御ルールを構成する

b) テストに JMeter を使用する

c) 分析結果

開始時刻になると、新しく追加されたリクエストが最初にキューに入り、キューの先頭にあるリクエストも処理されるため、すべてのリクエストが正常に処理されます。

その後、リクエストの速度がキューの処理速度よりも速かったため、キューは最終的にタイムアウト期間内にいっぱいになり、QPS は拒否されました。

最後のリクエストが送信された後、キューはリクエストの処理を続行し、タイムアウトを超過しないため、最後の qps はすべて渡されます。

1.3.4. ホットスポットパラメータの電流制限

以前の電流制限は、リソースにアクセスするすべてのリクエストをカウントして、それが qps しきい値を超えているかどうかを判断することでしたが、ホットスポットパラメータの現在の制限は、同じパラメータ値を持つリクエストをカウントして、qps しきい値を超えているかどうかを判断することでした。

例えばホットリソースのパラメータNo.0（第1パラメータ）を統計すると、以下のように同じパラメータに対する1秒あたりのリクエスト数が5を超えることはできません。

さらに、ホットスポットパラメータ電流制限の詳細オプションでは、一部のパラメータに追加の制限を課すこともできます。

パラメータタイプ: パラメータインデックスが指すパラメータのデータタイプ (Java データタイプのみがサポートされます)。

パラメータ値: 渡されるパラメータ値。

電流制限しきい値: ウィンドウ期間内の qps の最大しきい値。

たとえば、パラメータ値が 100 の場合、以下に示すように、1 秒あたりの許容 QPS は 10 になります。

ここでは、例を使用して説明します。ホットスポットパラメーターの現在の制限をリソース /order/{orderId} に追加します。ルールは次のとおりです。

デフォルトのホットスポットパラメータルールは、1 秒あたりのリクエスト数が 2 を超えないことです。
このパラメータ 102 に例外を設定します。1 秒あたりのリクエスト数は 4 を超えません。
103 パラメータに例外を設定します。1 秒あたりのリクエスト数は 10 を超えません。

具体的な実装手順は次のとおりです。

a) @SentinelResource アノテーションをホットスポットパラメータ電流制限オブジェクトに追加します

注: ホットスポットパラメーターの電流制限は、デフォルトの SpringMVC リソースでは無効であるため、 @SentinelResource を追加してリソースを指定し、名前を付ける必要があります。

    @SentinelResource("hot")
    @GetMapping("{orderId}")
    public Order queryOrderByUserId(@PathVariable("orderId") Long orderId) {
        // 根据id查询订单并返回
        return orderService.queryOrderById(orderId);
    }

b) 電流制限ルールを構成する