ES+Redis+MySQL 高可用性アーキテクチャ設計

1. 背景
2. ES 高可用性ソリューション
3. メンバーシップ Redis キャッシュソリューション
4. 高可用性メンバーマスターデータベースソリューション
5. 異常なメンバー関係管理
6. 見通し: より洗練されたフロー制御とダウングレード戦略

1. 背景

会員制度は、当社のあらゆる事業分野における発注の主要プロセスに密接に関わる基本的なシステムです。会員システムに障害が発生すると、ユーザーは注文できなくなり、影響範囲は会社の全事業に及びます。したがって、会員制システムは高いパフォーマンスと高可用性を確保し、安定的かつ効率的な基本サービスを提供する必要があります。

Tongcheng と eLong の合併に伴い、Tongcheng APP、eLong APP、Tongcheng WeChat Mini Program、および eLong WeChat Mini Program などのマルチプラットフォームのメンバーシップシステムをオープンにする必要があるシステムがますます増えています。たとえば、WeChat アプレットのクロスマーケティングでは、ユーザーが鉄道の切符を購入し、この時点でホテルの赤い封筒を送りたいとします。これには、ユーザーの統一されたメンバーシップ関係を照会する必要があります。鉄道の切符は東城会員システムを使用し、ホテルは eLong 会員システムを使用しているため、対応する eLong 会員カード番号が見つかった後でのみ、赤い封筒を会員アカウントに取り付けることができます。上記のクロスマーケティングに加えて、注文センター、会員レベル、マイレージ、赤い封筒、頻繁な旅行、実名、さまざまなマーケティング活動など、統一された会員関係をクエリする必要がある多くのシナリオがあります。そのため、メンバーシップシステムのリクエスト量はますます大きくなり、同時実行数はますます高くなっており、今年のメーデー休暇には 2 回目の同時 TPS が 20,000 を超えています。このような大量のトラフィックの影響下で、メンバーシップシステムはどのようにして高いパフォーマンスと高可用性を実現するのでしょうか? この記事ではこれに焦点を当てます。

2. ES 高可用性ソリューション

1. ES デュアルセンターアクティブ/スタンバイクラスターアーキテクチャ

Tongcheng と eLong の統合後、プラットフォーム全体のすべてのシステムのメンバーの総数は 10 億人を超えました。データ量がこれほど大きいと、ビジネス分野のクエリの次元も比較的複雑になります。一部のビジネスラインは携帯電話番号に基づいており、一部は WeChat Unionid に基づいており、また一部は eLong カード番号などに基づいて会員情報を照会します。このような大量のデータと非常に多くのクエリディメンションに基づいて、統合されたメンバーシップ関係を保存するために ES を選択しました。ES クラスターはメンバーシップシステムアーキテクチャ全体において非常に重要ですが、ES の高可用性を確保するにはどうすればよいでしょうか?

まず、次の図に示すように、ES クラスター自体が高可用性を保証していることがわかります。

ES クラスターの 1 つのノードがダウンすると、他のノードに対応するレプリカシャードがプライマリシャードにアップグレードされ、サービスを提供し続けます。しかし、それでも十分ではありません。たとえば、ES クラスタがコンピュータルーム A に展開されているが、コンピュータルーム A が突然電源を失った場合、どうすればよいでしょうか? たとえば、サーバーハードウェアに障害が発生し、ES クラスター内のほとんどのマシンがダウンした場合、どうすればよいでしょうか? または、突然非常に人気のあるフラッシュセールイベントが発生し、非常に大規模なトラフィックの波が発生し、ES クラスターが直接破壊されました。どうすればよいでしょうか? このような状況に直面して、運用保守の兄弟たちをコンピューター室に急行させて問題を解決させますか? 会員制度は会社のすべての事業部門の発注という主要なプロセスに直接影響を及ぼし、障害回復にかかる時間は非常に短くなければならないため、これは非常に非現実的です。運用および保守担当者による手動介入が必要な場合、その時間は非常に短くなります。長すぎるでしょう、これは絶対に耐えられません。ES の高可用性を実現するにはどうすればよいですか? 私たちのソリューションは、ES デュアルセンターアクティブ/スタンバイクラスターアーキテクチャです。

当校にはコンピュータ室Aとコンピュータ室Bの2つのコンピュータ室があります。ES メインクラスタをコンピュータルーム A にデプロイし、ES スタンバイクラスタをコンピュータルーム B にデプロイします。メンバーシステムの読み取りと書き込みはすべて ES メインクラスター内で行われ、データは MQ を介して ES スタンバイクラスターに同期されます。このとき、ESメインクラスタがダウンした場合には、統一構成により、メンバシステムの読み書きを計算機室BのESスタンバイクラスタに切り替えることで、ESメインクラスタがダウンしてもフェイルオーバーが可能となります。短期間での会員制度の安定運用を実現します。最後に、ESメインクラスタの障害が復旧した後、スイッチをオンにして障害時のデータをESメインクラスタに同期し、データが同期され整合性が取れた後、メンバーシステムの読み書きをESメインクラスタに切り替えます。集まる。

2. ES トラフィック分離 3 クラスターアーキテクチャ

デュアルセンター ES のアクティブクラスターとスタンバイクラスターがこのステップを達成できれば大きな問題はないと思われますが、昨年のひどいトラフィックショックにより考えが変わりました。休日だったので、ある企業がマーケティングキャンペーンを行ったところ、ユーザーからのリクエストで会員システムが10回以上呼び出され、会員システムのtpsが急上昇し、ESクラスタが爆発寸前になりました。このインシデントにより私たちは恐怖を感じ、発信者を優先し、より洗練された絶縁、回路遮断、ダウングレード、および電流制限戦略を実装する必要があることを認識しました。まず、すべての発信者を分類し、リクエストを 2 種類に分類しました。最初のカテゴリは、注文の主要なプロセスに密接に関連するリクエストであり、これらのリクエストは非常に重要であり、高い優先度で保証される必要があります。2つ目はマーケティング活動に関するもので、リクエスト数が多くTPSも高いものの、発注というメインプロセスには影響を与えないという特徴があります。これに基づいて、高 TPS マーケティングスパイクリクエストに対処するために特別に使用される別の ES クラスターを構築しました。これにより、メインの ES クラスターから分離され、特定のトラフィックの影響によってユーザーの注文プロセスに影響を与えることはありません。マーケティング活動のプロセス。以下に示すように:

3. ES クラスターの深さの最適化と改善

ES のデュアルセンターアクティブクラスターとスタンバイクラスターの高可用性アーキテクチャについて説明した後、ES のメインクラスターの最適化について詳しく説明します。ある時期、私たちは特に惨めでした。つまり、食事のたびに ES クラスターが警察に電話し始めたため、私たちは食事のたびに慌てふためき、ES クラスターだけでは対処できないのではないかと心配しました。会社全体が爆破されるだろう。では、なぜ食事の時間になったらすぐに警察を呼ぶのでしょうか？トラフィックが比較的大きいため、ES スレッドの数が急増し、CPU が高速化され、クエリ時間が増加し、それがすべての呼び出し元に送信され、その結果、遅延の範囲が広がります。では、この問題をどうやって解決すればいいのでしょうか？ES クラスターを詳しく調べたところ、次の問題が見つかりました。

ES 負荷は不当であり、ホットスポット問題は深刻です。ES メインクラスタには数十のノードがあります。多くのシャードをデプロイするノードもあれば、少数のシャードをデプロイするノードもあります。その結果、一部のサーバーに大きな負荷がかかります。トラフィックがピークに達すると、警告が頻繁に発行されます。
ES スレッドプールのサイズが大きすぎるように設定されているため、CPU の負荷が急上昇します。ES のスレッドプールを設定する場合、一般的にスレッド数はサーバーの CPU コア数に設定されることがわかっていますが、ES のクエリ負荷が高くスレッド数を増やす必要がある場合でも、スレッド数を増やす必要はありません。「CPUコア * 3 / 2 + 1」を超えるには。スレッド数の設定が多すぎると、CPU が複数のスレッドコンテキスト間を頻繁に切り替えて、大量の CPU リソースを浪費します。
シャードによって割り当てられたメモリが 100g と大きすぎるため、クエリが遅くなります。ES インデックスはシャードの数を合理的に割り当て、シャードのメモリサイズを 50g 以内に制御する必要があることがわかっています。シャードによって割り当てられたメモリが大きすぎると、クエリが遅くなり、時間がかかり、パフォーマンスに重大な影響を及ぼします。
文字列型のフィールドにはテキストとキーワードのダブルフィールドが設定されており、記憶容量が2倍になります。会員情報のクエリは関連度に応じてスコアを付ける必要がなく、キーワードに従って直接クエリできるため、テキストフィールドを完全に削除でき、ストレージスペースの大部分を節約し、パフォーマンスを向上させることができます。
ES クエリ。クエリではなくフィルターを使用します。クエリは検索結果の関連性スコアを計算するため、より多くの CPU を消費しますが、メンバー情報のクエリではスコアを計算する必要がなく、この部分のパフォーマンスの低下を完全に回避できます。
ES の計算能力を節約するには、メンバーシステムの jvm メモリ内の ES の検索結果をソートします。
ルーティングキーを追加します。ES クエリはリクエストをすべてのシャードに分散し、すべてのシャードが結果を返した後にデータを集約し、最終的に呼び出し元に結果を返すことがわかっています。データがどのシャードに分散されているかが事前にわかっている場合は、多数の不要なリクエストを削減し、クエリのパフォーマンスを向上させることができます。

上記の最適化後の結果は非常に顕著で、ES クラスターの CPU が大幅に削減され、クエリのパフォーマンスが大幅に向上しました。ES クラスターの CPU 使用率:

時間のかかる会員制インターフェース:

3. メンバーシップ Redis キャッシュソリューション

長い間、メンバーシップシステムはキャッシュされていませんでした。主な理由は 2 つあります。1 つは、上記の ES クラスターのパフォーマンスが非常に優れており、同時トランザクション数が 1 秒あたり 30,000 を超えていること、99 行に約 5 ミリ秒かかることです。 , さまざまな難しい問題に対処するのに十分です。第二に、ビジネスによっては、メンバーの結合関係にリアルタイムの一貫性が必要となる場合があり、メンバーシップは 10 年以上開発された古いシステムであり、多くのインターフェースと多くのシステムから構成される分散システムです。したがって、考慮されていないインターフェイスが存在し、キャッシュが時間内に更新されない限り、データがダーティになり、次のような一連の問題が発生します。ユーザーは WeChat の注文を確認できない、アプリが表示されないWeChatの会員レベル、マイレージなど。合併はなく、WeChatとAPPはクロスマーケットできないなど。では、なぜ再度キャッシュする必要があるのでしょうか? これは、今年の航空券のブラインドボックスアクティビティにより、それがもたらす瞬間的な同時実行性が高すぎるためです。会員システムは安全で健全ですが、依然として不安は消えず、念のため、最終的にキャッシングソリューションを導入することにしました。

1. ESの1秒近い遅延によるRedisキャッシュデータの不整合問題の解決策

メンバーシップキャッシュソリューションを作成する過程で、キャッシュされたデータの不整合につながる ES によって引き起こされる問題に遭遇しました。ES の稼働データはほぼリアルタイムであることがわかっていますが、ES にドキュメントを追加するとすぐに確認できるのですが、それが見つからず、確認できるまで 1 秒待つ必要があります。以下に示すように:

ES のほぼリアルタイムのメカニズムにより、Redis キャッシュデータの不整合が生じるのはなぜですか? 具体的には、ユーザーが APP アカウントからログアウトすると、ES を更新して APP アカウントと WeChat アカウント間のバインド関係を削除する必要があります。ES のデータ更新はほぼリアルタイムです。つまり、1 秒後に更新されたデータをクエリできます。この 1 秒以内に、ユーザーのメンバーシップバインディング関係をクエリするリクエストがあり、最初に Redis キャッシュをチェックインして誰もいないことがわかり、次に ES をチェックインしてそれを見つけますが、見つかったのは更新前の古いデータです。最後に、リクエストはクエリされた古いデータを Redis キャッシュに更新して返します。このように、1秒後にES上のユーザーのメンバーシップデータが更新されますが、redisキャッシュ内のデータは古いデータのままであるため、redisキャッシュとESデータの間に不整合が発生します。以下に示すように:

この問題に直面したら、どうやって解決すればよいでしょうか? 私たちのアイデアは、キャッシュされたデータの一貫性を確保するために、ES データを更新するときに 2 秒の Redis 分散同時ロックを追加し、その後、Redis 内のメンバーのキャッシュされたデータを削除することです。この時点でデータのクエリ要求がある場合は、まず分散ロックを取得し、メンバー ID がロックされていること、つまり ES によって更新されたばかりのデータがまだ有効になっていないことを確認してから、この時点でデータをクエリした後、の場合、redis キャッシュは更新されず、直接返されるため、キャッシュされたデータの不整合の問題が回避されます。以下に示すように:

一見すると、上記の解決策には問題がないように見えますが、慎重に分析すると、キャッシュされたデータの不整合が生じる可能性があります。たとえば、更新リクエストが分散ロックを追加する前に、分散ロックを取得するためのクエリリクエストが 1 つだけありますが、この時点ではロックがないため、キャッシュの更新を続けることができます。しかし、キャッシュを更新する直前にスレッドがブロックされ、その際に更新要求が来て分散ロックが追加され、キャッシュが削除されました。更新リクエストの操作が完了すると、クエリリクエストのスレッドがアクティブになり、このときに更新キャッシュが実行され、ダーティデータがキャッシュに書き込まれます。見つかりましたか？この問題の主な核心は、「キャッシュの削除」と「キャッシュの更新」の間に同時実行性の競合があることですが、これらが相互に排他的である限り、問題は解決できます。以下に示すように:

統計によると、キャッシュソリューションの導入後、キャッシュヒット率は 90% 以上になり、ES への負担が大幅に軽減され、メンバーシップシステムの全体的なパフォーマンスが大幅に向上しました。

2. Redis デュアルセンターマルチクラスターアーキテクチャ

次に、Redis クラスターの高可用性を確保する方法を見てみましょう。以下に示すように:

Redis クラスターの高可用性に関しては、デュアルセンターマルチクラスターモデルを採用しています。一連の Redis クラスターをコンピュータールーム A とコンピュータールーム B にそれぞれデプロイします。キャッシュされたデータを更新するときは、二重書き込みを行い、両方のコンピュータールームの Redis クラスターが正常に書き込まれた場合にのみ、成功を返します。キャッシュされたデータをクエリするときは、遅延を減らすためにコンピュータルームの近くでクエリを実行します。これにより、たとえコンピュータ室A全体が破綻しても、コンピュータ室Bは引き続き充実した会員サービスを提供することができる。

4. 高可用性メンバーマスターデータベースソリューション

前述したように、すべてのプラットフォームメンバーのバインディング関係データは ES に存在し、メンバーの登録詳細はリレーショナルデータベースに存在します。当初、メンバーが使用していたデータベースは SqlServer でしたが、ある日、DBA が来て、単一の SqlServer データベースには 10 億を超えるメンバーデータが保存されており、サーバーは物理的な限界に達したため、これ以上拡張できないと言いました。。現在の成長傾向によれば、SqlServer データベース全体が崩壊するまで、そう長くはかからないでしょう。考えてみてください。それはどのような災害シナリオですか。会員データベースが崩壊すると、会員システムも崩壊し、会員システムが崩壊すると、会社のすべての事業部門が崩壊します。そう思うとゾクゾクするし、とても新鮮なので、早速DBの移行作業に取り掛かりました。

1. MySql デュアルセンターパーティションクラスターソリューション

調査の結果、次の図に示すように、デュアルセンターのサブデータベースとサブテーブルを備えた MySql クラスターソリューションを選択しました。

会員のデータは合計10億件以上あり、会員のメインデータベースを1,000以上のシャードに分割し、各シャードを100万程度まで分割して使用できるようにしました。MySql クラスタは 1 つのマスターと 3 つのスレーブのアーキテクチャを採用しており、マスターライブラリはコンピュータルーム A に配置され、スレーブライブラリはコンピュータルーム B に配置されます。 1ミリ秒以内です。メンバーシステムは DBRoute を通じてデータの読み取りと書き込みを行い、書き込まれたデータはマスターノードが配置されているコンピュータールーム A にルーティングされ、読み取られたデータは近くにアクセスできるローカルコンピュータールームにルーティングされて、ネットワークの遅延が軽減されます。このように、デュアルセンターMySqlクラスタアーキテクチャを採用することで可用性が大幅に向上し、計算機室A全体が崩壊しても、計算機室Bのスレーブをマスターにアップグレードしてサービスを提供し続けることができます。

デュアルセンター MySql クラスターの構築後にストレステストを実施したところ、2 回目の同時実行数は 20,000 以上に達し、平均所要時間は 10 ミリ秒以内であり、パフォーマンスは基準を満たしています。

2. 会員メインデータベースのスムーズな移行計画

次の作業は、メンバーシップシステムの基盤となるストレージを SqlServer から MySql に切り替えることです。これは非常に危険な作業であり、主に次のような問題があります。

メンバーシップシステムは一時的に停止することはできません。停止することなく SqlServer から MySql への切り替えを完了するのは、高速自動車の車輪を交換するようなものです。
会員システムは多くのシステムやインターフェースから構成されており、10年以上開発されてきたため、歴史的な理由から古いインターフェースが多数残されており、ロジックも複雑です。非常に多くのシステムを 1 つずつ整理し、DAL 層のコードを問題なく書き換える必要があります。そうしないと大惨事になります。
データの移行はシームレスである必要があり、10 億を超える在庫データの移行だけでなく、リアルタイムデータもシームレスに mysql に同期される必要があります。さらに、データ同期のリアルタイム性を確保するだけでなく、データの正確性と SqlServer および MySql データの一貫性も確保する必要があります。

上記の問題点に基づいて、私たちは「完全同期、増分同期、リアルタイムトラフィックグレースケールスイッチング」の技術的ソリューションを設計しました。

まず、シームレスなデータの切り替えを実現するために、リアルタイム二重書き込み方式を採用しています。ビジネスロジックの複雑さと、SqlServer と MySql の技術的な違いにより、mysql を二重に書き込むプロセスでは、書き込みが成功しない場合があり、書き込みに失敗すると、SqlServer と MySql のデータが不整合になります。絶対に許されない。そこで、試行時を中心にSqlServerに書き込み、次にスレッドプール経由で非同期にMySqlに書き込み、書き込みに失敗したら3回リトライし、それでも失敗する場合はログを記録して手動で確認するという戦略をとります。一定期間実行して二重書き込みの失敗がなくなるまで、二重書き込みを続けます。上記の戦略により、ほとんどの場合、二重書き込み操作の正確性と安定性が保証され、試行中に SqlServer と MySql のデータに不整合があった場合でも、MySql のデータを完全に再構築できます。 SqlServer 。二重書き込み戦略を設計するときに、SqlServer が正常に書き込みできること、つまり SqlServer 内のデータが最も完全で正しいことを保証するためです。以下に示すように:

二重書き込みについて話した後は、「読み取りデータ」をグレースケールする方法を見てみましょう。全体的なアイデアは、A/B プラットフォームを介してトラフィックを段階的にグレースケールすることです。最初は、トラフィックの 100% が SqlServer データベースを読み取り、その後、徐々にトラフィックを減らして MySql データベースを読み取ります。最初は、1% (ある場合)問題がない場合は、徐々にトラフィックを解放し、最終的にはすべてのトラフィックが MySql データベースを通過します。徐々にグレースケールのトラフィックが増加するプロセスでは、検証メカニズムが必要であり、検証が OK の場合にのみ、トラフィックをさらに拡大できます。では、この検証メカニズムはどのように実装されているのでしょうか? 解決策は、非同期スレッドを使用して、クエリリクエスト内の SqlServer と MySql のクエリ結果が一致しているかどうかを比較することです。一致していない場合は、ログを記録し、不一致の問題が完全に解決されるまで手動で不一致の原因を確認します。、トラフィックを徐々にグレースケール化します。以下に示すように:

したがって、全体的な実装プロセスは次のようになります。

まず、暗くて風が強い夜の真夜中に、トラフィックが最も少ないときに、SqlServer から MySql データベースへの完全なデータ同期を完了します。次に、二重書き込みを有効にすると、ユーザー登録があればリアルタイムで2つのデータベースに二重書き込みされます。次に、完全同期とリアルタイム二重書き込み有効の間では、この期間中も 2 つのデータベースのデータに差異が存在するため、データの不整合を防ぐために、データを完全にするために再度増分同期が必要になります。残りの時間は、さまざまなログの監視に費やされ、二重書き込みの問題がないかどうか、データの比較に一貫性があるかどうかなどが確認されます。この期間は最も時間がかかり、最も問題が発生しやすい期間です。問題が深刻でデータの不整合が発生した場合は、最初からやり直して、完全な SqlServer に基づいて MySql データベースを再構築し、その後再構築する必要があります。最後までトラフィックをグレー化します , トラフィックの 100% が MySql に対してグレースケール化されます。この時点で、完了です。グレースケールロジックはオフラインになり、すべての読み取りと書き込みが MySql クラスターに切り替えられます。

3. MySql と ES のアクティブ/スタンバイクラスタースキーム

このステップの後、メインメンバーライブラリは問題ないはずだと感じましたが、dal コンポーネントの重大な障害により考えが変わりました。その失敗はひどいもので、社内の多くのアプリケーションがデータベースに接続できなくなり、注文件数が激減したことから、たとえデータベースが良好であっても、dalコンポーネントの異常によって会員システムが正常に動作しなくなる可能性があることが分かりました。電話を切る。したがって、次のように、メンバーマスターデータベースのデータソースを再度異種混合し、データを ES に二重書き込みします。

dal コンポーネントに障害が発生するか、MySql データベースがハングアップした場合は、読み取りと書き込みを ES に切り替え、MySql が回復するのを待ってからデータを MySql に同期し、最後に読み取りと書き込みを MySql データベースに戻すことができます。以下に示すように:

5. 異常なメンバー関係管理

会員システムは、システムの安定性と高可用性を確保するだけでなく、データの正確性と正確性も確保する必要があります。たとえば、分散型同時障害により、ユーザーの APP アカウントが他の人の WeChat アプレットアカウントにバインドされ、非常に悪い影響が生じます。まず、2 つのアカウントを連携すると、2 人のユーザーが注文したホテル、航空券、電車のチケットを相互に確認できるようになります。考えてみてください、他の人はあなたのホテルの予約を見ることができます、あなたが人気がなかったら文句を言いますか？他の人のオーダーを見ることができるほか、オーダーを操作することもできます。たとえば、ユーザーは、APP の注文センターで他の人が予約した航空券の注文を見て、それが自分の注文ではないと考え、注文をキャンセルします。周知のとおり、航空券のキャンセル料は非常に高額であり、これはユーザーの通常の旅行に影響を与えるだけでなく、比較的大きな経済的損失にもつながり、非常に悪いことです。

これらの異常なメンバーアカウントについては、詳細に分類し、非常に複雑で頭を使うロジックを通じてこれらのアカウントを特定し、メンバーインターフェイスの徹底的な最適化と管理を実行し、コードロジック層の関連する抜け穴をブロックしました。異常なメンバーのアカウントを完了しました。ガバナンス作業。以下に示すように:

6. 見通し: より洗練されたフロー制御とダウングレード戦略

どのようなシステムでも 100% 問題が発生しないことを保証することはできないため、障害を考慮した設計、つまりより洗練されたフロー制御と劣化戦略が必要です。

1. より洗練された交通制御戦略

ホットスポット制御。不正請求のシナリオでは、同じ会員 ID に対して大量のリクエストが繰り返され、ホットアカウントが形成され、これらのアカウントへのアクセスが設定されたしきい値を超えると、トラフィック制限戦略が実行されます。

発信側アカウントに基づくフロー制御ルール。この戦略は主に、呼び出し元のコードのバグによって引き起こされる大量のトラフィックを防ぐことを目的としています。たとえば、ユーザー要求では、呼び出し元がメンバーシップインターフェイスをループで何度も呼び出すため、メンバーシップシステムのトラフィックが何度も突然増加します。したがって、発信アカウントごとにフロー制御ルールを設定し、しきい値を超えた場合のフロー制限ポリシーを実装する必要があります。

グローバルフロー制御ルール。当社のメンバーシップシステムは、1 秒あたり 30,000 tps 以上の同時リクエストに耐えることができます。現時点で、tps が 100,000 にも達するひどいトラフィックが到来している場合は、このトラフィックの波ですべてのメンバーデータベースを強制終了させ、高速に実行することをお勧めします。会員システムの許容範囲を超えるトラフィックを拒否すれば、少なくとも 30,000 tps 以内の会員リクエストは正常に応答でき、会員システム全体が崩壊することはありません。

2. より洗練されたダウングレード戦略

平均応答時間に基づいてダウングレードします。メンバインターフェイスは他のインターフェイスにも依存しており、他のインターフェイスの呼び出しの平均応答時間がしきい値を超えると、準縮退状態になります。次の 1 秒間の受信リクエストの平均応答時間が引き続きしきい値を超えた場合、次の時間枠でヒューズが自動的に切断されます。

外れ値の数と外れ値の割合に基づく降格。メンバインタフェースが依存する他のインタフェースで例外が発生した場合、1分以内の例外数が閾値を超えるか、例外総数と1秒あたりのスループットの割合が閾値を超えると、縮退状態になり、次の時間枠内で自動的に融合します。