大規模 Web サイトのアーキテクチャの進化と知識システム_PHP チュートリアル
LiveJournal や eBay など、大規模な Web サイトのアーキテクチャの進化を紹介する記事はこれまでにもいくつかあり、非常に参考になりますが、その理由を詳細に説明するよりも、それぞれの進化の結果について詳しく述べているように感じます。このような進化の後、多くの学生がなぜ Web サイトにこれほど複雑なテクノロジーが必要なのかを理解するのが難しいと感じているという事実に加えて、この記事を書くことを思いつきました。通常の Web サイトから大規模な Web サイトのプロセスにおける比較的典型的なアーキテクチャの進化プロセスと、習得する必要がある知識システムについて説明します。これが、インターネットで働きたいと考えている学生にいくつかの予備的な概念を与えることができれば幸いです。業界:) この記事が新しいアイデアを呼び込む役割を果たすことができるように、記事に間違いがある場合はさらに提案をお願いします。
アーキテクチャ進化の最初のステップ: Webサーバーとデータベースを物理的に分離
最初は、いくつかのアイデアにより、インターネット上にWebサイトを構築しましたが、この時点では、ホストがインターネット上にある可能性さえありました。この記事では、アーキテクチャの進化のみに焦点を当てているため、この時点でホストはすでにホストされており、Web サイトには特定の特性があるため、一定の帯域幅を持っていると仮定します。何人かの人々が訪問し始めますが、徐々にシステムの負荷が高まり、応答速度がどんどん遅くなっていることがわかります。このとき、データベースとアプリケーションが相互に影響を与えていることがより明らかになります。アプリケーションに問題があると、データベースにも問題が発生しやすくなり、データベースに問題が発生すると、アプリケーションにも問題が発生しやすくなります。そこで、アプリケーションとデータベースを物理的に 2 つのマシンに分離するという進化の最初のステップに入りました。現時点では、新しい技術要件はありませんが、影響があることがわかり、システムは以前の応答速度に復元され、データベースとデータベースによって相互に影響を与えることなく、より高いトラフィックをサポートできるようになりました。応用。
このステップが完了した後のシステムの図を見てください:
このステップには次の知識システムが含まれます:
アーキテクチャの進化のこのステップには、基本的に技術的な知識システムの要件はありません。
アーキテクチャの進化の第 2 ステップ: ページ キャッシュの増加
訪問者が増えると、応答速度が再び遅くなり始めることに気づきます。データベースにアクセスする操作が多すぎると、データ接続の競争が激しくなり、応答が遅くなります。ただし、データベース接続をオープンしすぎると、データベース マシンへの負荷が非常に高くなります。したがって、データベース接続リソースの競合とデータベース読み取りの負荷を軽減するために、キャッシュ メカニズムの使用を検討してください。この時点では、まず、Squid および他の同様のメカニズムを使用して、システム内の比較的静的なページ (ページなど) をキャッシュすることを選択できます。 1 ~ 2 日で更新されます) (もちろん、ページを静的にするソリューションを使用することもできます)。これにより、プログラムを変更せずに、Web サーバーへの負荷を大幅に軽減し、データベース接続リソースの競合を減らすことができます。 . それで、比較的静的なページをキャッシュするために Squid を使い始めました。
このステップが完了した後のシステムの図を見てください:
このステップには次の知識システムが含まれます:
Squid などのフロントエンド ページ キャッシュ テクノロジ。それをうまく使いたい場合は、イカメソッドやキャッシュ無効化アルゴリズムなどの実装を深くマスターする必要があります。
アーキテクチャ進化の第 3 ステップ: ページ フラグメント キャッシュの追加
キャッシュ用に Squid を追加した後、システム全体の速度は確かに向上し、Web サーバーへの負荷も減少し始めましたが、アクセス数が増加すると、システムが再び少し遅くなり始めることがわかりました。Squid などの動的キャッシュの利点を味わった後、現在の動的ページの比較的静的な部分もキャッシュできるのではないかと考え始めました。 , そこで、ESI などのページ フラグメント キャッシュ戦略のようなものを使用することを検討しました。そこで、動的ページの比較的静的なフラグメント部分をキャッシュするために ESI を使用し始めました。
このステップが完了した後のシステムの図を見てください:
このステップには次の知識システムが含まれます:
ESI などのページ フラグメント キャッシュ テクノロジ。これをうまく使用したい場合は、 ESI などの実装もマスターする必要があります。;
アーキテクチャ進化の第 4 ステップ: データ キャッシュ
ESI などのテクノロジーを使用してシステムのキャッシュ効果を再度改善した後、システムへの負荷は実際にさらに軽減されましたが、アクセス数が増加すると、検索後にシステムの速度が低下し始める可能性があります。ユーザー情報の取得など、データ情報を繰り返し取得する箇所があったので、このデータ情報もキャッシュできないかと検討し、変更後のデータをローカルメモリにキャッシュしました。システムの応答速度は再び回復し、データベースへの負担も大幅に軽減されました。
このステップが完了した後のシステムの図を見てください:
このステップには次の知識システムが含まれます:
マップデータ構造、キャッシュアルゴリズム、選択したフレームワーク自体の実装メカニズムなどを含むキャッシュテクノロジー。
アーキテクチャ進化の 5 番目のステップ: Web サーバーの追加
好調な時期は長くは続かず、システムのアクセス数が再び増加すると、Web サーバー マシンへの負荷が相対的に上昇することがわかりました。この時点で、Web サーバーを追加することを検討し始めました。これは、可用性の問題を解決すると同時に、単一の Web サーバーがダウンした場合に使用できなくなることを防ぐためでもあります。 Web サーバーを追加する場合、次のような問題が発生します。
1. この時点で通常考えられる解決策は、Apache 独自の負荷分散ソリューションです。 LVS などのソフトウェア負荷分散ソリューション; 2. ユーザーセッションなどのステータス情報の同期を維持する方法。現時点で検討されるソリューションには、データベースへの書き込み、ストレージへの書き込み、またはセッションの同期が含まれます。情報およびその他のメカニズム
3. 以前にキャッシュされたユーザー データなどのデータ キャッシュ情報の同期を維持する方法。現時点で通常考慮されるメカニズムには、次のような同様の機能を作成する方法が含まれます。ファイルのアップロードは引き続き正常に動作します。現時点で通常考えられるメカニズムは、共有ファイル システムまたはストレージの使用です。これらの問題を解決した後、最終的に Web サーバーの数が 2 つに増加し、システムは最終的に以前の速度に戻りました。
このステップが完了した後のシステムの図を見てください:
このステップには次の知識システムが含まれます:
しばらくの間、システムのアクセス数が急速に増加するという幸福を味わった後、システムが再び速度を落とし始めていることに気付きました。検索した結果、データベースの書き込みおよび更新操作中にデータベース接続リソースの競合が非常に激しく、システムの速度が低下することがわかりました。現時点で利用できるオプションにはデータベースのクラスタリングとサブが含まれます。 - データベース戦略に関しては、データベースのサポートがあまり優れていないため、サブデータベースを実現するには元のプログラムを変更する必要があることがより一般的になります。 -データベース、はい、目標は達成され、システムの回復は以前よりもさらに速くなりました。
このステップが完了した後のシステムの図を見てください:このステップには次の知識システムが含まれます:
しかし同時に、データ量の増加とサブデータベースの進歩に伴い、データベースのより適切な設計、チューニング、メンテナンスを行う必要があるため、これらの側面におけるテクノロジーが必要になります。はまだ非常に要求が厳しいです。
アーキテクチャ進化の 7 番目のステップ: テーブル シャーディング、DAL、分散キャッシュ
システムが実行を続けると、データ量が大幅に増加し始めますが、この時点ではクエリがまだ少し遅いことがわかります。データベースが分割された後、サブデータベースのアイデアに従って、サブテーブルの作業を開始します。おそらく、この時点で、必然的にプログラムにいくつかの変更が必要になることがわかります。アプリケーション自体は、サブデータベースやサブテーブルなどのルールを考慮する必要があり、まだ少し複雑なので、さらに追加するかどうかを考えました。 サブデータベースとサブテーブルへのデータアクセスの実装には、一般的なフレームワークが使用されます。これは eBay のアーキテクチャにおける DAL に相当します。もちろん、この一般的なフレームワークは、テーブルが完成した後に作業を開始するまで待機する可能性もあります。同時に、この段階で以前のキャッシュ同期ソリューションでは問題が発生する可能性があります。データ量が多すぎるため、キャッシュをローカルに保存して、分散キャッシュを使用する必要があります。計画が立てられたため、さらなる調査と拷問の後、最終的に大量のデータ キャッシュが分散キャッシュに転送されました。
このステップが完了した後のシステムの図を見てください:
このステップには次の知識システムが含まれます:
サブテーブルもビジネス部門のようなもので、関連するテクノロジーは動的ハッシュになります。アルゴリズム、一貫性のあるハッシュ アルゴリズムなど。
DAL には、データベース接続管理 (タイムアウト、例外)、データベース操作制御 (タイムアウト、例外)、データベースとテーブルのシャーディング ルールのカプセル化など、多くの複雑なテクノロジが含まれます。
アーキテクチャ進化の 8 番目のステップ: Web サーバーを追加します
サブデータベースとテーブル サブデータベースの作業が完了した後、データベースへの負荷は比較的低いレベルに下がりました。再び毎日のアクセス数を監視し始めました。ある日突然、システムへのアクセスが再び遅くなり始めたことがわかりました。それは正常でした。その後、Web サーバーを確認したところ、Apache が多くのリクエストをブロックしており、各リクエストの数も比較的高速であることがわかりました。列に並んで待つ必要があり、応答速度が遅いため、一般的に、この時点ではある程度のお金があるので、ここに Web サーバーを追加します。課題:
1. Apache のソフト ロードまたは LVS ソフト ロードは、膨大な Web アクセス (要求された接続数、ネットワーク トラフィックなど) のスケジュールに耐えることができません。資金が許せば、解決策は購入することになります。 F5、Netsclar、Athelon などのハードウェア負荷。資金が許可されない場合、解決策は、アプリケーションを論理的に分類し、負荷クラスター内の別のソフトウェアに分散することです。
2.同期、ファイル共有、その他のソリューションにはボトルネックがあり、改善する必要があるかもしれません。おそらく、この時点で、Web サイトのビジネス ニーズを満たす分散ファイル システムが状況に応じて作成されるでしょう。 Web サイトのトラフィックが増加したとき、解決策は Web サーバーを継続的に追加することでした。
アーキテクチャ進化の第9ステップ: データの読み書きの分離と安価なストレージソリューション
ある日突然、この完璧な時代が終わりに近づいていることに気づき、データベースの悪夢が現れました。追加により、データベースとテーブルがデータベースとテーブルに分割されています。現時点では、データベースの読み取りと書き込みの比率が非常に高いことに気づくかもしれませんが、もちろん、データの読み取りと書き込みを分離するソリューションを実装するのは簡単ではありません。データベースに保存されたデータは無駄であるか、データベース リソースを過剰に消費するため、この段階で形成される可能性のあるアーキテクチャの進化は、データの読み取りと書き込みを分離し、BigTable などのより安価なストレージ ソリューションを作成することです。 。 このステップが完了した後のシステムの図を見てください:データの読み取りと書き込みの分離には、データベースのレプリケーション、スタンバイ、その他の戦略の深い理解と自己実装テクノロジも必要です。
安価なストレージ ソリューションには、OS ファイル ストレージの深い理解と理解が必要です。また、ファイルで使用される言語の実装を深く理解していることも必要です。
アーキテクチャ進化の第10ステップ: 大規模分散アプリケーションの時代と安価なサーバー群の夢の時代へ
上記の長くて苦痛なプロセスを経て、私たちはついに再び完璧な時代を迎えました継続的な増加により、Web サーバーはより高いアクセス数をサポートできるようになります。人気が高まるにつれて、さまざまな機能の需要も急激に増加し始めます。 Web サーバー上に元々デプロイされていた Web アプリケーションがすでに非常に大きく、複数のチームがそれに変更を加え始めたとき、それは非常に不便であり、基本的にどのチームも多かれ少なかれそれを繰り返す必要があることがわかりました。巨大なアプリケーションパッケージを N 台のマシンにコピーして起動するには時間がかかり、問題が発生したときの確認も容易ではないため、デプロイとメンテナンスも非常に面倒です。特定のアプリケーションのバグによりサイト全体が利用できなくなる可能性が非常に高く、チューニングが不十分であるなどの他の問題もあります (マシンにデプロイされたアプリケーションがすべてを行う必要があるため、基本的にターゲットを絞ったチューニングを実行することができません) ) などの分析に基づいて、システムを責任に応じて分割することを決定し始めたので、通常、このステップには時間がかかります。多くの課題:
1. 分散化した後は、高性能で安定した通信フレームワークを提供する必要があり、さまざまな通信およびリモート呼び出し方法をサポートする必要があります。
2. 巨大なアプリケーションを変換するには、長時間かかるため、ビジネス組織とシステムの依存関係の制御が必要です。
3. この巨大な分散アプリケーションの運用と保守の方法 (依存関係の管理、運用状況の管理、エラー追跡、チューニング、監視と警報など)。
このステップの後、システム アーキテクチャは比較的安定した段階に入ります。同時に、このアーキテクチャと学習した経験を組み合わせて、大量の訪問とデータをサポートするために多数の安価なマシンの使用を開始することもできます。増加するトラフィックをサポートするさまざまな方法が他にもあります。
このステップが完了した後のシステムの図を見てください:
このステップには次の知識システムが含まれます:
このステップには多くの知識システムが含まれており、通信、リモート通話、メッセージメカニズム、深く理解して習得するには、理論、ハードウェア レベル、オペレーティング システム レベル、および使用される言語の実装を明確に理解する必要があります。
運用と保守には、多くの場合、分散並列コンピューティング、レポート、監視テクノロジー、ルールと戦略などを習得する必要があります。
ウェブサイト全体のアーキテクチャの古典的な進化プロセスは、上記の比較と同様です。 もちろん、各ステップで実行される計画と進化の手順は異なる場合があります。さらに、Web サイトのビジネスが異なるため、専門的および技術的なニーズも異なります。もちろん、このブログでは、データベース クラスターやデータ マイニングなど、ここで言及されていないテクノロジーの進化プロセスについて詳しく説明します。 、検索などがありますが、実際の進化のプロセスでは、より多くのトラフィックをサポートするために、ハードウェア構成、ネットワーク環境のアップグレード、オペレーティング システムの変更、CDN ミラーリングなども使用されます。実際の開発プロセスでは、大規模な Web サイトでは、上記のことだけでなく、セキュリティ、運用と保守、運用、サービス、ストレージなども行う必要があります。この記事を書くのは実際には簡単ではありません。これは、大規模な Web サイト アーキテクチャの進化に関するさらなる紹介につながる可能性があります。:)追記: 最後に、LiveJournal アーキテクチャの進化に関する記事をいくつか紹介します:
LiveJournal のバックグラウンド開発から大規模な Web サイトのパフォーマンス最適化手法を検討する
http://blog.zhangjianfeng.com/article/743
またここから: http://www.danga.com/words/現在の LiveJournal Web サイトのアーキテクチャに関する詳細情報を見つけることができます。

ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

AI Hentai Generator
AIヘンタイを無料で生成します。

人気の記事

ホットツール

メモ帳++7.3.1
使いやすく無料のコードエディター

SublimeText3 中国語版
中国語版、とても使いやすい

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

ドリームウィーバー CS6
ビジュアル Web 開発ツール

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

ホットトピック











1. 今すぐ Toutiao の記事を公開してどうやってお金を稼ぐことができますか?今すぐ Toutiao で記事を公開して収入を増やす方法! 1. 基本的な権利と利益の有効化: オリジナルの記事は広告によって利益を得ることができますが、利益を得るにはビデオが横画面モードでオリジナルである必要があります。 2. ファン100人の権利を有効化:ファン数が100人以上に達すると、マイクロヘッドライン、オリジナルQ&A作成、Q&Aから利益を得ることができます。 3. オリジナル作品にこだわる: オリジナル作品には記事、小見出し、質問などが含まれ、300 ワード以上であることが求められます。違法に盗用された作品をオリジナル作品として出版した場合、クレジットポイントが減点され、利益も差し引かれますのでご注意ください。 4. 垂直性:専門分野の記事を書く場合、分野を超えて自由に記事を書くことができず、適切な推薦が得られず、専門性や洗練度が得られず、ファンもつきにくいそして読者たち。 5. 活動: 高活動、

SpringDataJPA は JPA アーキテクチャに基づいており、マッピング、ORM、トランザクション管理を通じてデータベースと対話します。そのリポジトリは CRUD 操作を提供し、派生クエリによりデータベース アクセスが簡素化されます。さらに、遅延読み込みを使用して必要な場合にのみデータを取得するため、パフォーマンスが向上します。

論文のアドレス: https://arxiv.org/abs/2307.09283 コードのアドレス: https://github.com/THU-MIG/RepViTRepViT は、モバイル ViT アーキテクチャで優れたパフォーマンスを発揮し、大きな利点を示します。次に、この研究の貢献を検討します。記事では、主にモデルがグローバル表現を学習できるようにするマルチヘッド セルフ アテンション モジュール (MSHA) のおかげで、軽量 ViT は一般的に視覚タスクにおいて軽量 CNN よりも優れたパフォーマンスを発揮すると述べられています。ただし、軽量 ViT と軽量 CNN のアーキテクチャの違いは十分に研究されていません。この研究では、著者らは軽量の ViT を効果的なシステムに統合しました。

Go フレームワーク アーキテクチャの学習曲線は、Go 言語とバックエンド開発への慣れ、選択したフレームワークの複雑さ、つまり Go 言語の基本の十分な理解によって決まります。バックエンドの開発経験があると役立ちます。フレームワークの複雑さが異なると、学習曲線も異なります。

Hua Yishan Heart Moon では、Lu Shu は SSR の有名人です。彼は単一ターゲットのバックライン プレイヤーとして配置されており、非常に優れたクリティカル ヒット率を持っています。多くのプレイヤーは Lu Shu についてあまり知りません。私があなたに持ってきたものは次のとおりです。 . 華宜山心月陸朔のスキルと属性の紹介をご覧ください。有名人の属性 有名人のスキル 1. Lu Ming Shuzhong スキルの説明: Lu Ming Shuzhong スキルの説明: Lu Shu はShuzhong の Qiongqihui で生まれ、子供の頃から武術を練習しており、優れた武術のスキルを持っています。敵の後列攻撃力の100%に等しい基本攻撃ダメージを与え、対象の怒りを10ポイント減少させる。スキル属性: レベル 2: 基本攻撃ダメージが 105% に増加します。レベル 2: 基本攻撃のダメージが 110% に増加し、ターゲットの怒りが 15 ポイント減少します。レベル 2: 基本攻撃ダメージが 115% に増加しました。レベル 2: 基本攻撃のダメージが 120% に増加し、ターゲットの怒りが 20 ポイント減少します。レベル2:基本攻撃

PyCharm は、開発効率を大幅に向上させる豊富な機能とツールを備えた強力な Python 統合開発環境です。その中でも置換機能は開発プロセスで頻繁に使用される機能の 1 つであり、開発者がコードを迅速に修正し、コードの品質を向上させるのに役立ちます。この記事では、初心者がこの関数をよりよく習得して使用できるように、特定のコード例と組み合わせて PyCharm の置換関数を詳細に紹介します。置換関数の概要 PyCharm の置換関数は、開発者がコード内の指定されたテキストを迅速に置換するのに役立ちます

2024 年は AI 携帯電話元年です。AI スマート テクノロジーにより、携帯電話はますます効率的かつ便利に使用できるようになります。最近、今年の初めにリリースされたGalaxy S24シリーズは、生成AIエクスペリエンスを再び改善しました。以下で詳細な機能の紹介を見てみましょう。 1. 生成 AI は Samsung Galaxy S24 シリーズを強力に強化します。Galaxy S24 シリーズは、Galaxy AI によって強化され、多くのインテリジェント アプリケーションをもたらします。これらの機能は Samsung One UI6.1 と緊密に統合されており、ユーザーはいつでも便利なインテリジェントなエクスペリエンスを得ることができ、パフォーマンスが大幅に向上します。携帯電話の効率と使いやすさ。 Galaxy S24 シリーズで先駆けて開発されたサークルアンド検索機能は、長押しするだけで実現できる機能です。

1. Llama3 のアーキテクチャ このシリーズの記事では、llama3 を最初から実装します。 Llama3 の全体的なアーキテクチャ: Llama3 のモデル パラメーターをイメージします: Llama3 モデルのこれらのパラメーターの実際の値を見てみましょう。図[1] コンテキストウィンドウ (context-window) LlaMa クラスをインスタンス化する際、変数 max_seq_len によって context-window が定義されます。クラスには他にもパラメータがありますが、このパラメータは変圧器モデルに最も直接関係しています。ここでの max_seq_len は 8K です。図[2] 語彙サイズと注意力L
