ここでの大規模な Web サイトのアーキテクチャには、高インタラクションと高インタラクションのデータベースの大規模 Web サイトのみが含まれます。理由は誰もがよく知っているため、HTML の静的化に依存して実現できるニュースや一部のアーキテクチャについては説明しません。ここでは、例として、国内、Kaixin.com、およびその他の同様の Web2.0 シリーズ アーキテクチャなど、データ モビリティの高い高負荷および高テイク データ交換 Web サイトを使用します。ここでは、PHP、JSP、または .NET 環境について話しているわけではありません。実装言語は、品質ではなく実装に問題があります。言語を選択する場合、アーキテクチャは必須です。
ここでは、大規模なウェブサイトが注意し、考慮する必要がある問題について説明します
1. 大量のデータの処理
ご存知のとおり、一部の比較的小規模なサイトでは、データの量はそれほど多くなく、負荷自体はそれほど大きくなく、いくつかのインデックスを追加することで解決できます。ほとんど。大規模な Web サイトの場合、データ量は毎日数百万単位になることがあります。多対多の関係が適切に設計されていない場合は、初期段階では問題ありませんが、ユーザー数が増加するにつれてその量は増加します。データの量は幾何級数的に増加します。現時点では、テーブルの選択と更新 (複数のテーブルの共同クエリは言うまでもなく) のコストが非常に高くなります。
2. データの同時処理
2.0のCTOがシャンファンソードを持っていて、キャッシュしているケースもあります。同時実行性が高く、処理量が多い場合、キャッシュも大きな問題になります。キャッシュはアプリケーション全体でグローバルに共有されますが、変更を行うときに、2 つ以上のリクエストが同時にキャッシュの更新を要求すると、アプリケーションは直接停止します。現時点では、適切なデータ同時処理戦略とキャッシュ戦略が必要です。
さらに、データベースのデッドロックの問題もあります。おそらく、同時実行性が高い状況ではデッドロックが発生する可能性が非常に高くなります。
3. ファイルストレージの問題
ファイルのアップロードをサポートする一部の 2.0 サイトでは、幸いにもハードディスクの容量がどんどん大きくなっているので、ファイルの保存方法と効率的なインデックス作成方法についてもっと検討する必要があります。一般的な解決策は、ファイルを日付と種類別に保存することです。しかし、ファイルボリュームが大規模なデータの場合、ハードディスクに 500 G の些細なファイルが保存されている場合、帯域幅が十分であっても、ディスクの IO がメンテナンスや使用中に大きな問題になります。この時にアップロードも絡むと簡単にディスクオーバーになってしまいます。
おそらく RAID と専用ストレージサーバーを使用することで現在の問題は解決できますが、おそらくさまざまな場所からのアクセスの問題があり、サーバーが分散されている場合はどうすればよいでしょうか。ファイルインデックスとアーキテクチャを計画する方法。
したがって、ファイルストレージは非常に難しい問題であることを認めなければなりません
4. データ関係の処理
多対多の関係が満載の 3 番目のパラダイムに準拠したデータベースを簡単に計画でき、INDENTIFY COLUMN の代わりに GUID を使用することもできます。しかし、多対多の関係が充実している 2.0 の時代では。人間関係において、最初に放棄すべきパラダイムは 3 番目のパラダイムです。複数テーブルの結合クエリは効果的に最小限に抑える必要があります。
5. データインデックスの問題
ご存知のとおり、インデックス作成はデータベースクエリの効率を向上させる最も安価で簡単な方法です。ただし、UPDATE が高い場合、更新と削除のコストは想像を絶するほど高くなります。筆者は、集中したインデックスの更新が完了するまでに 10 分かかるという状況に遭遇しました。そのため、サイトにとって、これらの基本的な作業は耐えられません。
課題A、D、Eはアーキテクチャをやる上で考慮しなければならない課題であり、最も時間がかかる課題でもあります。
6.分散処理
双方向性の高さから2.0のWebサイトについては、CDNの効果は基本的に0で、コンテンツはリアルタイムに更新され、従来通りに対応しています。様々な場所でのアクセス速度を確保するには、様々な場所にあるサーバー間のデータの同期や更新をいかに効率的に実現するかが大きな課題となります。
7. Ajaxの長所と短所の分析
AJAX が成功し、AJAX が失敗するのが主流になってきましたが、XMLHTTP ベースの post と get がとても簡単であることに突然気づきました。クライアントはデータを取得またはサーバーに送信し、サーバーはデータ要求を受信した後にそれを返します。これは通常の AJAX 要求です。しかし、AJAX 処理中にパケット キャプチャ ツールを使用すると、データの返送と処理が一目瞭然になります。一部の計算負荷の高い AJAX リクエストの場合は、Web サーバーを簡単に強制終了できるパケット送信マシンを構築できます。
8. データセキュリティの分析
HTTP プロトコルの場合、データ パケットは平文で送信されます。おそらく、暗号化を使用できると言えますが、G 問題の場合、暗号化プロセスは平文で行われる可能性があります (たとえば、私たちが知っている QQ など)。その暗号化を判断し、彼と同じ暗号化および復号化メソッドを効果的に記述するのは簡単です。サイトのトラフィックがそれほど大きくないときは、誰もあなたのことなど気にしませんが、トラフィックが増加すると、いわゆるプラグインやいわゆる大量メッセージが次々と現れます (大量メッセージからの手掛かりは、次の URL で確認できます)。 QQの始まり）。おそらく、より高いレベルの判断、さらには HTTPS を使用して実装できると言っても過言ではありません。これらのプロセスを実行すると、膨大なデータベース、IO、CPU コストが発生することに注意してください。一部大量送信の場合は基本的に不可能です。著者は、Baidu スペースと QQ スペースでグループ メッセージングを実現することができました。試してみようと思えば、実際には難しいことではありません。
9. データ同期とクラスター処理の問題
データベース サーバーの 1 つが過剰になった場合、その時点でデータベース ベースの負荷とクラスタリングを行う必要があります。これは現時点で最も問題となる問題であり、データベースの設計によってはデータの遅延が発生するため、他の手段を使用して解決する必要があります。この問題を解決するには、数秒以上の遅延内に効果的な対話が行われるようにしてください。データのハッシュ化、セグメンテーション、コンテンツ処理、その他の問題など。
10. データ共有チャネルとOPENAPIのトレンド
Openapi は、Google、Facebook、Myspace から国内の学校まで、誰もがこの問題を検討しており、より効果的にユーザーを維持し、ユーザーの関心を高め、最も効果的な開発を行うことができます。 。現時点では、効果的なデータ共有プラットフォームとデータオープンプラットフォームが不可欠になっており、オープンインターフェイスの場合のデータセキュリティとパフォーマンスの確保も真剣に検討する必要があります。
。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
