安定性構築で遭遇する問題と解決策

目次

ネットワークタイムアウトの適切な設定

中核事業と非中核事業の分離

3つのTomcatスレッドの数を合理的に構成します

4つのコードで再試行しないようにしてください

弱体化のための5つの本質的でない依存関係

6つのデータベーストランザクションの合理化

7つのSQLパフォーマンス最適化ポイント

8.オンラインプロセスをスムーズにしよう

異常なトラフィックを処理するための9つの電流制限、融合、劣化、キューイング

10の完璧なログおよび監視機能


この記事では、主に高可用性と高性能構築に関するいくつかの経験と要約について説明します。

ネットワークタイムアウトの適切な設定

1.1ネットワークコールのタイムアウト期間とは何ですか?

たとえば、アプリケーションサーバー間、アプリケーションサーバーとredisサーバー間、アプリケーションサーバーとmqサーバー間のネットワーク要求の場合、これらのネットワーク要求には通常3つのタイムアウト期間があります。

  • connectRequestTimeout:クライアントは接続プールから接続タイムアウト時間を取得します。
  • connectTimeout:クライアントとサーバー間の接続を確立するためのタイムアウト期間。
  • socketTimeout:クライアントとサーバーがデータを読み取るためのタイムアウト時間。

1.2タイムアウト期間を設定する必要があるのはなぜですか?

システム接続プールまたはスレッドプールのリソースは限られているため、タイムアウトが設定されていないと仮定すると、ダウンストリームサービスの速度が遅いか、ダウンストリームサービスが異常であるため、ダウンストリームサービスが戻るのを愚かに待っているスレッドが多数あります。

一部の通常のリクエストは待機または拒否され、サービスレスポンスが遅くなり、スループットレートが低下し、QPSが低下し、ユーザーエクスペリエンスが低下します。この状況は、タイムアウトを設定することで回避できます。

1.3タイムアウト期間を合理的に設定するにはどうすればよいですか?

単純な原則は次のとおりです。socketTimeout、connectTimeout、connectRequestTimeout 3つのタイムアウト、300ミリ秒以下、システムが受け入れることができる場合は可能な限り短くします。

タイムアウト期間は、システムの99行に応じて設定できますいわゆる99回線は、ネットワーク要求の99%を満たすために必要な最小時間です。簡単に言うと、1日に10,000回リクエストするインターフェースがあるとします。

9900リクエストの計算に必要な最小時間は、99行と呼ばれます。具体的な計算については、この記事(https://blog.csdn.net/brucewong0516/article/details/80205422を参照してください

Redisは通常2〜3ミリ秒で読み取りと書き込みを行い、タイムアウト期間を短く設定する必要があります。50ミリ秒を超えないようにしてください。mqのタイムアウトについても同じことが言えます。

中核事業と非中核事業の分離

すべての企業にはコアビジネスと非コアビジネスがあります。コアリンクはコアビジネスに分類できます。いわゆるコアリンクは会社の最も価値のあるビジネスである必要があります。コアビジネスはリンク上のコアビジネスのみを呼び出すことができます。

非中核事業は非中核事業のみを呼び出すことができます。会社が可能であれば、コアビジネスのデュアルコンピュータールームまたはマルチコンピュータールームの展開を実現します。

3つのTomcatスレッドの数を合理的に構成します

スレッドの数を合理的に構成します。たとえば、CPUを集中的に使用するスレッドは少なく構成でき、IOを集中的に使用するスレッドはより多く構成できます。詳細については、この記事(https://blog.csdn.net/jack1liu/article/details/100511226を参照してください

4つのコードで再試行しないようにしてください

特別な理由がない場合は、コードで再試行しないでください。再試行は可能な限りビジネスの再試行である必要があり、上流のビジネス担当者が再試行操作を実行します。

コードで再試行してみませんか?

コードを再試行すると、このブロックはフロー増幅の傾向があり、通常は1倍の量になります。5回再試行すると、フローは通常の5倍になります。サービスをシャットダウンするのは簡単です。

弱体化のための5つの本質的でない依存関係

弱い依存とは何ですか?

いわゆる弱い依存は、メインプロセスへの影響が少ないプロセスに弱く依存することです。

たとえば、mq / redisでタイムアウト例外が発生した場合、それがmain関数に影響を与えない場合は、例外をキャッチして上位層にスローしないようにする必要があります。例えば:     

String value = redis.get(“key”);
	if(value == null) {
		value = dao.getOneColumn(“”);
	}
}

redisに弱く依存するキャッチがない場合、redisが失敗すると、例外が直接上位層にスローされ、データベースからデータを読み取ることができなくなります。 

mqのフォールトトレランスをキャッチすることに加えて、mqが使用できないときに失われたメッセージを処理する方法は?たとえば、ログを記録して後で処理するようにmqを変更します。

6つのデータベーストランザクションの合理化

トランザクション内の操作は、トランザクションの実行時間を短縮するために可能な限り少なくする必要があり、RPC呼び出しがあってはなりません。

7つのSQLパフォーマンス最適化ポイント

7.1遅いSQLを定義する方法は?

理論的には、ユーザー側のSQL実行は10ミリ秒以内である必要があり、50ミリ秒を超えると低速SQLとして分類できます。

7.2 SQLクエリの数の適切な制限は何ですか?

たとえば、制限制限は100または200を超えることはできず、inのID制限も100または200です。

7.3新しく追加されたSQLに問題がないことを確認するにはどうすればよいですか?

Explainを使用して、SQLの実行プランを表示します。

関連するクエリフィールドにインデックスを追加して、クエリを高速化します。

8.オンラインプロセスをスムーズにしよう

たとえば、データベースの移行では、プログラムの設計とオンラインプロセスで、影響範囲の最大限の制御迅速な回復という2つのコアポイントを考慮する必要があります

影響範囲を最大限に制御するにはどうすればよいですか?

  • グレースケールプロセスを検討し、徐々に音量を上げることができます。
  • 機能を確認するために、ホワイトリストなどを追加できます。

機能をすばやく復元するにはどうすればよいですか?

  • 機能をすばやく復元するには、いくつかの動的スイッチを追加します。
  • 事前に準備し、オンラインで計画をロールバックします。

異常なトラフィックを処理するための9つの電流制限、融合、劣化、キューイング

作者は、異常なトラフィックのためにサービスが一時的に利用できないという問題に遭遇しました。詳細については、(https://blog.csdn.net/jack1liu/article/details/112135898を参照してください

もちろん、融合、劣化、およびキューイングテクノロジーは、サービス内の異常なトラフィックにも使用できます。問題が解決できれば大丈夫です。

10の完璧なログおよび監視機能

合理的で必要なログデータを印刷する必要があります。

10.1合理的で必要なログとは何ですか?

ビジネス上の問題のトラブルシューティングとシステムの問題のトラブルシューティングを行うことができるログは合理的で必要です。

10.2なぜ監視機能を改善する必要があるのですか?

監視がない場合、サービスは実際に裸で実行されているように感じます。問題がある場合、監視は問題をより迅速かつ効果的に見つけ、再現し、解決するのに役立ちます。

おすすめ

転載: blog.csdn.net/jack1liu/article/details/112647026