ここでは、PHP、JSP、または.NET環境であるかどうかについては説明しません。建築の観点から問題を見ていきます。言語の実装は問題ではありません。言語の利点は、良いか悪いかではなく、実装にあります。どんな言語を選んでも、アーキテクチャは直面しなければなりません。
1。大規模なデータの処理
誰もが知っているように、一部の比較的小さなサイトでは、データの量はそれほど大きくありません。選択と更新は、直面する問題を解決できます。負荷自体はそれほど大きくなく、せいぜいいくつかのインデックスを実行できます。大規模なWebサイトの場合、1日あたりのデータの量は数百万になる場合があります。不十分に設計されていない多くの関係が初期段階では問題にならないが、ユーザーが成長するにつれて、データの量は幾何学的に増加します。この時点で、テーブルを選択して更新すると（複数のテーブルのジョイントクエリは言うまでもありません）、コストは非常に高くなります。
2。データの並行処理
ある時点で、2.0 CTOにはシャンファンの剣があります。これはキャッシュです。キャッシュの場合、高い並行性と高い処理が実行される場合にも大きな問題です。アプリケーション全体で、キャッシュはグローバルに共有されます。ただし、変更を行うと、2つ以上のリクエストが同時にキャッシュの更新が必要な場合、アプリケーションは直接死亡します。現時点では、優れたデータの並行性処理戦略とキャッシュ戦略が必要です。
さらに、データベースのデッドロックの問題です。たぶん、私たちは通常、並行性でデッドロックが発生する可能性が非常に高いと感じていないため、ディスクキャッシュが大きな問題であると感じていません。
3.ファイルストレージの問題
ファイルをサポートする一部のサイトでは、2.0をアップロードするサイトの場合、ハードディスク容量が大きくなり、より大きくなっていることが幸運な場合、ファイルを効果的に保存およびインデックス作成する方法をさらに検討する必要があります。一般的な解決策は、日付とタイプごとにファイルを保存することです。ただし、ファイルのボリュームが大きい場合、ハードディスクが500 gの些細なファイルを保存する場合、ディスクのIOはメンテナンスと使用中に大きな問題です。帯域幅が十分であっても、ディスクが応答しない場合があります。この時点でアップロードが関係している場合、ディスクは簡単に終了します。
おそらく、RAIDと専用のストレージサーバーを使用すると、現在の問題を解決できますが、さまざまな場所でのアクセスの問題である別の問題があります。たぶん私たちのサーバーは北京にあり、多分雲南省またはXintengのアクセス速度にあるのでしょうか？配布されている場合、ファイルインデックスとアーキテクチャをどのように計画する必要がありますか。
ですから、ファイルストレージは非常に難しい問題であることを認めなければなりません
4。データ関係の処理
多くの関係に満ちた3番目の正常に準拠したデータベースを簡単に計画できます。しかし、多くの多くの関係が浸水している2.0時代では、3番目の正常は放棄されるべき最初のものです。マルチテーブルのジョイントクエリは、効果的に最小化する必要があります。
5。データインデックスの問題
誰もが知っているように、インデックス作成は、データベースの効率クエリを改善するための最も安価で簡単なソリューションです。ただし、高い更新の場合、更新と削除のコストは高く、考えられません。著者は、フォーカスインデックスを更新するときに完了するのに10分かかる状況に遭遇したため、サイトの場合、これらは基本的に耐えられません。
インデックスと更新は、自然の敵のペアです。質問A、D、およびEは、アーキテクチャを行う際に考慮しなければならない問題であり、時間がかかる問題でもあります。
6。分散処理
2.0のWebサイトの場合、相互作用が高いため、CDNによって達成される効果は基本的に0であり、コンテンツはリアルタイムで更新されます。これは通常の処理です。さまざまな場所でのアクセス速度を確保するには、大きな問題に直面する必要があります。つまり、さまざまな場所でのサーバーのリアルタイム通信を効果的に実現し、更新および実現する方法は考慮する必要があります。
7。Ajaxの長所と短所の分析
成功はajaxであり、失敗はajaxであり、Ajaxは主流のトレンドになりました、そして、私は突然、Xmlhttpに基づいてポストと取得が非常に簡単であることがわかりました。クライアントはデータをサーバーに取得または投稿し、データリクエストを受信した後にサーバーが返されます。これは非常に通常のAJAXリクエストです。ただし、AJAXを処理する場合、パケットキャプチャツールを使用する場合、データの返品と処理は一目で明らかになります。計算量が多いいくつかのAJAX要求の場合、請負業者を構築することができます。これは、Webサーバーを簡単に殺すことができます。
8。データセキュリティの分析
HTTPプロトコルの場合、データパケットはプレーンテキストで送信されます。暗号化を使用できると言えるかもしれませんが、Gの問題では、暗号化プロセスは平易なテキストである可能性があります（たとえば、暗号化を簡単に判断し、暗号化と復号化方法を効果的に記述できることがわかっています）。サイトのトラフィックがそれほど大きくない場合、誰もあなたのことを気にしませんが、トラフィックが発生すると、いわゆるプラグインといわゆる質量送信が次々に続きます（QQの開始時の質量から手がかりが見られます）。おそらく、これを達成するために高レベルの判断やHTTPを使用できると非常に言えるでしょう。これらの処理を行うと、多くのデータベース、IO、CPUコストを支払うことに注意してください。一部の大規模な放送では、基本的に不可能です。著者は、バイドゥスペースとQQスペースの大規模な出版をすでに実現できます。誰もがそれを試すことは難しくありません。
9。データの同期とクラスター処理の問題
データベースアーバーの1つが圧倒された場合、データベースベースのロードとクラスターを実行する必要があります。これは最も厄介な問題かもしれません。データはネットワーク伝送に基づいています。データ遅延はひどい問題であり、避けられない問題です。このようにして、他の手段を使用して、この遅延の数秒以上以内に効果的な相互作用を確保する必要があります。たとえば、データハッシュ、セグメンテーション、コンテンツ処理、その他の問題。
10。データ共有チャネルとOpenapiの傾向
Openapiは、Google、Facebook、Myspaceから自宅のキャンパスまで、避けられない傾向になりました。この問題は考慮されています。より効果的にユーザーを維持し、より多くの関心を刺激し、より多くの人々があなたが最も効果的な開発を行うのを助けることができます。現時点では、効果的なデータ共有プラットフォームの場合、データオープンプラットフォームは不可欠な方法になります。オープンインターフェイスでデータセキュリティとパフォーマンスを確保することは、真剣に考慮する必要がある別の問題です。