《從上百幅架構(gòu)圖中學(xué)大型網(wǎng)站建設(shè)經(jīng)驗（上）》文章地址：http://www.tfxk.com/zixun/04213BU2013.htm
5、Google App Engine技術(shù)架構(gòu)

    然而，只管業(yè)務(wù)之間已經(jīng)足夠獨立了，但是有些業(yè)務(wù)之間或多或少總會有點接洽，如用戶，基礎(chǔ)上都會和每個業(yè)務(wù)相關(guān)系，況且這種分區(qū)方式，也不能解決單張表數(shù)據(jù)量暴漲的問題，因而為何不嘗嘗水平sharding呢？

    近段時間以來，通過接觸有關(guān)海量數(shù)據(jù)處理和搜索引擎的諸多技術(shù)，經(jīng)常見識到不少精妙絕倫的架構(gòu)圖。除了每每感慨于每幅圖名義上的繪制的精致之外，更為架構(gòu) 圖當面所暗藏的設(shè)計思維所嘆服。個人這兩天始終在收集各大型網(wǎng)站的架構(gòu)設(shè)計圖，一為了一飽眼福，領(lǐng)略各類大型網(wǎng)站架構(gòu)設(shè)計的精彩之外，二來也可供閑時重復(fù) 揣摩領(lǐng)會，何樂而不為呢?特此，總結(jié)整理了諸如國外wikipedia，F(xiàn)acebook，Yahoo！，YouTube，MySpace，Twitter，海內(nèi)如優(yōu)酷網(wǎng)等大型網(wǎng)站的技術(shù)架構(gòu)（本文重點剖析優(yōu)酷網(wǎng)的技術(shù)架構(gòu)），以饗讀者。

6、Amazon技術(shù)架構(gòu)

    Amazon的云架構(gòu)圖如下：

                                               Yahoo! Mail 架構(gòu)

寫入無奈擴展 寫入無法緩存 復(fù)制延時 鎖榜樣回升 表變大，緩存率降落

    對于緩存系統(tǒng)，還能夠看看下幅圖：

    緩存在大型web名目中起到了舉足輕重的作用，究竟數(shù)據(jù)越湊近CPU存取速度越快。下圖是twitter的緩存架構(gòu)圖：

    Yahoo! Mail 架構(gòu)安排了 Oracle RAC，用來存儲 Mail 服務(wù)相干的 Meta 數(shù)據(jù)。

2、Facebook 架構(gòu) 防止內(nèi)存拷貝，避免內(nèi)存鎖 如接到老大哥告訴要把某個視頻撤下來，假如在緩存里是比擬麻煩的

其主從復(fù)制的進程如下圖所示：

                                    Amazon的Dynamo Key-Value存儲架構(gòu)圖

    如果把業(yè)務(wù)切割得足夠獨破，那把不同業(yè)務(wù)的數(shù)據(jù)放到不同的數(shù)據(jù)庫服務(wù)器將是一個不錯的方案，而且萬一其中一個業(yè)務(wù)瓦解了也不會影響其他業(yè)務(wù)的畸形進行，并且也起到了負載分流的作用，大大晉升了數(shù)據(jù)庫的吞吐才能。經(jīng)由垂直分區(qū)后的數(shù)據(jù)庫架構(gòu)圖如下：

貌似大的系統(tǒng)都對“緩存”情有獨鐘，從http緩存到memcached內(nèi)存數(shù)據(jù)緩存，但優(yōu)酷表現(xiàn)不用內(nèi)存緩存，理由如下：

    此篇文章終于寫完了，從昨日有收拾此文的念頭后，到本日上午找電腦上網(wǎng)而不得，再到此刻在網(wǎng)吧實現(xiàn)此文。著實也體味了一把什么叫做為技巧狂熱的感到。大型 網(wǎng)站架構(gòu)是一個實戰(zhàn)性很強的貨色，而你我或者當初臨時還只是一個在外看熱烈的門外漢罷了。不外，不要緊，小魚小蝦照樣能暢游汪汪大洋，更何況日后亦能成長 為大魚大鯊。

 緩存策略

                                       ,網(wǎng)站設(shè)計;      WikiPedia 技術(shù)架構(gòu)圖Copy @Mark Bergsma

7、優(yōu)酷網(wǎng)的技術(shù)架構(gòu)

然而，主從復(fù)制也帶來其余一系列機能瓶頸問題：

    twitter平臺大抵由twitter.com、手機以中舉三方利用形成，如下圖所示（其中流量主要以手機和第三方為重要起源）：

。

    下圖是分布式存儲系統(tǒng)的示用意，讀者可觀摩之：

    可能有讀者并不熟習Amazon，它現(xiàn)在已經(jīng)是全球商品種類最多的網(wǎng)上零售商和寰球第2大互聯(lián)網(wǎng)公司。而之前它僅僅是一個小小的網(wǎng)上書店。ok，下面，咱們來見識下它的架構(gòu)。

簡單的MySQL主從復(fù)制。
MySQL的主從復(fù)制解決了數(shù)據(jù)庫的讀寫分別，并很好的提升了讀的性能，其本來圖如下：

    ok，歡迎關(guān)注從上百幅架構(gòu)圖中學(xué)得半點大型網(wǎng)站建設(shè)經(jīng)驗（下）。有任何問題或過錯，歡迎不吝教正。謝謝大家。本文完。

 MySQL垂直分區(qū)

    優(yōu)酷的數(shù)據(jù)庫架構(gòu)也是閱歷了很多曲折，從一開端的單臺MySQL服務(wù)器（Just Running）到簡單的MySQL主從復(fù)制、SSD優(yōu)化、垂直分庫、水平sharding分庫。

4、twitter技術(shù)架構(gòu)

    本文側(cè)重凸顯每一幅圖的出色之處與其背地含意，而圖的闡明性文字則從簡從略。ok，好好享受此番架構(gòu)盛宴吧。當然，若有任何倡議或問題，歡送不吝斧正。謝謝。

Datastore是基于BigTable技術(shù)的分布式數(shù)據(jù)庫，固然其也可以被懂得成為一個服務(wù)，但是因為其是整個App Engine獨一存儲長久化數(shù)據(jù)的處所，所以其是App Engine中一個異常中心的模塊。其詳細細節(jié)將在下篇和大家探討。

                                            GAE的架構(gòu)圖

                                           Amazon的云架構(gòu)圖

    這樣，就根據(jù)module、method及params來確定調(diào)用絕對獨立的模塊，顯得非常簡練。下圖是優(yōu)酷的前端部分架構(gòu)圖：

    Dynamo對Consistent Hashing算法的改良在于：它放在環(huán)上作為一個node的是一組機器（而不是memcached把一臺機器作為node），這一組機器是通過同步機制保障數(shù)據(jù)一致的。

后記

                          ,成都網(wǎng)頁設(shè)計公司;          Facebook 搜索功效的架構(gòu)示意圖

而且Squid 的 write() 用戶過程空間有耗費，Lighttpd 1.5 的 AIO(異步I/O) 讀取文件到用戶內(nèi)存導(dǎo)致效力也比較低下。

來自wikipedia的數(shù)據(jù)：峰值每秒鐘3萬個 HTTP 懇求 每秒鐘 3Gbit 流量, 近乎375MB 350 臺 PC 服務(wù)器。 GeoDNSA ：40-line patch for BIND to add geographical filters support to the existent views in BIND", 把用戶帶到最近的服務(wù)器。GeoDNS 在 WikiPedia 架構(gòu)中擔負重擔當然是由 WikiPedia 的內(nèi)容性質(zhì)決議的--面向各個國度，各個地區(qū)。 負載平衡：LVS，請看下圖：  從上百幅架構(gòu)圖中學(xué)大型網(wǎng)站建設(shè)教訓(xùn)（上） 引言

    Dynamo是亞馬遜的key-value模式的存儲平臺，可用性跟擴大性都很好，性能也不錯：讀寫拜訪中99.9%的響應(yīng)時光都在300ms內(nèi)。按散布 式體系常用的哈希算法切分數(shù)據(jù)，分放在不同的node上。Read操作時，也是依據(jù)key的哈希值尋找對應(yīng)的node。Dynamo應(yīng)用了 Consistent Hashing算法，node對應(yīng)的不再是一個斷定的hash值，而是一個hash值范疇，key的hash值落在這個規(guī)模內(nèi)，則順時針沿ring找，碰 到的第一個node即為所需。

 MySQL程度分片（Sharding）

  如何來肯定某個用戶所在的shard呢，可以建一張用戶和shard對應(yīng)的數(shù)據(jù)表，每次要求先從這張表找用戶的shard id，再從對應(yīng)shard中查詢相關(guān)數(shù)據(jù)，如下圖所示：    但是，優(yōu)酷是如何解決跨shard的查詢呢，這個是個難點，據(jù)先容優(yōu)酷是盡量不跨shard查問，切實不行通過多維分片索引、分布式搜尋引擎，下策是分布式數(shù)據(jù)庫查詢（這個無比麻煩而且耗性能）。

    仔細的讀者一定能發(fā)明，上副架構(gòu)圖之前呈現(xiàn)在此文之中：從多少幅架構(gòu)圖中偷得半點海里數(shù)據(jù)處置經(jīng)驗。本文與前文最大的不同是，前文只有幾幅，此文系列將有上百幅架構(gòu)圖，任你縱情欣賞。

前端包含4個模塊：Front End，Static Files，App Server，App Master。

全部服務(wù)群包括良多服務(wù)供App Server調(diào)用，比方Memcache，圖形，用戶，URL抓取和義務(wù)隊列等。

    這是一個十分好的思路，將用戶按必定規(guī)矩（按id哈希）分組，并把該組用戶的數(shù)據(jù)存儲到一個數(shù)據(jù)庫分片中，即一個sharding，這樣跟著用戶數(shù)目的增添，只有簡略地配置一臺服務(wù)器即可，原理圖如下：

                                                     twitter的整體架構(gòu)設(shè)計圖

那問題發(fā)生總得解決的，這就產(chǎn)生下面的優(yōu)化計劃。

    從一開始，優(yōu)酷網(wǎng)就自建了一套CMS來解決前端的頁面顯示，各個模塊之間分離得比較適當，前端可擴展性很好，UI的分離，閃開發(fā)與保護變得非常簡單和機動，下圖是優(yōu)酷前真?zhèn)�模塊調(diào)用關(guān)聯(lián)：

1、WikiPedia 技術(shù)架構(gòu)

  ,成都網(wǎng)站設(shè)計;  簡單而言，上述GAE的架構(gòu)分為如圖所示的三個局部：前端，Datastore和服務(wù)群。

    附注：1、此段優(yōu)酷網(wǎng)的技術(shù)架構(gòu)整頓于此處：

3、Yahoo! Mail 架構(gòu)

但 為何咱們訪問優(yōu)酷會如斯流利，與土豆比擬優(yōu)酷的視頻加載速度稍遜一籌？這個要歸功于優(yōu)酷樹立的比較完美的內(nèi)容散發(fā)網(wǎng)絡(luò)（CDN），它通過多種方法保證分布 在全國各地的用戶進行就近訪問——用戶點擊視頻請求后，優(yōu)酷網(wǎng)將根據(jù)用戶所處地域地位，將離用戶最近、服務(wù)狀態(tài)最好的視頻服務(wù)器地址傳遞給用戶，從而保證 用戶可以得到疾速的視頻休會。這就是CDN帶來的上風，就近訪問。

(責任編輯：網(wǎng)站建設(shè))
從上百幅架構(gòu)圖中學(xué)大型網(wǎng)站建設(shè)經(jīng)驗（上）相關(guān)文章