インタビュアー: 高同時実行性についてどのくらい知っていますか?私：うーん...

高い同時実行性は、ほぼすべてのプログラマーが望んでいるエクスペリエンスです。 理由は非常に簡単です。トラフィックが増加すると、インターフェイスの応答タイムアウト、CPU 負荷の増加、頻繁な GC、デッドロック、大規模なデータ ストレージなど、さまざまな技術的な問題が発生します。Wait 、これらの質問は、技術的な深みを継続的に向上させる原動力になります。

過去の面接では、候補者が同時実行性の高いプロジェクトを行ったことがある場合、通常、候補者に同時性の高いプロジェクトについての理解を尋ねますが、体系的に答えることができます。 . この問題が得意な人は多くありませんが、大きく分けて

1、# に分類されます。 ##データベースのインジケーターはありません コンセプト: 同時実行性の高いシステムを測定するためにどのインジケーターを選択すればよいかわかりませんか?同時実行性と QPS の違いがわかりません。システムの総ユーザー数、アクティブ ユーザー数、平坦時とピーク時の QPS と TPS、その他の重要なデータさえもわかりません。

2. いくつかの計画は策定されましたが、詳細は完全に把握されていませんでした: Can'計画 では、技術的な点と起こり得る副作用に焦点を当てる必要があります。たとえば、読み取りパフォーマンスにボトルネックがある場合、キャッシュが導入されますが、キャッシュ ヒット率、ホット キー、データの一貫性などの問題は無視されます。

3. 高同時実行設計とパフォーマンスの最適化を同一視する一方的な理解: は同時プログラミング、マルチレベル キャッシュ、非同期化、水平拡張について説明していますが、高い同時実行性の設計を無視します。 利用可能な設計、サービス ガバナンス、運用および保守の保証。

4. 大きな計画をマスターしますが、最も基本的なことは無視します: 垂直方向について明確に説明できるようにする階層化、水平パーティショニングやキャッシュなどの大きなアイデアはあるが、データ構造が合理的かどうか、アルゴリズムが効率的かどうかを分析するつもりはなく、IOとコンピューティングの最も基本的な2つの側面から詳細を最適化することについて考えたことはありません。

この記事では、高同時実行プロジェクトでの私自身の経験を組み合わせて、高同時実行で習得する必要がある知識と実践的なアイデアを体系的にまとめたいと思います。お役に立てば幸いです。 コンテンツは次の 3 つの部分に分かれています:

• 高い同時実行性を理解するにはどうすればよいですか?
  
• #高同時実行性のシステム設計の目標は何ですか?
• 高い同時実行性を実現する実際的なソリューションは何ですか?
  
  

01 高い同時実行性を理解するにはどうすればよいですか?

高い同時実行性は大量のトラフィックを意味し、トラフィックの影響に抵抗するために技術的手段を使用する必要があります。これらの手段はトラフィックを運用するのと同様で、システムによるトラフィックのよりスムーズな処理を可能にします。ユーザーエクスペリエンスにより良い結果をもたらします。

一般的な同時実行性の高いシナリオには、淘宝網のダブル 11、春節期間中のチケット入手、Weibo Vs からのホットなニュースなどが含まれます。これらの典型的なものに加えて、1 秒あたり数十万のリクエストを伴うフラッシュセール システム、1 日に数千万の注文を伴う注文システム、1 日に数億のデイリー アクティブを伴う情報フロー システムなどはすべて分類できます。高い同時実行性として。

明らかに、上記の高同時実行シナリオでは、同時実行の量は異なります。では、どの程度の同時実行が高同時実行とみなされるのでしょうか?

##1. 数字だけを見るのではなく、具体的なビジネス シナリオにも注目してください。 10W QPS のフラッシュセールは同時実行性が高いとは言えませんが、1W QPS の情報フローは同時実行性が高いとは言えません。情報フロー シナリオには複雑な推奨モデルとさまざまな手動戦略が含まれており、そのビジネス ロジックはフラッシュ セール シナリオよりも 10 倍以上複雑になる可能性があります。したがって、これらは同じ次元に存在せず、比較する意味はありません。

2. ビジネスは 0 から 1 から始まります。同時実行性や QPS はあくまで参考指標です。最も重要なのは、ビジネス量が徐々に 10 倍、100 倍に増加したときに、倍増のプロセスにおいて、システムを進化させるために高同時実行性の処理方法を使用し、アーキテクチャ設計、コーディング実装、さらには製品ソリューションの側面から高同時性によって引き起こされる問題を防止および解決しましたか?やみくもにハードウェアをアップグレードしたり、水平方向の拡張のためにマシンを追加したりするのではなく。

さらに、各高同時実行シナリオの ビジネス特性はまったく異なります。読み取りが多く書き込みが少ない情報フロー シナリオもあれば、書き込みが少ないトランザクション シナリオもあります。読み取りと書き込み、さまざまなシナリオでの同時実行性の問題を解決するための一般的な技術ソリューションはありますか??

大きなアイデアや他の人の計画から学ぶことはできると思いますが、実際の実装プロセスでは、細部に無数の落とし穴があるでしょう。また、ソフトウェアとハ​​ードウェアの環境、技術スタック、製品ロジックは完全に一致することはできないため、同じビジネスシナリオにつながります。同じ技術ソリューションを使用したとしても、異なる問題に直面するため、これらの落とし穴を解決する必要があります。ひとつひとつ乗り越えていく。

したがって、この記事では、基礎的な知識、一般的な考え方、および私が実践した効果的な経験に焦点を当てて、あなたに高い同時実行性についてのより深い理解。

#02 高同時実行性のシステム設計の目標は何ですか?

まず、高同時実行性のシステム設計の目標を明確にしてから、これに基づいて有意義かつ的を絞った設計計画と実際の経験について話し合います。

#2.1 マクロ目標

##高い同時実行性は、単に高い同時実行性を追求することを意味するわけではありません パフォーマンス、これは多くの人の一方的な理解です。 マクロの観点から見ると、高同時実行性のシステム設計には、高い パフォーマンス、高可用性、および高いスケーラビリティという 3 つの目標があります。

1. 高いパフォーマンス:

パフォーマンスは、システムの並列処理能力を反映します。限られたハードウェア投資で、改善パフォーマンスとは、コストを節約することを意味します。同時にパフォーマンスはユーザーエクスペリエンスを反映しており、応答時間はそれぞれ100ミリ秒と1秒で、ユーザーに与える印象はまったく異なります。

2. 高可用性 : は、システムが正常に動作できる時間を示します。 1 つは年間を通じてダウンタイムや障害が発生しないもので、もう 1 つはオンライン事故やダウンタイムが時折発生するもので、ユーザーは間違いなく前者を選択します。また、システムが90％しか利用できないと業務に大きな支障をきたします。

3. 高拡張性 : システムの拡張能力、 を示します。トラフィックのピーク時の短時間 容量拡張を完了し、ダブル 11 イベント、有名人の離婚、その他の話題のイベントなどのピークトラフィックをよりスムーズに処理します。

これら 3 つの目標は相互に関連しており、相互に影響を与えるため、総合的に検討する必要があります。

# というような言い方より #:システムのスケーラビリティを考慮して、## サービスをステートレスになるように設計します。##,この種のクラスタは、高いスケーラビリティを確保するように設計されています。実際、はシステムを時々アップグレードします パフォーマンスと使いやすさ。

別の例: 可用性を確保するために、通常、多数のスレッドが遅いリクエストをブロックしてシステム雪崩を引き起こすことを防ぐために、サービス インターフェイスにタイムアウト設定が設定されます。通常、依存するサービスのパフォーマンスに基づいて設定を行います。

2.2 マイクロ目標

から見てみましょう。ミクロな視点 高性能、高可用性、高スケーラビリティを測定するための具体的な指標は何でしょうか?なぜこれらの指標が選ばれたのでしょうか?

❇ パフォーマンス指標

パフォーマンス指標は、現在のパフォーマンスの問題を解決し、パフォーマンス最適化の評価の基礎としても機能します。一般的に、一定期間内のインターフェースの応答時間が指標として使用されます。

1. 平均応答時間: 最も一般的に使用されますが、明らかな欠陥があり、遅いリクエストの影響を受けません。たとえば、リクエストが 10,000 件あり、そのうち 9,900 件が 1 ミリ秒、100 件が 100 ミリ秒である場合、平均応答時間は 1.99 ミリ秒です。平均消費時間は 0.99 ミリ秒しか増加していませんが、リクエストの 1% の応答時間は 100 ミリ秒増加しています。回。

2、TP90、TP99、およびその他の分位値: 応答時間を小さいものから大きいものに並べ替えます。TP90 は 90 番目のポイントにランクされることを意味します。ビット応答時間。分位値が大きいほど、遅いリクエストに対する感度が高くなります。

3. スループット: スループットは応答時間に反比例します。応答時間は 1ms、スループットは 1 秒あたり 1000 回です。

通常、パフォーマンス目標を設定するときは、次のようにスループットと応答時間の両方が考慮されます。 1 秒あたり 1 リクエストが 10,000 件未満では、AVG は 50 ミリ秒未満に制御され、TP99 は 100 ミリ秒未満に制御されます。同時実行性の高いシステムの場合、AVG と TP の分位値を同時に考慮する必要があります。

###

また、ユーザーエクスペリエンスの観点から、200ミリ秒が第一の区切り点であり、ユーザーが遅延を感じにくい、1秒が第二の区切り点であり、ユーザーが遅延を感じることができると考えています。遅れますが、許容範囲です。

したがって、健全な高同時実行システムの場合、TP99 は 200 ミリ秒以内に制御され、TP999 または TP9999 は 200 ミリ秒以内に制御される必要があります。 1秒以内。

❇ 可用性 インジケータ

高可用性とは、システム 高い無障害動作能力を持っている 可用性 = 通常の動作時間 / システムの総動作時間 システムの可用性を表すには、一般に数桁の 9 が使用されます。

高同時実行システムの場合、最も基本的な要件は、3 つの 9 または 4 つの 9 を保証することです。理由は簡単です。9 が 2 つしか達成できない場合、故障時間は 1% であることを意味します。たとえば、一部の大企業では、年間の GMV または収益が 1,000 億を超えることもよくあります。1% は、1 のビジネス インパクトです。億レベル。

❇ スケーラビリティ指標

突然のトラフィックに直面して、アーキテクチャを一時的に変更することは不可能です。最速の方法は、マシンを追加してシステムの処理能力を直線的に向上させることです。

業務クラスタや基本コンポーネントの場合、スケーラビリティ = 性能向上率 / マシン追加率 理想的なスケーラビリティは、リソースが数台増加することです。倍になり、パフォーマンスが数倍向上します。 一般的に、拡張能力は 70% 以上に維持する必要があります。

しかし、同時実行性の高いシステムの全体的なアーキテクチャの観点から見ると、 の目標はサービスを拡張することだけではありません トラフィックが 10 倍に増加すると、ビジネス サービスはすぐに 10 倍に拡張できますが、データベースが新たなボトルネックになる可能性があるため、ステートレスに設計してください。

MySQL のようなステートフル ストレージ サービスは、通常、拡張が技術的に困難です。アーキテクチャが事前に計画されていない場合 (垂直分割と水平分割)、移行が必要になります。大量のデータ。

したがって、サービス クラスター、データベースなどのミドルウェア、キャッシュやメッセージ キュー、負荷分散、帯域幅、依存するサードパーティなど、高いスケーラビリティを考慮する必要があります。同時実行性が一定に達すると、これらの各要素は、後でスケーリングする際のボトルネックになる可能性があります。

03 高い同時実行性のための実用的なソリューションは何ですか??

高同時実行設計の 3 つの主な目標を理解した後、高同時実行設計計画を系統的にまとめます。この計画は次の 2 つの部分から展開されます。まず、一般的な設計方法を要約します。次に、高パフォーマンス、高可用性、高スケーラビリティに関する具体的な実用的なソリューションが示されます。

#3.1 ユニバーサルデザインの手法

ユニバーサルデザインの手法主に、「vertical」 と 「horizo​​ntal」 という 2 つの次元から始まります。これは一般に高同時処理の 2 本の柱として知られています。縦方向の拡張と横方向の拡張。

❇ 垂直方向の拡張 (スケールアップ)

その目標は、単一マシンの処理能力を向上させることです。 , プランには次の内容も含まれます:

1. 単一マシンのハードウェア パフォーマンスを向上させる: メモリ、CPU コア数、ストレージ容量を増やすか、ディスク を SSD にアップグレードします。 など。 method waytoimprove 。 2. 単一マシンのソフトウェア パフォーマンスを向上させる: キャッシュを使用して IO の数を減らし、同時または非同期メソッドを使用してスループットを向上させます。

❇ 水平方向の拡張 (スケールアウト)

なぜなら、パフォーマンスには常に限界があるからです。単一マシンの場合、最終的には、次の 2 つの方向を含む、水平拡張の導入とクラスター展開による同時処理能力のさらなる向上が必要です:

1. 階層化アーキテクチャを適切に実行します。これは水平方向の拡張の進歩です。なぜなら、高同時実行システムには複雑なビジネスが含まれることが多く、階層化された処理によって複雑な問題が単純化され、水平方向の拡張が容易になるからです。

上の図は、インターネットの最も一般的な階層型アーキテクチャですが、もちろん、実際の高同時実行性システム アーキテクチャは、これをベースにしてさらに改良されることになります。例えば、動的と静的な分離が行われ、CDNが導入され、リバースプロキシ層はLVS Nginx、Web層は統合されたAPIゲートウェイ、ビジネスサービス層は垂直ビジネスに応じてさらにマイクロサービス化され、ストレージ層はさまざまな異種データベースにすることができます。

#2. 各レイヤーの水平拡張: ステートレスな水平拡張、ステートフルなシャード ルーティング。通常、ビジネス クラスタはステートレスになるように設計できますが、データベースとキャッシュは多くの場合ステートフルです。したがって、パーティション キーはストレージ シャーディング用に設計する必要があります。もちろん、読み取りパフォーマンスは、マスターとスレーブの同期や読み取りと書き込みの分離によって改善することもできます。

3.2 具体的な実践計画

私の個人的な経験と組み合わせて、次の 3 つを考えます。高パフォーマンス、高可用性、高スケーラビリティの側面に基づいて、実装可能な実用的なソリューションをまとめます。

❇ 高性能の実用的なソリューション

1、クラスター展開、負荷による単一マシンへの負荷を軽減します。バランスをとること。

2. マルチレベル キャッシュ (静的データに対する CDN、ローカル キャッシュ、分散キャッシュなどの使用、ホット キーの処理、キャッシュ ペネトレーション、キャッシュの同時実行性、データの整合性など)キャッシュシナリオの問題。

3. データベースのシャーディング、テーブルのシャーディング、インデックスの最適化、および検索エンジンを利用した複雑なクエリの問題の解決。

4. HBase、TiDB などの NoSQL データベースの使用を検討しますが、チームはこれらのコンポーネントに精通しており、強力な運用および保守能力を備えている必要があります。

#5. 非同期、マルチスレッド、MQ、または遅延タスクを通じて、二次プロセスを非同期に処理します。

6、電流制限、まず企業が電流制限を許可しているかどうかを検討する必要があります (たとえば、フロントエンド電流制限、Nginxアクセス層電流制限、サーバーサイド電流制限を含むフラッシュセールシナリオが許可されています。

7. トラフィックの山を切り詰め谷を埋める MQ はトラフィックを処理します。

8. 同時処理、マルチスレッドを通じてシリアル ロジックを並列化します。

9. 赤い封筒をつかむシナリオなどの事前計算では、赤い封筒の金額を事前に計算してキャッシュし、赤い封筒を送信するときにそれを直接使用できます。

10、キャッシュ ウォームアップ、非同期 タスクadvance データをローカル キャッシュまたは分散キャッシュに予熱します。

11. データベースやキャッシュの バッチ読み取りおよび書き込み、RPC バッチ インターフェイスのサポートなどの IO の数を減らすか、冗長データによる RPC 呼び出しを排除します。

12. 軽量通信プロトコル、適切なデータ構造の使用、インターフェイスの冗長フィールドの削除、キャッシュ キー サイズの削減、キャッシュ値の圧縮などを含め、IO 中のデータ パケットのサイズを削減します。 。

13. 実行プロセスをブロックする可能性が高い判定ロジックを事前に配置する、For ループの計算ロジックを最適化する、またはより多くのロジックを使用するなど、プログラム ロジックの最適化効率的なアルゴリズム。

14. HTTP リクエスト プール、スレッド プール (コア パラメータの設定には CPU 集中型または IO 集中型を考慮)、データベースなどのさまざまなプーリング テクノロジの使用とプール サイズの設定Redis接続プールなど。

15. GC の頻度と時間をできる限り削減するための、新世代と旧世代のサイズ、GC アルゴリズムの選択などの JVM の最適化。

#16. ロックの選択。読み取りが多く書き込みが少ないシナリオではオプティミスティック ロックを使用するか、セグメント化されたロックを通じてロックの競合を減らすことを検討してください。

上記のソリューションは、コンピューティングと IO の 2 つの側面から考えられるすべての最適化ポイントを考慮したものにすぎません。現在のパフォーマンスをリアルタイムで理解するには、サポートする監視システムが必要です。パフォーマンスのボトルネック分析を実行し、28/20 原則に従って主な矛盾に焦点を当てて最適化します。

❇ 高可用性の実用的なソリューション

#1. ピア ノードのフェイルオーバー: Nginx とサービス ガバナンス フレームワークの両方が、ピア ノードの障害をサポートします。別のノードにアクセスします。

###

2. ハートビート検出とマスター/スレーブ切り替え (Redis のセンチネル モードまたはクラスター モード、MySQL のマスター/スレーブ切り替えなど) の実装による、非ピア ノードのフェイルオーバー。

3. インターフェイス レベルのタイムアウト設定、再試行戦略、および 冪等設計。

4. ダウングレード処理: コア サービスを確保し、非コア サービスを犠牲にし、必要に応じて回線を切断します; またはコア リンクに問題がある場合、は代替リンクです。

5. 電流制限処理: システムの処理能力を超えるリクエストを直接拒否またはエラーコードを返します。

6. MQ シナリオにおけるメッセージ信頼性の保証 (プロデューサー側の再試行メカニズム、ブローカー側の永続性、コンシューマー側の ACK メカニズムなどを含む)。

7. グレースケール リリースでは、マシンの寸法に応じた小規模なトラフィックの展開をサポートし、システム ログとビジネス インジケーターを観察し、動作が安定した後にフル ボリュームをプッシュできます。

8. 監視と警報: CPU、メモリ、ディスク、ネットワークの最も基本的な監視に加え、Web サーバー、JVM、データベース、その他のさまざまな監視を含む包括的な監視システムミドルウェア 監視およびビジネス指標の監視。

9. 災害復旧訓練: 現在の「カオス エンジニアリング」と同様に、システムに対していくつかの破壊的な方法を使用して、ローカルな障害が可用性の問題を引き起こすかどうかを観察します。

高可用性ソリューションは主に、冗長性、トレードオフ、システムの運用と保守の 3 つの方向から検討され、同時にサポート機能や障害対応機能も必要となります。オンラインで問題が発生した場合でも、時間内にフォローアップできます。

❇ 拡張性の高い実用的なソリューション

1. 合理的な階層化アーキテクチャ: たとえば、上記のインターネットで最も一般的なもの階層化アーキテクチャ。さらに、マイクロサービスは、 データ アクセス層とビジネス ロジック層に従って、よりきめ細かい方法でさらに階層化できます (ただし、パフォーマンスを評価する必要があり、ネットワーク内にもう 1 つのホップが存在する可能性があります)。 。

#2. ストレージ層の分割: ビジネスの次元に応じて垂直に分割し、データに応じてさらに水平に分割 (サブデータベースとサブテーブル)機能の寸法。

#3. ビジネス層の分割: 最も一般的なのは、ビジネスの側面 (電子商取引における商品サービス、注文サービスなど) に応じた分割です。コア インターフェイスと非コア インターフェイスに応じて分割することもできます。また、リクエスト元 (To C と To B、APP と H5# など) に応じて分割することもできます。 ##)。

最後の言葉

高い同時実行性は確かに複雑かつシステム的な問題です。スペースが限られているため、分散トレース、フルリンク ストレス テスト、柔軟なトランザクションなどが必要になります。すべては考慮すべき技術的な点です。また、ビジネスシナリオが異なれば、高同時実行性の実装ソリューションも異なりますが、全体的な設計思想や参考にできるソリューションは基本的に似ています。

同時実行性の高い設計では、 アーキテクチャ設計の 3 つの原則 (単純さ、適切さ、進化) も遵守する必要があります。 「時期尚早な最適化は諸悪の根源である」、 はビジネスの の実際の状況から切り離すことはできず、 過度に設計しないでください。 適切なソリューションが最も完璧です。 この記事によって、高同時実行性についてより包括的な理解が得られることを願っています。また、学ぶことができる経験や深い考え方をお持ちの場合は、コメントにメッセージを残してください。ディスカッションのためのエリア。

以上がインタビュアー: 高同時実行性についてどのくらい知っていますか?私：うーん...の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。