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

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 サイトのセグメンテーションの粒度は非常に小さくなることがあります。

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

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

#5. キャッシュ

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

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

#キャッシュを使用するための 2 つの前提条件: 1 つ目は、データアクセスホットスポットのバランスが取れていないこと、2 つ目は、データが一定期間内に有効であること、
6. 非同期
ビジネス間のメッセージ受け渡しは同期呼び出しではなく、ビジネス操作が複数のステージに分割され、各ステージが共有されます。データは非同期で実行され、共同作業が行われます。

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

一般的な生産者/消費者モデルでは、生産者と消費者の間に直接の呼び出し関係はなく、システムの可用性を向上できることがこのモデルの特徴です。、Web サイトの応答速度を向上させ、同時アクセスのピークを排除します。
非同期メソッドを使用してビジネスを処理すると、ユーザーエクスペリエンスとビジネスプロセスに影響を与える可能性があり、製品設計のサポートが必要になります。

7. 冗長性

サーバーがダウンしてもデータを失わずに Web サイトが引き続きサービスを提供できるようにするには、ある程度のサーバー冗長化運用とデータ冗長化バックアップが必要です。
小規模な Web サイトでもクラスターを構築するには少なくとも 2 台のサーバーが必要です。コールドバックアップを実現するための定期的なバックアップとストレージに加えて、データベースもマスターとサーバー間で共有する必要があります。スレーブ、リアルタイム同期、ホットバックアップ。
#大企業では、データセンター全体をバックアップし、ローカルの災害復旧センターと同期する場合があります。

8. 自動化

主にリリースの運用と保守に焦点を当てます。
リリースプロセスの自動化: 自動コード管理、自動テスト、自動セキュリティ検出、自動デプロイメント。
自動監視: 自動アラーム、自動フェイルオーバー、自動障害回復、自動機能低下、自動リソース割り当て。

9. セキュリティ

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

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

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

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

#A. パフォーマンス

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

# #B. 可用性

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

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

アプリケーションサーバー: サーバーは、適切な負荷分散装置を通じてクラスターに継続的に追加できます。
キャッシュサーバー: 新しいキャッシュサーバーを追加すると、キャッシュルートが無効になる可能性があります。ルーティングアルゴリズムが必要です。
リレーショナルデータベース: ルーティングパーティショニングやその他の手段による。

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

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

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

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

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

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

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 コア数、スレッドの安全性に注意する必要があります: オブジェクトをステートレスオブジェクトとして設計し、ローカルオブジェクトを使用し、リソースに同時にアクセスする場合はロックを使用します);

リソースの再利用 (単一のケースとオブジェクトプール);
データ構造;
ガベージコレクション

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 . 高可用性サービス

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

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

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

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

#E. 高可用性データ

1.CAP 原則

高可用性データ: データの永続性 (永続的なストレージ、バックアップ)コピーは失われません）、データへのアクセス性（異なるデバイス間の素早い切り替え）、データの一貫性（複数のコピーの場合、コピーデータの一貫性が保証されます）
CAP原則：データサービスを提供するストレージシステムは、データの一貫性（Consistency）、データの可用性（Availability）、パーティショントレランス（Partition Tolerance（システムがネットワークパーティションをまたがる拡張性を持つ））の3つの条件を同時に満たすことはできない。
通常、大規模な Web サイトでは、分散システムの可用性 (A) とスケーラビリティ (P) が向上しますが、一貫性 (C) はある程度犠牲になります。一般に、データの不整合はシステムの同時書き込み処理が多い場合やクラスタの状態が不安定な場合に発生することが多く、アプリケーションシステムは分散データ処理システムのデータの不整合を理解し、ある程度の補償やエラー訂正を行う必要があります。アプリケーションシステムデータが正しくありません。
データの一貫性は、強力なデータの一貫性 (すべての操作が一貫している)、データユーザーの一貫性 (コピーには一貫性がない可能性がありますが、ユーザーがアクセスするとエラー修正が実行されます) に分類できます。検証により、正しいデータがユーザーに返されることが確認され、データは最終的に一貫性があることが確認されます (コピーとユーザーアクセスは一貫性がない可能性がありますが、システムは一定期間の自己回復と修正の後に一貫性に達します)

2. データバックアップ

非同期ホットバックアップ: 複数のデータコピーの書き込み操作は非同期で完了します。書き込み操作のデータサービスシステムでは、書き込みのみが行われます。1 つのコピーが成功すると、ストレージシステムは他のコピーを非同期で書き込みます (失敗する可能性があります)
同期ホットバックアップ:複数のデータコピーの書き込み操作は同期的に完了します。つまり、アプリケーションプログラムがデータサービスシステムから書き込み成功応答を受信すると、データの複数のコピーが正常に書き込まれています。

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

1. Web サイトrelease

2. 自動テスト: Selenium

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

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

5. 自動リリース

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

G. Web サイトの動作監視

1. 監視データの収集

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): サーバーのハードウェアのパフォーマンスに基づいて、ポーリングに基づいて設定された重みに従って配信が実行されます
ランダム: リクエストは各アプリケーションサーバーにランダムに分散されます
最小接続数: レコードサーバーが処理中の接続数。新しいリクエストは次のアプリケーションサーバーに分散されます。接続数が最も少ないサーバー

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 サイトの他の関連記事を参照してください。