這里的大型網(wǎng)站架構(gòu)僅包括高度交互且高度交互的數(shù)據(jù)類型網(wǎng)站。出于眾所周知的原因，我們不會談?wù)撔侣勵惡鸵恍┛梢砸蕾嘓TML靜態(tài)實現(xiàn)的體系結(jié)構(gòu)。我們使用高負載和高數(shù)據(jù)。以高數(shù)據(jù)移動性交換網(wǎng)站為例

例如，海南，開心網(wǎng)等類似web2.0系列架構(gòu)。我們不在這里討論PHP或JSP或.NET環(huán)境。我們從架構(gòu)方面來看問題。實現(xiàn)語言不是問題。語言的優(yōu)點是實現(xiàn)而不是好或壞。無論您選擇哪種語言，都必須實施架構(gòu)。面對。

在這里，我們討論大型網(wǎng)站需要考慮和考慮的問題

1.處理海量數(shù)據(jù)

眾所周知，對于一些相對較小的站點，數(shù)據(jù)量不是很大，選擇和更新可以解決我們面臨的問題，負載不是很大，最多可以做幾個索引。對于大的網(wǎng)站，每天的數(shù)據(jù)量可能是數(shù)百萬。如果存在設(shè)計糟糕的多對多關(guān)系，則在早期階段沒有問題，但隨著用戶的增長，數(shù)據(jù)量將以幾何方式增長。此時，我們選擇和更新表的成本非常高（更不用說多表聯(lián)合查詢）。

2，數(shù)據(jù)并發(fā)處理

在某些時候，2.0的CTO有一把劍，它是一個緩存。對于緩存，當(dāng)高并發(fā)性很高時，這也是一個大問題。在整個應(yīng)用程序下，緩存是全局共享的，但是當(dāng)我們進行更改時，如果兩個或多個請求同時對緩存進行更新，則應(yīng)用程序?qū)⒅苯铀劳?。這時，您需要一個良好的數(shù)據(jù)并發(fā)處理策略和緩存策略。

另外，它是數(shù)據(jù)庫的死鎖問題。也許我們感覺不到。在高并發(fā)性的情況下出現(xiàn)死鎖的概率非常高。磁盤緩存是一個大問題。

3.文件存儲問題

對于一些支持文件上傳2.0的站點，我們應(yīng)該更關(guān)注如何在硬盤容量增長時有效地存儲和索引文件。常見的解決方案是按日期和類型存儲文件。但是當(dāng)文件數(shù)量是海量數(shù)據(jù)時，如果硬盤存儲500G的普通文件，那么磁盤Io在維護和使用過程中是一個很大的問題，即使你的帶寬足夠，但你的磁盤不一定會響應(yīng)。如果此時間涉及上傳，則磁盤很容易結(jié)束。

也許使用raid和專用存儲服務(wù)器可以解決目前的問題，但是到處都存在訪問問題。也許我們的服務(wù)器在沈陽，如何解決云南或新疆的訪問速度？如果是分布式的，那么我們就是文件索引以及如何規(guī)劃架構(gòu)。

所以我們不得不承認文件存儲是一個非常困難的問題

4.數(shù)據(jù)關(guān)系的處理

我們可以輕松地規(guī)劃符合第三范式的數(shù)據(jù)庫，該范例包含多對多關(guān)系，并且可以用GUID替換INDENTIFY COLUMN。然而，2.0時代充滿了多對多的關(guān)系。第三種范式是第一種范式。應(yīng)該放棄。必須有效地最小化多表聯(lián)合查詢。

5，數(shù)據(jù)索引的問題

眾所周知，索引是提高數(shù)據(jù)庫效率查詢的最便宜和最簡單的方法。但是，在UPDATE很高的情況下，更新和刪除的成本會很高，我無法想到它。我遇到了一個在更新聚焦索引時需要10分鐘才能完成的情況。所以對于網(wǎng)站來說，這些基礎(chǔ)知識是無法忍受的。

索引和更新是一對自然的。問題A，D和E是我們在進行架構(gòu)時必須考慮的問題，它們可能是花費最多時間的問題。

6，分布式處理

對于2.0網(wǎng)站由于其高交互性，CDN實現(xiàn)的效果基本上為0，內(nèi)容實時更新，我們經(jīng)常處理。為了確保每個地方的訪問速度，我們需要面對一個大問題，即如何有效地實現(xiàn)數(shù)據(jù)同步和更新，各地服務(wù)器的實時通信都存在必須考慮的問題。

7.分析Ajax的優(yōu)缺點

程也AJAX，擊敗了AJAX，AJAX成了主流趨勢，突然發(fā)現(xiàn)基于XML的帖子和獲取是如此簡單?？蛻舳双@取或發(fā)布到服務(wù)器數(shù)據(jù)，服務(wù)器在收到數(shù)據(jù)請求后返回。這是一個普通的AJAX請求。但是在AJAX處理中，如果我們使用數(shù)據(jù)包捕獲工具，數(shù)據(jù)返回和處理一目了然。對于一些計算密集型的AJAX請求，我們可以構(gòu)造一個發(fā)夾，可以輕松殺死網(wǎng)絡(luò)服務(wù)器。

8.數(shù)據(jù)安全性分析

對于HTTP協(xié)議，數(shù)據(jù)包以純文本形式傳輸。也許我們可以說我們可以使用加密，但對于G問題，加密過程可能是純文本（例如，我們知道QQ很容易。判斷他的加密并有效地編寫像他這樣的加密和解密方法）。當(dāng)您的網(wǎng)站流量不是很大時，沒有人關(guān)心您，但是當(dāng)您的流量出現(xiàn)時，所謂的插件，所謂的群發(fā)郵件將陸續(xù)出現(xiàn)（從qq群組可見性開始）。也許我們可以非常說我們可以使用更高級別的判斷甚至HTTPS來實現(xiàn)，注意，當(dāng)你做這些處理時會付出巨大的數(shù)據(jù)庫，io和CPU成本。對于一些團體頭發(fā)，它基本上是不可能的。作者已經(jīng)能夠?qū)崿F(xiàn)百度空間和qq空間的大規(guī)模分發(fā)。每個人都愿意嘗試，這并不是很難。

9.數(shù)據(jù)同步和集群處理的問題

當(dāng)我們的某個數(shù)據(jù)庫服務(wù)器不堪重負時，我們需要在此時執(zhí)行基于數(shù)據(jù)庫的工作負載和集群。這個時間可能是最棘手的問題。數(shù)據(jù)基于網(wǎng)絡(luò)傳輸。根據(jù)數(shù)據(jù)庫的設(shè)計，數(shù)據(jù)延遲是一個可怕的問題，也是一個不可避免的問題。在這種情況下，我們需要使用另一種方法。確保在此延遲的幾秒鐘內(nèi)或更長時間內(nèi)實現(xiàn)有效的交互。如數(shù)據(jù)散列，分割，內(nèi)容處理等。

10.數(shù)據(jù)共享渠道和OPENAPI趨勢

Openapi已成為一種必然趨勢，從谷歌，臉書，臉譜到學(xué)校，正在考慮這個問題，它可以更有效地留住用戶，激發(fā)用戶的興趣，讓更多的人幫助你做最有效的發(fā)展。這時，一個有效的數(shù)據(jù)共享平臺，數(shù)據(jù)開放平臺已經(jīng)成為不可或缺的方式，并且在開放接口的情況下確保數(shù)據(jù)的安全性和性能，這是一個我們必須認真考慮的問題。