mysql 大規模 Web サイトの技術アーキテクチャの中核となる原則は何ですか?

1. 大規模 Web サイト アーキテクチャの進化

A. 大規模 Web サイト ソフトウェア システムの特徴

高い同時実行性、大規模トラフィック、高可用性、大量のデータ、広範囲に分散したユーザーと複雑なネットワーク条件、劣悪なセキュリティ環境、要件の急速な変化と頻繁なリリース、漸進的な開発、

B. 大規模なシステムの進化と開発プロセススケール Web サイト アーキテクチャ

1. 初期段階: 1 台のサーバー、LNMP

2. アプリケーション サービスとデータ サービスの分離: アプリケーション サーバー (CPU)、データベース サーバー (高速ディスク検索とデータ キャッシュ)、ファイル サーバー (大容量のハードディスク) ;

3. キャッシュを使用して Web サイトのパフォーマンスを向上させる: アプリケーション サーバーにキャッシュされたローカル キャッシュ (高速アクセス、アプリケーション サーバーのメモリによる制限、データ量の制限)、リモート分散キャッシュ (クラスタを使用して大容量メモリを展開) サーバーは専用のキャッシュ サーバーとして機能します)

4. アプリケーション サーバー クラスター: 負荷分散によるスケジューリング

5. データベースの読み取りと書き込みの分離

6. リバース プロキシと CDN アクセラレーションの使用 : CDN (最も近いネットワーク コンピューター ルームに展開)、リバース プロキシ (中央のコンピューター ルームに展開)

#7. 分散ファイル システムと分散データベースの使用システム

8. NoSQL と検索エンジンを使用します

9. 事業分割

10. 分散サービス

C. の値大規模 Web サイト アーキテクチャの進化

1 。大規模 Web サイト アーキテクチャ技術の核となる価値は、Web サイトのニーズに柔軟に対応することです。

2。開発を推進する主力大規模 Web サイト技術の開発は Web サイトのビジネス開発です。

#D.Web サイト アーキテクチャ設計の誤解

#1. 大企業のソリューションに盲従する

2. テクノロジーのためのテクノロジー

##3. あらゆる問題をテクノロジーで解決しようとする: テクノロジーはビジネス上の問題を解決するために使用され、ビジネス上の問題はビジネス手段によっても解決できます

#2. 大規模な Web サイト アーキテクチャ モデル

各モデルは、継続的に繰り返される問題と、その問題のソリューション コアを表します。こうすることで、作業を重複させることなく、ソリューションを何度も使用できます。パターンの鍵となるのは、パターンの再現性です。

#A. Web サイト アーキテクチャ パターン

1. 階層化

階層化: エンタープライズ アプリケーション システムで最も一般的です。システムを水平方向にいくつかの部分に分割し、各部分が比較的単一の責任を担い、その後、下位層に対する上位層の依存と呼び出しを通じて完全なシステムを形成するアーキテクチャ パターン。

#Web サイトのソフトウェア システムは、アプリケーション層 (ビュー層、ビジネス ロジック層)、サービス層 (データ インターフェイス層、論理処理層)、データ層に分かれています

• 
  

巨大なソフトウェア システムをさまざまな部分に分割することで、分業と共同開発とメンテナンスを容易にすることができます。呼び出しインターフェイスは変更されず、他の層が対応する調整を行う必要がなく、各層が特定の問題に応じて独立して開発を進めることができます。

• 
  

2. セグメンテーション

• 
  

  垂直に切ります。さまざまな機能とサービスを分離し、それらを高い結合性と低い結合性を備えたモジュール式ユニットにパッケージ化します。大規模な Web サイトのセグメンテーションの粒度は非常に小さくなることがあります。

3. 分散

• 
  

  つまり、さまざまなモジュールがさまざまなサーバーにデプロイされ、リモート呼び出しを通じて連携します。これは、同じ機能を実行するためにより多くのコンピュータを使用できることを意味します。

問題: ネットワークはパフォーマンスに重大な影響を与える可能性があり、複数のサーバーのダウンタイムが発生する可能性が高く、分散環境ではデータの一貫性を維持することも非常に困難です。これにより、Web サイトが複雑な開発、処理、メンテナンスに依存することが困難になります。

• 
  

#一般的な分散ソリューション: 分散アプリケーションとサービス、分散静的リソース、分散データとストレージ、分散コンピューティング(Hadoop とその MapReduce)、分散構成、分散ロック、分散ファイルなど;

• 
  

4. クラスター

• 
  

  # #Multipleサーバーは同じアプリケーションを展開してクラスターを形成し、負荷分散装置を通じて外部サービスを共同で提供します。

#5. キャッシュ

• 
  キャッシュとは、処理を高速化するために、計算に最も近い場所にデータを保存することです。

CDN、リバース プロキシ、ローカル キャッシュ、分散キャッシュ。

• 
  #キャッシュを使用するための 2 つの前提条件: 1 つ目は、データ アクセス ホットスポットのバランスが取れていないこと、2 つ目は、データが一定期間内に有効であること、

• 
  6. 非同期

• ビジネス間のメッセージ受け渡しは同期呼び出しではなく、ビジネス操作が複数のステージに分割され、各ステージが共有されます。データは非同期で実行され、共同作業が行われます。
  

#単一サーバーは、マルチスレッド共有メモリ キューを通じて非同期実行を実現できます。分散システムでは、複数のサーバー クラスタが分散メッセージ キューを通じて非同期実行を実現できます。

• 一般的な生産者/消費者モデルでは、生産者と消費者の間に直接の呼び出し関係はなく、システムの可用性を向上できることがこのモデルの特徴です。 、Web サイトの応答速度を向上させ、同時アクセスのピークを排除します。
  

• 非同期メソッドを使用してビジネスを処理すると、ユーザー エクスペリエンスとビジネス プロセスに影響を与える可能性があり、製品設計のサポートが必要になります。
  

7. 冗長性

• サーバーがダウンしてもデータを失わずに Web サイトが引き続きサービスを提供できるようにするには、ある程度のサーバー冗長化運用とデータ冗長化バックアップが必要です。
  

• 小規模な Web サイトでもクラスターを構築するには少なくとも 2 台のサーバーが必要です。コールド バックアップを実現するための定期的なバックアップとストレージに加えて、データベースもマスターとサーバー間で共有する必要があります。スレーブ、リアルタイム同期、ホット バックアップ。
  

• #大企業では、データ センター全体をバックアップし、ローカルの災害復旧センターと同期する場合があります。
  

8. 自動化

• 主にリリースの運用と保守に焦点を当てます。
  

• リリース プロセスの自動化: 自動コード管理、自動テスト、自動セキュリティ検出、自動デプロイメント。
  

• 自動監視: 自動アラーム、自動フェイルオーバー、自動障害回復、自動機能低下、自動リソース割り当て。
  

9. セキュリティ

B. 新浪微博におけるアーキテクチャ パターンの適用

#3 、大規模 Web サイトの中核となるアーキテクチャ要素

アーキテクチャ: 最高レベルの計画であり、変更が難しい決定。

ソフトウェア アーキテクチャ: ソフトウェアの全体的な構造とコンポーネントの抽象的な説明。大規模なソフトウェア システムのあらゆる側面の設計をガイドするために使用されます。

#A. パフォーマンス

• ブラウザ側: ブラウザ キャッシュ、ページ圧縮、合理的なレイアウト、Cookie 送信の削減、CDN など。

  
  

アプリケーション サーバー側: サーバーのローカル キャッシュ、分散キャッシュ、非同期操作とメッセージ キューの連携、クラスタリングなど。

• 
  

コード: マルチスレッド、メモリ管理の改善など

• 
  

データベース: インデックス作成、キャッシュ、SQL 最適化、NoSQL テクノロジー

• 
  

# #B. 可用性

#サーバー、データベース、ファイル ストレージなどの環境を実行する主な手段は冗長性です。

• 
  

  #ソフトウェアを開発するとき、私たちはリリース前検証、自動テスト、自動リリース、グレースケール リリースなどを使用します。

• 
  

C. スケーラビリティ

スケーラビリティとは、クラスタにサーバーを継続的に追加することで、同時ユーザー アクセスのプレッシャーの高まりとデータ ストレージへの需要の増大を緩和することを指します。新しいサーバーを追加した場合に、元のサーバーと同じサービスを提供できるかどうか。

• 
  

  アプリケーション サーバー: サーバーは、適切な負荷分散装置を通じてクラスターに継続的に追加できます。

• 
  

  キャッシュ サーバー: 新しいキャッシュ サーバーを追加すると、キャッシュ ルートが無効になる可能性があります。ルーティングアルゴリズムが必要です。

• 
  

  リレーショナル データベース: ルーティング パーティショニングやその他の手段による。

• 
  

D. スケーラビリティ

測定基準: Web サイトにビジネス製品を追加したときに、それが達成できるかどうか既存の製品は透過的で影響がない、異なる製品間の結合がほとんどないかどうか、

• 
  

  意味: イベント駆動型アーキテクチャ (メッセージ キュー)、分散サービス (ビジネスとサービスの結合)利用可能なサービス共有、分散サービス フレームワークを通じて呼び出されます)

• 
  

E. セキュリティ

4. 即時応答: Web サイト高-パフォーマンス アーキテクチャ

A. Web サイトのパフォーマンス テスト

1. さまざまな視点からの Web サイト

ユーザーの視点からのパフォーマンス: ページの HTML スタイルを最適化し、ブラウザーの同時実行機能と非同期機能を利用し、ブラウザーのキャッシュ戦略を調整し、CDN サービス、リフレクション プロキシなどを使用します。

• 
  

開発者の観点から見た Web サイトのパフォーマンス: キャッシュを使用してデータ読み取りを高速化し、クラスターを使用してスループットを向上させ、非同期メッセージを使用してリクエスト応答を高速化し、ピーククリッピングを達成します。コード最適化メソッドを使用して、プログラムのパフォーマンスを向上させます。

• 
  

運用および保守担当者の観点から見た Web サイトのパフォーマンス: バックボーン ネットワークの構築と最適化、コスト効率の高いカスタマイズされたサーバーの使用、リソース使用率を最適化するための仮想化テクノロジーの使用など。

• 
  

2. パフォーマンス テスト指標

応答時間: テスト方法は、リクエストを繰り返し、合計テスト時間を分割することです。 10,000回 1万回かかります。

• 
  

同時実行数: システムが同時に処理できるリクエストの数 (Web サイト システム ユーザーの数 >>Web サイトのオンライン ユーザーの数 >>数値)同時 Web サイト ユーザーの数)、テスト プログラム 複数のスレッドを介して同時ユーザーをシミュレートすることにより、システムの同時処理能力をテストします。

• 
  

スループット: 単位時間あたりにシステムによって処理されるリクエストの数 (TPS、HPS、QPS など)

• 
  

パフォーマンス カウンター: サーバーまたはオペレーティング システムのパフォーマンスを記述する一部のデータ ジョイスティック。この文を書き直したものは次のとおりです。これには、システム負荷、オブジェクトとスレッドの数、メモリ使用量、CPU 使用量、ディスクとネットワーク I/O が含まれます。

• 
  

3. パフォーマンス テストの方法: パフォーマンス テスト、負荷テスト、ストレス テスト、安定性テスト

性能テストは、システムの性能指標、最大負荷容量、および最大圧力耐久性を取得するために、システムに継続的に負荷を加えるために実行されます。いわゆるアクセス圧力の増加とは、テスト プログラムに対する同時リクエストの数が継続的に増加することを意味します。

5. パフォーマンス最適化戦略

• パフォーマンス分析: リクエスト処理の各リンクのログを確認し、どのリンクが応答時間が不当であるか、または期待を超えているかを分析します。監視データを確認してください。
  

B. Web フロントエンドのパフォーマンスの最適化

1. ブラウザ アクセスの最適化: http リクエストの削減 (CSS/JS/ のマージ)画像 )、ブラウザーのキャッシュを使用 (HTTP ヘッダーのキャッシュ制御と有効期限)、圧縮 (Gzip) を有効にし、CSS をページの上部に配置し、JS をページの下部に配置し、Cookie の送信を削減します

2 .CND アクセラレーション

3. リバース プロキシ: キャッシュ機能を設定することで Web リクエストを高速化します。 (実サーバーの保護や負荷分散機能の実装も可能)

#C. アプリケーションサーバーのパフォーマンスの最適化##1. 分散キャッシュ

#Web サイトのパフォーマンス最適化の第一法則: キャッシュの使用を優先してパフォーマンスを最適化する

• 
  

  キャッシュは主に、読み取り/書き込み比率が高く、めったに変わりません。キャッシュにヒットできない場合は、データベースが読み取られ、データが再度キャッシュに書き込まれます。

• 
  

  2. キャッシュの合理的な使用: データを頻繁に変更しない、ホット スポットのないアクセス、データの不整合とダーティ リード、キャッシュの可用性 (キャッシュ ホット スタンバイ)、キャッシュのウォーム- up (プログラムの開始時に一部のキャッシュをプリロード)、キャッシュの侵入

3. 分散キャッシュ アーキテクチャ: 同期して更新する必要がある分散キャッシュ (JBoss Cache)、相互に通信しない分散キャッシュ (Memcached)

4. 非同期操作: ピークカット効果が高いメッセージ キューを使用します (Web サイトのスケーラビリティとパフォーマンスを向上させることができます)。メッセージキューに格納されます。

5. クラスターを使用します

6. コードの最適化:

マルチスレッド (IO ブロッキングとマルチ CPU、起動スレッドの数 = [タスク実行時間 /(タスク実行時間 - IO 待機時間)]*CPU コア数、スレッドの安全性に注意する必要があります: オブジェクトをステートレス オブジェクトとして設計し、ローカル オブジェクトを使用し、リソースに同時にアクセスする場合はロックを使用します);

• 
  

  リソースの再利用 (単一のケースとオブジェクト プール);

• 
  

  データ構造;

• 
  

  ガベージ コレクション

• 
  

D. ストレージ パフォーマンスの最適化

1. データベースは主に 2 レベルのインデックスを持つ B ツリーを使用します。 、ツリーには最も多くのレベルがあり、3 つのフロアがあります。レコードを更新するには、5 回のディスク アクセスが必要になる場合があります。

2. 非常に多くの NoSQL 製品は、N 次マージ ツリーとみなせる LSM ツリーを使用しています。

3. RAID (安価なディスクの冗長アレイ)、RAID0、RAID1、RAID10、RAID5、RAID6 は、従来のリレーショナル データベースおよびファイル システムで広く使用されています。

4.HDFS (Hadoop 分散ファイル システム) は、MapReduce と連携してビッグ データを処理します。

5. 確実: Web サイトの高可用性アーキテクチャ

A. Web サイトのユーザビリティの測定と評価

1 . Web サイトの可用性の測定

Web サイトが利用できない時間 (ダウンタイム時間) = 障害修復時点 - 障害発見 (レポート) 時点

• 
  

  Web サイトの年間可用性インデックス = (1 つの Web サイトが利用できない時間 / 年間合計時間)*100%

• 
  

  2 9 は基本的に利用可能で、88 時間、9 が 3 つあるとさらに高可用性になります、9 時間、4 9 は自動回復機能を備えた高可用性、53 分、5 9 は 5 分未満の非常に高い可用性、QQ は 99.99、4 9 で、年間約 53 分間利用できなくなります。

• 
  #2. Web サイトのユーザビリティ評価

障害スコア: Web サイトの障害を分類および重み付けして、障害の責任を計算する方法を指します

• 
  障害スコア = 障害時間 (分) * 障害の重み

• 
  

  B. 高可用性 Web サイト アーキテクチャ

主な方法は、データとサービスの冗長バックアップとフェイルオーバーです。アプリケーション層とサービス層はクラスター負荷分散を使用して高可用性を実現し、データ層はデータ同期レプリケーションを使用して冗長バックアップを実現します。

C. 高可用性アプリケーション

1. 負荷分散によるステートレス サービスのフェイルオーバー: アプリケーションのアクセスが非常に小さい場合でも、少なくとも 2 台のサーバーをデプロイする必要があります。負荷分散を使用すると、小さなクラスターが構築されます。 2. アプリケーション サーバー クラスターのセッション管理

セッション レプリケーション: サーバー間のセッション同期、小規模クラスター

• 
  #セッション バインディング: ソース アドレス ハッシュを使用して、同じ IP から発信されたリクエストを同じサーバーに分散します。これは高可用性に影響します。

• #Cookie を使用してセッションを記録します。サイズ制限があり、各リクエストの応答を送信する必要があります。Cookie をオフにすると、アクセスできなくなります
  

• # #セッション サーバー: 分散キャッシュ、データベースなどを使用し、高可用性、高スケーラビリティ、優れたパフォーマンスを実現します

  
  

• D . 高可用性サービス
  

1. 階層管理: サーバーは階層的に運用・保守されており、コアアプリケーションとサービスはより優れたハードウェアを優先的に使用し、運用・保守の応答速度も非常に高速です。

2. タイムアウト設定: アプリケーション内のサービス呼び出しのタイムアウト期間を設定します。タイムアウトが経過すると、通信フレームワークは例外をスローします。サービス スケジュール ポリシーに基づいて、アプリケーションは再試行を続行するか、サービスを転送するかを選択できます。他のサーバー上で同じサービスを提供するサーバーにリクエストを送信します。

アプリケーションは、サービスの失敗時にアプリケーションのリクエスト全体が失敗する状況を回避するために、メッセージ キューなどの非同期メソッドを通じてサービスへの呼び出しを完了します。

4. サービスの低下: サービスを拒否し、優先度の低いアプリケーションからの呼び出しを拒否するか、一部の要求呼び出しをランダムに拒否します。機能を閉じるか、一部の重要でないサービスを閉じるか、一部の重要でない機能を内部で閉じます。

5. 冪等設計: サービス層では、サービスを繰り返し呼び出しても 1 回呼び出した場合と同じ結果が得られることが保証されており、サービスは冪等です。

#E. 高可用性データ

1.CAP 原則

• 高可用性データ: データの永続性 (永続的なストレージ、バックアップ)コピーは失われません）、データへのアクセス性（異なるデバイス間の素早い切り替え）、データの一貫性（複数のコピーの場合、コピーデータの一貫性が保証されます）

  
  

• CAP原則：データサービスを提供するストレージシステムは、データの一貫性（Consistency）、データの可用性（Availability）、パーティショントレランス（Partition Tolerance（システムがネットワークパーティションをまたがる拡張性を持つ））の3つの条件を同時に満たすことはできない。

  
  

• 通常、大規模な Web サイトでは、分散システムの可用性 (A) とスケーラビリティ (P) が向上しますが、一貫性 (C) はある程度犠牲になります。一般に、データの不整合はシステムの同時書き込み処理が多い場合やクラスタの状態が不安定な場合に発生することが多く、アプリケーションシステムは分散データ処理システムのデータの不整合を理解し、ある程度の補償やエラー訂正を行う必要があります。アプリケーション システム データが正しくありません。

  
  

• データの一貫性は、強力なデータの一貫性 (すべての操作が一貫している)、データ ユーザーの一貫性 (コピーには一貫性がない可能性がありますが、ユーザーがアクセスするとエラー修正が実行されます) に分類できます。検証により、正しいデータがユーザーに返されることが確認され、データは最終的に一貫性があることが確認されます (コピーとユーザー アクセスは一貫性がない可能性がありますが、システムは一定期間の自己回復と修正の後に一貫性に達します)

  
  

2. データ バックアップ

• 非同期ホット バックアップ: 複数のデータ コピーの書き込み操作は非同期で完了します。書き込み操作のデータ サービス システムでは、書き込みのみが行われます。1 つのコピーが成功すると、ストレージ システムは他のコピーを非同期で書き込みます (失敗する可能性があります)

  
  

• 同期ホット バックアップ:複数のデータ コピーの書き込み操作は同期的に完了します。つまり、アプリケーション プログラムがデータ サービス システムから書き込み成功応答を受信すると、データの複数のコピーが正常に書き込まれています。

  
  

#3. フェイルオーバー

障害確認: ハートビート検出、アプリケーションアクセス障害

• 
  

アクセス転送: サーバーがダウンしていることを確認した後、データの読み取りおよび書き込みアクセスを他のサーバーに再ルーティングします。

• 
  

データ復旧: 正常なサーバーからデータをコピーし、データ コピーの数を設定値に復元します

• 
  

F. 高可用性 Web サイトのソフトウェア品質保証

1. Web サイトrelease

2. 自動テスト: Selenium

ツールは、プレリリース サーバー上でプレリリース検証を実行します。まず、開発エンジニアが使用できるように、プレリリース マシンにリリースします。テストエンジニアです。構成、環境、データセンターなどは本番環境と同じである必要があります

4. コード管理: svn、git; トランク開発、ブランチリリース; ブランチ開発、トランクリリース (メインストリーム);

5. 自動リリース

#6. グレースケール リリース: クラスター サーバーをいくつかの部分に分割し、毎日一部のサーバーのみをリリースし、動作が安定していて障害がないことを確認します。期間中に問題が見つかった場合は、リリースされたサーバーの一部をロールバックするだけで済みます。ユーザーテスト（ABテスト）にもよく使われます。

G. Web サイトの動作監視

1. 監視データの収集

オペレーティング システムや Web サイトなどのユーザーの行動ログを収集します。ブラウザのバージョン、IP アドレス、ページのアクセス パス、ページの滞在時間、その他の情報。サーバー側のログ収集とクライアント側のブラウザーのログ収集が含まれます。

• 
  

サーバー パフォーマンスの収集: システム負荷、メモリ使用量、ディスク IO、ネットワーク IO など、ツール Ganglia など。

• 
  

実行データ レポート: バッファ ヒット率、平均応答遅延時間、1 分あたりに送信される電子メールの数、処理されるタスクの総数など。

• 
  

2. 監視と管理

システム アラーム: さまざまな監視インジケーターのしきい値を設定し、電子メールやインスタント メッセージング ツール、SMS を使用します。およびその他のアラーム

• 
  

障害転送: フェイルオーバーを実行するようにアプリケーションに積極的に通知します

• 
  

自動正常なダウングレード: 監視に基づいてパラメーターはアプリケーションの負荷を決定し、低負荷のアプリケーションを含む一部のサーバーを適切にアンインストールし、高負荷のアプリケーションを再インストールしてアプリケーション全体の負荷のバランスをとります。

• 
  

6. 終わりのない: Web サイトのスケーラビリティ アーキテクチャ

Web サイトのいわゆるスケーラビリティとは、 Web サイトを変更する必要はありません ソフトウェアとハ​​ードウェアの設計により、導入されているサーバーの数を変更するだけで、Web サイトのサービス処理能力を拡張または縮小できます。

A. Web サイト アーキテクチャのスケーラビリティ設計

1. スケーリングを実現するためのさまざまな機能の物理的な分離: 垂直方向の分離 (階層化後の分離)、ビジネス処理プロセスの異なる部分を分離するシステムの拡張性を実現するための導入、水平分離（事業分割後の分離）、システムの拡張性を実現するための異なるビジネスモジュールの個別の導入。

2. 単一の機能はクラスター スケールを通じて拡張可能

B. アプリケーション サーバー クラスターのスケーラビリティ設計

1. アプリケーション サーバーは次のとおりである必要があります。シームレスなステートフルになるように設計されており、リクエストのコンテキスト情報は保存されません。

2. 負荷分散:

• HTTP リダイレクト負荷分散: ユーザーの HTTP リクエストに基づいて実際の Web サーバー アドレスを計算し、ユーザーのサーバー アドレスに返されるサーバー アドレスを書き込みます。 HTTP リダイレクト応答内のブラウザ。このソリューションには利点もありますが、欠点としては、2 つのリクエストが必要であること、リダイレクト サーバー自体の処理能力が制限される可能性があること、さらに 302 ジャンプが SEO に影響を与える可能性があることです。
  

• DNS ドメイン名解決の負荷分散: 異なる IP を指すように DNS サーバー上の複数の A レコードを構成すると、負荷分散作業が DNS に転送されるという利点があります。多くは地理的位置もサポートしており、最も近いサーバーを返します。欠点は、A レコードがキャッシュされる可能性があり、制御はドメイン ネーム サービス プロバイダーにあることです。
  

• リフレクティブ プロキシ ロード バランシング: ブラウザによって要求されたアドレスはリバース プロキシ サーバーです。リバース プロキシ サーバーはリクエストを受信した後、負荷に基づいて実サーバーを計算します。バランシングアルゴリズム. 物理サーバーのアドレスを指定してリクエストを実サーバーに転送し、処理が完了するとレスポンスがリバースプロキシサーバーに返され、リバースプロキシサーバーはユーザーにレスポンスを返します。アプリケーション層 (HTTP 層) 負荷分散とも呼ばれます。その導入は簡単ですが、リバース プロキシのパフォーマンスがボトルネックになる可能性があります。
  

• IP 負荷分散: ユーザー要求データ パケットが負荷分散サーバーに到達すると、負荷分散サーバーはオペレーティング システムのカーネル プロセスでネットワーク データ パケットを取得し、負荷分散アルゴリズムに基づいて実 Web サーバーにロード バランシング アルゴリズムを実行し、ユーザー プロセスによる処理を必要とせずに、データの宛先 IP アドレスを実サーバーに変更します。実サーバーの処理が完了すると、応答パケットは負荷分散サーバーに戻り、負荷分散サーバーはパケットの送信元アドレスを独自の IP アドレスに変更してユーザーのブラウザに送信します。
  

• データリンク層の負荷分散: トライアングル送信モード。負荷分散サーバーのデータ分散プロセス中に IP アドレスは変更されず、宛先 MAC アドレスのみが変更されます。すべてのサーバーの仮想 IP を経由する アドレスは負荷分散サーバーの IP アドレスと一致します データ パケットの送信元アドレスと宛先アドレスは変更されません IP が一致しているため、応答データ パケットを直接返すことができますユーザーのブラウザ。ダイレクト ルーティング (DR) とも呼ばれます。製品LVS (Linux Virtual Server)を表します。
  

3. 負荷分散アルゴリズム:

• ラウンド ロビン (RR): すべてのリクエストがプールされ、各アプリケーションに分散されます。サーバー
  

• #加重ラウンドロビン (WRR): サーバーのハードウェアのパフォーマンスに基づいて、ポーリングに基づいて設定された重みに従って配信が実行されます

  
  

• ランダム: リクエストは各アプリケーション サーバーにランダムに分散されます

  
  

• 最小接続数: レコード サーバーが処理中の接続数。新しいリクエストは次のアプリケーション サーバーに分散されます。接続数が最も少ないサーバー

  
  

#ソース アドレス ハッシュ (ソース ハッシュ): リクエストのソースの IP アドレスに基づくハッシュ計算

• 
  

#C. 分散キャッシュ クラスターのスケーラビリティ設計

1. Memcached 分散キャッシュ クラスターのアクセス モデル# #KEY を介してルーティング アルゴリズム モジュールに入り、ルーティング アルゴリズムは、読み取りと書き込みのために Memcached サーバーを計算します。

2. Memcached 分散キャッシュ クラスターのスケーラビリティの課題

単純なルーティング アルゴリズムは、キャッシュされたデータ KEY のハッシュ値をサーバーの数で割って、剰余ハッシュ法を使用することです。残りは対応するサーバー番号です。うまくスケールできません。

3. 分散キャッシュの

一貫性のあるハッシュ アルゴリズム

まず、ノードに従って長さ 2 の 32 乗の整数リング (一貫性のあるハッシュ リング) を構築します。名前のハッシュ値により、キャッシュ サーバー ノードがこのハッシュ リングに配置されます。次に、キャッシュする必要があるデータの KEY 値に基づいてハッシュ値を計算し、ハッシュ リング上で時計回りに KEY のハッシュ値に最も近いキャッシュ サーバー ノードを検索して、KEY からキーへのハッシュ マッピングの検索を完了します。サーバ。

D. データ ストレージ サーバー クラスターのスケーラビリティ設計

1. リレーショナル データベース クラスターのスケーラビリティ設計

データ レプリケーション (マスター/スレーブ)、スプリットテーブル、データベース、データ シャーディング (Cobar)

2. NoSQL データベースのスケーラビリティ設計

NoSQL はリレーショナル代数と SQL (Structured Query Language) に基づく正規化を放棄します データ モデルもトランザクションを保証しません一貫性 (ACID)。高可用性と拡張性が強化されました。 (Apache HBase)

以上がmysql 大規模 Web サイトの技術アーキテクチャの中核となる原則は何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。