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

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

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

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

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

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

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

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

3.文件存儲(chǔ)問題

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

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

所以我們不得不承認(rèn)文件存儲(chǔ)是一個(gè)非常困難的問題

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

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

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

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

索引和更新是一對(duì)自然的。問題A，D和E是我們?cè)谶M(jìn)行架構(gòu)時(shí)必須考慮的問題，它們可能是花費(fèi)最多時(shí)間的問題。

6，分布式處理

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

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

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

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

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

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

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

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

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