大規模Webサイトのアーキテクチャ設計・制作時に考慮すべき10の課題_HTML/Xhtml_Webページ制作

ここでは PHP、JSP、または .NET 環境について話しているのではなく、実装言語は品質ではなく実装に問題があるのです。どの言語を選択するとしても、アーキテクチャには直面する必要があります。

1. 大量データの処理

ご存知のとおり、一部の比較的小規模なサイトでは、データの量はそれほど多くなく、負荷自体はそれほど大きくなく、いくつか追加することで解決できます。せいぜいインデックスくらい。大規模な Web サイトの場合、多対多の関係が適切に設計されていれば、毎日のデータ量は数百万単位になることがあります。ただし、ユーザー数が増加するにつれて、その量は増加します。データは幾何級数的に増加します。現時点では、テーブルの選択と更新 (複数のテーブルの共同クエリは言うまでもなく) のコストが非常に高くなります。

2. データ同時処理

2.0 の CTO は、キャッシュを行うシャンファンの剣を持っている場合があります。同時実行性が高く、処理量が多い場合、キャッシュも大きな問題になります。キャッシュはアプリケーション全体でグローバルに共有されますが、変更を行うときに、2 つ以上のリクエストが同時にキャッシュの更新を要求すると、アプリケーションは直接停止します。現時点では、適切なデータ同時処理戦略とキャッシュ戦略が必要です。

さらに、データベースにはデッドロックの問題があります。通常は感じられないかもしれませんが、同時実行性が高い状況ではデッドロックが発生する可能性が非常に高くなります。

3. ファイルストレージの問題

ファイルのアップロードをサポートする一部の 2.0 サイトでは、幸いにもハードディスクの容量がますます大きくなっているため、ファイルの保存方法と効果的なインデックス作成方法についてさらに検討する必要があります。一般的な解決策は、ファイルを日付と種類別に保存することです。しかし、ファイルボリュームが大規模なデータの場合、ハードディスクに 500 G の些細なファイルが保存されている場合、帯域幅が十分であっても、ディスクの IO がメンテナンスや使用中に大きな問題になります。この時にアップロードも絡むと簡単にディスクオーバーになってしまいます。

RAID と専用ストレージ サーバーを使用することで現在の問題は解決できるかもしれませんが、おそらく、サーバーが北京、雲南、新蔵にある場合、アクセス速度はどのように解決されるでしょうか。式を考えた場合、ファイルのインデックスとアーキテクチャをどのように計画すればよいでしょうか。

したがって、ファイルストレージは非常に難しい問題であることを認めなければなりません

4. データ関係の処理

多対多の関係が満載の 3 番目のパラダイムに準拠したデータベースを簡単に計画でき、GUID を使用して INDENTIFY COLUMN を置き換えることもできます。ただし、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 のトレンド

Google、Facebook、Myspace から国内の学校に至るまで、Openapi は、ユーザーをより効果的に維持し、より多くの人々を惹きつけるために、この問題を検討しています。発達。現時点では、効果的なデータ共有プラットフォームとデータオープンプラットフォームが不可欠になっており、オープンインターフェイスの場合のデータセキュリティとパフォーマンスの確保も真剣に検討する必要があります。