大型WEB網站架構深入分析

大型WEB網站架構深入分析

---本文轉載自網際網路

1、HTML靜態化
其實大家都知道，效率最高、消耗最小的就是純靜態化的html頁面，所以我們儘可能使我們的網站上的頁面採用靜態頁面來實現，這個最簡單的方法其實也是最有效的方法。但是對於大量內容並且頻繁更新的網站，我們無法全部手動去挨個實現，於是出現了我們常見的資訊釋出系統CMS，像我們常訪問的各個門戶站點的新聞頻道，甚至他們的其他頻道，都是通過資訊釋出系統來管理和實現的，資訊釋出系統可以實現最簡單的資訊錄入自動生成靜態頁面，還能具備頻道管理、許可權管理、自動抓取等功能，對於一個大型網站來說，擁有一套高效、可管理的CMS是必不可少的。
除了門戶和資訊釋出型別的網站，對於互動性要求很高的社群型別網站來說，儘可能的靜態化也是提高效能的必要手段，將社群內的帖子、文章進行實時的靜態化，有更新的時候再重新靜態化也是大量使用的策略，像Mop的大雜燴就是使用了這樣的策略，網易社群等也是如此。
同時，html靜態化也是某些快取策略使用的手段，對於系統中頻繁使用資料庫查詢但是內容更新很小的應用，可以考慮使用html靜態化來實現，比如論壇中論壇的公用設定資訊，這些資訊目前的主流論壇都可以進行後臺管理並且儲存再資料庫中，這些資訊其實大量被前臺程式呼叫，但是更新頻率很小，可以考慮將這部分內容進行後臺更新的時候進行靜態化，這樣避免了大量的資料庫訪問請求。
2、圖片伺服器分離
大家知道，對於Web伺服器來說，不管是Apache、IIS還是其他容器，圖片是最消耗資源的，於是我們有必要將圖片與頁面進行分離，這是基本上大型網站都會採用的策略，他們都有獨立的圖片伺服器，甚至很多臺圖片伺服器。這樣的架構可以降低提供頁面訪問請求的伺服器系統壓力，並且可以保證系統不會因為圖片問題而崩潰，在應用伺服器和圖片伺服器上，可以進行不同的配置優化，比如apache在配置ContentType的時候可以儘量少支援，儘可能少的LoadModule，保證更高的系統消耗和執行效率。
3、資料庫叢集和庫表雜湊
大型網站都有複雜的應用，這些應用必須使用資料庫，那麼在面對大量訪問的時候，資料庫的瓶頸很快就能顯現出來，這時一臺資料庫將很快無法滿足應用，於是我們需要使用資料庫叢集或者庫表雜湊。
在資料庫叢集方面，很多資料庫都有自己的解決方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是類似的方案，您使用了什麼樣的DB，就參考相應的解決方案來實施即可。
上面提到的資料庫叢集由於在架構、成本、擴張性方面都會受到所採用DB型別的限制，於是我們需要從應用程式的角度來考慮改善系統架構，庫表雜湊是常用並且最有效的解決方案。我們在應用程式中安裝業務和應用或者功能模組將資料庫進行分離，不同的模組對應不同的資料庫或者表，再按照一定的策略對某個頁面或者功能進行更小的資料庫雜湊，比如使用者表，按照使用者ID進行表雜湊，這樣就能夠低成本的提升系統的效能並且有很好的擴充套件性。sohu的論壇就是採用了這樣的架構，將論壇的使用者、設定、帖子等資訊進行資料庫分離，然後對帖子、使用者按照板塊和ID進行雜湊資料庫和表，最終可以在配置檔案中進行簡單的配置便能讓系統隨時增加一臺低成本的資料庫進來補充系統效能。
4、快取
快取一詞搞技術的都接觸過，很多地方用到快取。網站架構和網站開發中的快取也是非常重要。這裡先講述最基本的兩種快取。高階和分散式的快取在後面講述。
架構方面的快取，對Apache比較熟悉的人都能知道Apache提供了自己的快取模組，也可以使用外加的Squid模組進行快取，這兩種方式均可以有效的提高Apache的訪問響應能力。
網站程式開發方面的快取，Linux上提供的Memory Cache是常用的快取介面，可以在web開發中使用，比如用Java開發的時候就可以呼叫MemoryCache對一些資料進行快取和通訊共享，一些大型社群使用了這樣的架構。另外，在使用web語言開發的時候，各種語言基本都有自己的快取模組和方法，PHP有Pear的Cache模組，Java就更多了，.net不是很熟悉，相信也肯定有。
5、映象
映象是大型網站常採用的提高效能和資料安全性的方式，映象的技術可以解決不同網路接入商和地域帶來的使用者訪問速度差異，比如ChinaNet和EduNet之間的差異就促使了很多網站在教育網內搭建映象站點，資料進行定時更新或者實時更新。在映象的細節技術方面，這裡不闡述太深，有很多專業的現成的解決架構和產品可選。也有廉價的通過軟體實現的思路，比如Linux上的rsync等工具。
6、負載均衡
負載均衡將是大型網站解決高負荷訪問和大量併發請求採用的終極解決辦法。
負載均衡技術發展了多年，有很多專業的服務提供商和產品可以選擇，我個人接觸過一些解決方法，其中有兩個架構可以給大家做參考。
7、硬體四層交換
第四層交換使用第三層和第四層資訊包的報頭資訊，根據應用區間識別業務流，將整個區間段的業務流分配到合適的應用伺服器進行處理。　第四層交換功能就象是虛 IP，指向物理伺服器。它傳輸的業務服從的協議多種多樣，有HTTP、FTP、NFS、Telnet或其他協議。這些業務在物理伺服器基礎上，需要複雜的載量平衡演算法。在IP世界，業務型別由終端TCP或UDP埠地址來決定，在第四層交換中的應用區間則由源端和終端IP地址、TCP和UDP埠共同決定。
在硬體四層交換產品領域，有一些知名的產品可以選擇，比如Alteon、F5等，這些產品很昂貴，但是物有所值，能夠提供非常優秀的效能和很靈活的管理能力。Yahoo中國當初接近2000臺伺服器使用了三四臺Alteon就搞定了。
8、軟體四層交換
大家知道了硬體四層交換機的原理後，基於OSI模型來實現的軟體四層交換也就應運而生，這樣的解決方案實現的原理一致，不過效能稍差。但是滿足一定量的壓力還是遊刃有餘的，有人說軟體實現方式其實更靈活，處理能力完全看你配置的熟悉能力。
軟體四層交換我們可以使用Linux上常用的LVS來解決，LVS就是Linux Virtual Server，他提供了基於心跳線heartbeat的實時災難應對解決方案，提高系統的魯棒性，同時可供了靈活的虛擬VIP配置和管理功能，可以同時滿足多種應用需求，這對於分散式的系統來說必不可少。
一個典型的使用負載均衡的策略就是，在軟體或者硬體四層交換的基礎上搭建squid叢集，這種思路在很多大型網站包括搜尋引擎上被採用，這樣的架構低成本、高效能還有很強的擴張性，隨時往架構裡面增減節點都非常容易。這樣的架構我準備空了專門詳細整理一下和大家探討。
對於大型網站來說，前面提到的每個方法可能都會被同時使用到，我這裡介紹得比較淺顯，具體實現過程中很多細節還需要大家慢慢熟悉和體會，有時一個很小的squid引數或者apache引數設定，對於系統效能的影響就會很大，希望大家一起討論，達到拋磚引玉之效。

 

 

用squid做web cache server，而apache在squid的後面提供真正的web服務。當然使用這樣的架構必須要保證主頁上大部分都是靜態頁面。這就需要程式設計師的配合將頁面在反饋給客戶端之前將頁面全部轉換成靜態頁面。

基本看出sina和sohu對於頻道等欄目都用了相同的技術，即squid來監聽這些IP的80埠，而真正的web server來監聽另外一個埠。從使用者的感覺上來說不會有任何的區別，而相對於將web server直接和客戶端連在一起的方式，這樣的方式明顯的節省的頻寬和伺服器。使用者訪問的速度感覺也會更快。

 

http://www.dbanotes.net/arch/yupoo_arch.html

頻寬：4000M/S (參考)
伺服器數量：60 臺左右
Web伺服器：Lighttpd, Apache,nginx
應用伺服器：Tomcat
其他：Python, Java, MogileFS、ImageMagick 等

關於 Squid 與 Tomcat

Squid 與 Tomcat 似乎在 Web 2.0 站點的架構中較少看到。我首先是對 Squid 有點疑問，對此阿華的解釋是"目前暫時還沒找到效率比 Squid 高的快取系統，原來命中率的確很差，後來在 Squid 前又裝了層 Lighttpd, 基於 url 做 hash, 同一個圖片始終會到同一臺 squid 去，所以命中率徹底提高了"

對於應用伺服器層的 Tomcat，現在 Yupoo! 技術人員也在逐漸用其他輕量級的東西替代，而 YPWS/YPFS 現在已經用 Python 進行開發了。

名次解釋：

• YPWS--Yupoo Web Server YPWS 是用 Python開發的一個小型 Web 伺服器，提供基本的 Web 服務外，可以增加針對使用者、圖片、外鏈網站顯示的邏輯判斷，可以安裝於任何有空閒資源的伺服器中，遇到效能瓶頸時方便橫向擴充套件。
• YPFS--Yupoo File System 與 YPWS 類似，YPFS 也是基於這個 Web 伺服器上開發的圖片上傳伺服器。

【Updated: 有網友留言質疑 Python 的效率，Yupoo 老大劉平陽在 del.icio.us 上寫到 "YPWS用Python自己寫的，每臺機器每秒可以處理294個請求, 現在壓力幾乎都在10％以下"】

圖片處理層

接下來的 Image Process Server 負責處理使用者上傳的圖片。使用的軟體包也是 ImageMagick，在上次儲存升級的同時，對於銳化的比率也調整過了(我個人感覺，效果的確好了很多)。”Magickd“ 是影像處理的一個遠端介面服務，可以安裝在任何有空閒 CPU資源的機器上，類似 Memcached的服務方式。

我們知道 Flickr 的縮圖功能原來是用 ImageMagick 軟體包的，後來被雅虎收購後出於版權原因而不用了（?）；EXIF 與 IPTC Flicke 是用 Perl 抽取的，我是非常建議 Yupoo! 針對 EXIF 做些文章，這也是潛在產生受益的一個重點。

圖片儲存層

原來 Yupoo! 的儲存採用了磁碟陣列櫃，基於 NFS 方式的，隨著資料量的增大，”Yupoo! 開發部從07年6月份就開始著手研究一套大容量的、能滿足 Yupoo! 今後發展需要的、安全可靠的儲存系統“，看來 Yupoo! 系統比較有信心，也是滿懷期待的，畢竟這要支撐以 TB 計算的海量圖片的儲存和管理。我們知道，一張圖片除了原圖外，還有不同尺寸的，這些圖片統一儲存在 MogileFS 中。

對於其他部分，常見的 Web 2.0 網站必須軟體都能看到，如 MySQL、Memcached 、Lighttpd 等。Yupoo! 一方面採用不少相對比較成熟的開源軟體，一方面也在自行開發定製適合自己的架構元件。這也是一個 Web 2.0 公司所必需要走的一個途徑。

非常感謝一下 Yupoo! 阿華對於技術資訊的分享，技術是共通的。下一個能爆料是哪家?

--EOF--

lighttpd+squid這套快取是放在另外一個機房作為cdn的一個節點使用的，圖中沒描繪清楚，給大家帶來不便了。
squid前端用lighttpd沒用nginx，主要是用了這麼久，沒出啥大問題，所以就沒想其他的了。
URL Hash的擴充套件性的確不好，能做的就是不輕易去增減伺服器，我們目前是5臺伺服器做一組hash.

我們現在用Python寫的Web Server，在效率方面，我可以給個測試資料，根據目前的訪問日誌模擬訪問測試的結果是1臺ypws,平均每秒處理294個請求(載入所有的邏輯判斷)。
在可靠性上，還不沒具體的資料，目前執行1個多月還沒有任何異常。

lvs每個節點上都裝nginx，主要是為了反向代理及處理靜態內容，不過apache已顯得不是那麼必需，準備逐漸去掉。

我們處理圖片都是即時的，我們目前半數以上的伺服器都裝了magickd服務，用來分擔圖片處理請求。

 

http://www.dbanotes.net/review/tailrank_arch.html

每天數以千萬計的 Blog 內容中，實時的熱點是什麼? Tailrank 這個 Web 2.0 Startup 致力於回答這個問題。

專門爆料網站架構的Todd Hoff對 Kevin Burton 進行了採訪。於是我們能瞭解一下 Tailrank架構的一些資訊。每小時索引 2400 萬的 Blog 與 Feed，內容處理能力為 160-200Mbps，IO 寫入大約在10-15MBps。每個月要處理 52T 之多的原始資料。Tailrank 所用的爬蟲現在已經成為一個獨立產品：spinn3r。

伺服器硬體

目前大約 15 臺伺服器，CPU 是 64 位的 Opteron。每臺主機上掛兩個 SATA 盤，做 RAID 0。據我所知，國內很多 Web 2.0 公司也用的是類似的方式，SATA 盤容量達，低廉價格，堪稱不二之選。作業系統用的是 Debian Linux 。Web 伺服器用 Apache 2.0，Squid 做反向代理伺服器。

資料庫

Tailrank 用 MySQL 資料庫，聯邦資料庫形式。儲存引擎用 InnoDB， 資料量 500GB。Kevin Burton 也指出了 MySQL 5 在修了一些 多核模式下互斥鎖的問題(This Bug?)。到資料庫的JDBC 驅動連線池用 lbpool 做負載均衡。MySQL Slave 或者 Master的複製用 MySQLSlaveSync 來輕鬆完成。不過即使這樣，還要花費 20％ 的時間來折騰 DB。

其他開放的軟體

任何一套系統都離不開合適的 Profiling 工具，Tailrank 也不利外，針對 Java 程式的 Benchmark 用Benchmark4j。Log 工具用 Log5j(不是 Log4j)。Tailrank 所用的大部分工具都是開放的。

Tailrank 的一個比較大的競爭對手是 Techmeme，雖然二者暫時看面向內容的側重點有所不同。其實，最大的對手還是自己，當需要挖掘的資訊量越來越大，如果精準並及時的呈現給使用者內容的成本會越來越高。從現在來看，Tailrank 離預期目標還差的很遠。期待羅馬早日建成

 

http://hideto.javaeye.com/blog/129726

YouTube架構學習

關鍵字: YouTube

原文: YouTube Architecture 

YouTube發展迅速，每天超過1億的視訊點選量，但只有很少人在維護站點和確保伸縮性。 

平臺 
Apache 
Python 
Linux(SuSe) 
MySQL 
psyco，一個動態的Python到C的編譯器 
lighttpd代替Apache做視訊檢視 

狀態 
支援每天超過1億的視訊點選量 
成立於2005年2月 
於2006年3月達到每天3千萬的視訊點選量 
於2006年7月達到每天1億的視訊點選量 
2個系統管理員，2個伸縮性軟體架構師 
2個軟體開發工程師，2個網路工程師，1個DBA 

處理飛速增長的流量

Java程式碼

1. while (true)   
2. {   
3.   identify_and_fix_bottlenecks();   
4.   drink();   
5.   sleep();   
6.   notice_new_bottleneck();   
7. }  

while (true)

{

 identify_and_fix_bottlenecks();

 drink();

 sleep();

 notice_new_bottleneck();

}

每天執行該迴圈多次 

Web伺服器 
1，NetScaler用於負載均衡和靜態內容快取 
2，使用mod_fast_cgi執行Apache 
3，使用一個Python應用伺服器來處理請求的路由 
4，應用伺服器與多個資料庫和其他資訊源互動來獲取資料和格式化html頁面 
5，一般可以通過新增更多的機器來在Web層提高伸縮性 
6，Python的Web層程式碼通常不是效能瓶頸，大部分時間阻塞在RPC 
7，Python允許快速而靈活的開發和部署 
8，通常每個頁面服務少於100毫秒的時間 
9，使用psyco(一個類似於JIT編譯器的動態的Python到C的編譯器)來優化內部迴圈 
10，對於像加密等密集型CPU活動，使用C擴充套件 
11，對於一些開銷昂貴的塊使用預先生成並快取的html 
12，資料庫裡使用行級快取 
13，快取完整的Python物件 
14，有些資料被計算出來併傳送給各個程式，所以這些值快取在本地記憶體中。這是個使用不當的策略。應用伺服器裡最快的快取將預先計算的值傳送給所有伺服器也花不了多少時間。只需弄一個代理來監聽更改，預計算，然後傳送。 

視訊服務 
1，花費包括頻寬，硬體和能源消耗 
2，每個視訊由一個迷你叢集來host，每個視訊被超過一臺機器持有 
3，使用一個叢集意味著： 
-更多的硬碟來持有內容意味著更快的速度 
-failover。如果一臺機器出故障了，另外的機器可以繼續服務 
-線上備份 
4，使用lighttpd作為Web伺服器來提供視訊服務： 
-Apache開銷太大 
-使用epoll來等待多個fds 
-從單程式配置轉變為多程式配置來處理更多的連線 
5，大部分流行的內容移到CDN： 
-CDN在多個地方備份內容，這樣內容離使用者更近的機會就會更高 
-CDN機器經常記憶體不足，因為內容太流行以致很少有內容進出記憶體的顛簸 
6，不太流行的內容(每天1-20瀏覽次數)在許多colo站點使用YouTube伺服器 
-長尾效應。一個視訊可以有多個播放，但是許多視訊正在播放。隨機硬碟塊被訪問 
-在這種情況下快取不會很好，所以花錢在更多的快取上可能沒太大意義。 
-調節RAID控制並注意其他低階問題 
-調節每臺機器上的記憶體，不要太多也不要太少 

視訊服務關鍵點 
1，保持簡單和廉價 
2，保持簡單網路路徑，在內容和使用者間不要有太多裝置 
3，使用常用硬體，昂貴的硬體很難找到幫助文件 
4，使用簡單而常見的工具，使用構建在Linux裡或之上的大部分工具 
5，很好的處理隨機查詢(SATA，tweaks) 

縮圖服務 
1，做到高效令人驚奇的難 
2，每個視訊大概4張縮圖，所以縮圖比視訊多很多 
3，縮圖僅僅host在幾個機器上 
4，持有一些小東西所遇到的問題： 
-OS級別的大量的硬碟查詢和inode和頁面快取問題 
-單目錄檔案限制，特別是Ext3，後來移到多分層的結構。核心2.6的最近改進可能讓Ext3允許大目錄，但在一個檔案系統裡儲存大量檔案不是個好主意 
-每秒大量的請求，因為Web頁面可能在頁面上顯示60個縮圖 
-在這種高負載下Apache表現的非常糟糕 
-在Apache前端使用squid，這種方式工作了一段時間，但是由於負載繼續增加而以失敗告終。它讓每秒300個請求變為20個 
-嘗試使用lighttpd但是由於使用單執行緒它陷於困境。遇到多程式的問題，因為它們各自保持自己單獨的快取 
-如此多的圖片以致一臺新機器只能接管24小時 
-重啟機器需要6-10小時來快取 
5，為了解決所有這些問題YouTube開始使用Google的BigTable，一個分散式資料儲存： 
-避免小檔案問題，因為它將檔案收集到一起 
-快，錯誤容忍 
-更低的延遲，因為它使用分散式多級快取，該快取與多個不同collocation站點工作 
-更多資訊參考GoogleArchitecture，GoogleTalk Architecture和BigTable 

資料庫 
1，早期 
-使用MySQL來儲存後設資料，如使用者，tags和描述 
-使用一整個10硬碟的RAID 10來儲存資料 
-依賴於信用卡所以YouTube租用硬體 
-YouTube經過一個常見的革命：單伺服器，然後單master和多read slaves，然後資料庫分割槽，然後sharding方式 
-痛苦與備份延遲。master資料庫是多執行緒的並且執行在一個大機器上所以它可以處理許多工作，slaves是單執行緒的並且通常執行在小一些的伺服器上並且備份是非同步的，所以slaves會遠遠落後於master 
-更新引起快取失效，硬碟的慢I/O導致慢備份 
-使用備份架構需要花費大量的money來獲得增加的寫效能 
-YouTube的一個解決方案是通過把資料分成兩個叢集來將傳輸分出優先次序：一個視訊檢視池和一個一般的叢集 
2，後期 
-資料庫分割槽 
-分成shards，不同的使用者指定到不同的shards 
-擴散讀寫 
-更好的快取位置意味著更少的IO 
-導致硬體減少30% 
-備份延遲降低到0 
-現在可以任意提升資料庫的伸縮性 

資料中心策略 
1，依賴於信用卡，所以最初只能使用受管主機提供商 
2，受管主機提供商不能提供伸縮性，不能控制硬體或使用良好的網路協議 
3，YouTube改為使用colocation arrangement。現在YouTube可以自定義所有東西並且協定自己的契約 
4，使用5到6個資料中心加CDN 
5，視訊來自任意的資料中心，不是最近的匹配或其他什麼。如果一個視訊足夠流行則移到CDN 
6，依賴於視訊頻寬而不是真正的延遲。可以來自任何colo 
7，圖片延遲很嚴重，特別是當一個頁面有60張圖片時 
8，使用BigTable將圖片備份到不同的資料中心，程式碼檢視誰是最近的 

學到的東西 
1，Stall for time。創造性和風險性的技巧讓你在短期內解決問題而同時你會發現長期的解決方案 
2，Proioritize。找出你的服務中核心的東西並對你的資源分出優先順序別 
3，Pick your battles。別怕將你的核心服務分出去。YouTube使用CDN來分佈它們最流行的內容。建立自己的網路將花費太多時間和太多money 
4，Keep it simple！簡單允許你更快的重新架構來回應問題 
5，Shard。Sharding幫助隔離儲存，CPU，記憶體和IO，不僅僅是獲得更多的寫效能 
6，Constant iteration onbottlenecks： 
-軟體：DB，快取 
-OS：硬碟I/O 
-硬體：記憶體，RAID 
7，You succeed as a team。擁有一個跨越條律的瞭解整個系統並知道系統內部是什麼樣的團隊，如安裝印表機，安裝機器，安裝網路等等的人。With a good team allthings are possible。

 

http://hideto.javaeye.com/blog/130815

Google架構學習

關鍵字: Google

原文：Google Architecture 

Google是伸縮性的王者。Google一直的目標就是構建高效能高伸縮性的基礎組織來支援它們的產品。 

平臺 
Linux 
大量語言：Python，Java，C++ 

狀態 
在2006年大約有450,000臺廉價伺服器 
在2005年Google索引了80億Web頁面，現在沒有人知道數目 
目前在Google有超過200個GFS叢集。一個叢集可以有1000或者甚至5000臺機器。成千上萬的機器從執行著5000000000000000位元組儲存的GFS叢集獲取資料，叢集總的讀寫吞吐量可以達到每秒40兆位元組 
目前在Google有6000個MapReduce程式，而且每個月都寫成百個新程式 
BigTable伸縮儲存幾十億的URL，幾百千千兆的衛星圖片和幾億使用者的引數選擇 

堆疊 
Google形象化它們的基礎組織為三層架構： 
1，產品：搜尋，廣告，email，地圖，視訊，聊天，部落格 
2，分散式系統基礎組織：GFS，MapReduce和BigTable 
3，計算平臺：一群不同的資料中心裡的機器 
4，確保公司裡的人們部署起來開銷很小 
5，花費更多的錢在避免丟失日誌資料的硬體上，其他型別的資料則花費較少 

可信賴的儲存機制GFS(Google FileSystem)
1，可信賴的伸縮性儲存是任何程式的核心需求。GFS就是Google的核心儲存平臺 
2，Google File System - 大型分散式結構化日誌檔案系統，Google在裡面扔了大量的資料 
3，為什麼構建GFS而不是利用已有的東西？因為可以自己控制一切並且這個平臺與別的不一樣，Google需要： 
-跨資料中心的高可靠性 
-成千上萬的網路節點的伸縮性 
-大讀寫頻寬的需求 
-支援大塊的資料，可能為上千兆位元組 
-高效的跨節點操作分發來減少瓶頸 
4，系統有Master和Chunk伺服器 
-Master伺服器在不同的資料檔案裡保持後設資料。資料以64MB為單位儲存在檔案系統中。客戶端與Master伺服器交流來在檔案上做後設資料操作並且找到包含使用者需要資料的那些Chunk伺服器 
-Chunk伺服器在硬碟上儲存實際資料。每個Chunk伺服器跨越3個不同的Chunk伺服器備份以建立冗餘來避免伺服器崩潰。一旦被Master伺服器指明，客戶端程式就會直接從Chunk伺服器讀取檔案 
6，一個上線的新程式可以使用已有的GFS叢集或者可以製作自己的GFS叢集 
7，關鍵點在於有足夠的基礎組織來讓人們對自己的程式有所選擇，GFS可以調整來適應個別程式的需求 

使用MapReduce來處理資料 
1，現在你已經有了一個很好的儲存系統，你該怎樣處理如此多的資料呢？比如你有許多TB的資料儲存在1000臺機器上。資料庫不能伸縮或者伸縮到這種級別花費極大，這就是MapReduce出現的原因 
2，MapReduce是一個處理和生成大量資料集的程式設計模型和相關實現。使用者指定一個map方法來處理一個鍵/值對來生成一箇中間的鍵/值對，還有一個reduce方法來合併所有關聯到同樣的中間鍵的中間值。許多真實世界的任務都可以使用這種模型來表現。以這種風格來寫的程式會自動並行的在一個大量機器的叢集裡執行。執行時系統照顧輸入資料劃分、程式在機器集之間執行的排程、機器失敗處理和必需的內部機器交流等細節。這允許程式設計師沒有多少並行和分散式系統的經驗就可以很容易使用一個大型分散式系統資源 
3，為什麼使用MapReduce？ 
-跨越大量機器分割任務的好方式 
-處理機器失敗 
-可以與不同型別的程式工作，例如搜尋和廣告。幾乎任何程式都有map和reduce型別的操作。你可以預先計算有用的資料、查詢字數統計、對TB的資料排序等等 
4，MapReduce系統有三種不同型別的伺服器 
-Master伺服器分配使用者任務到Map和Reduce伺服器。它也跟蹤任務的狀態 
-Map伺服器接收使用者輸入並在其基礎上處理map操作。結果寫入中間檔案 
-Reduce伺服器接收Map伺服器產生的中間檔案並在其基礎上處理reduce操作 
5，例如，你想在所有Web頁面裡的字數。你將儲存在GFS裡的所有頁面拋入MapReduce。這將在成千上萬臺機器上同時進行並且所有的調整、工作排程、失敗處理和資料傳輸將自動完成 
-步驟類似於：GFS -> Map ->Shuffle -> Reduction -> Store Results back into GFS 
-在MapReduce裡一個map操作將一些資料對映到另一箇中，產生一個鍵值對，在我們的例子裡就是字和字數 
-Shuffling操作聚集鍵型別 
-Reduction操作計算所有鍵值對的綜合併產生最終的結果 
6，Google索引操作管道有大約20個不同的map和reduction。 
7，程式可以非常小，如20到50行程式碼 
8，一個問題是掉隊者。掉隊者是一個比其他程式慢的計算，它阻塞了其他程式。掉隊者可能因為緩慢的IO或者臨時的CPU不能使用而發生。解決方案是執行多個同樣的計算並且當一個完成後殺死所有其他的 
9，資料在Map和Reduce伺服器之間傳輸時被壓縮了。這可以節省頻寬和I/O。 

在BigTable裡儲存結構化資料 
1，BigTable是一個大伸縮性、錯誤容忍、自管理的系統，它包含千千兆的記憶體和1000000000000000的儲存。它可以每秒鐘處理百萬的讀寫 
2，BigTable是一個構建於GFS之上的分散式雜湊機制。它不是關係型資料庫。它不支援join或者SQL型別查詢 
3，它提供查詢機制來通過鍵訪問結構化資料。GFS儲存儲存不透明的資料而許多程式需求有結構化資料 
4，商業資料庫不能達到這種級別的伸縮性並且不能在成千上萬臺機器上工作 
5，通過控制它們自己的低階儲存系統Google得到更多的控制權來改進它們的系統。例如，如果它們想讓跨資料中心的操作更簡單這個特性，它們可以內建它 
6，系統執行時機器可以自由的增刪而整個系統保持工作 
7，每個資料條目儲存在一個格子裡，它可以通過一個行key和列key或者時間戳來訪問 
8，每一行儲存在一個或多個tablet中。一個tablet是一個64KB塊的資料序列並且格式為SSTable 
9，BigTable有三種型別的伺服器： 
-Master伺服器分配tablet伺服器，它跟蹤tablet在哪裡並且如果需要則重新分配任務 
-Tablet伺服器為tablet處理讀寫請求。當tablet超過大小限制(通常是100MB-200MB)時它們拆開tablet。當一個Tablet伺服器失敗時，則100個Tablet伺服器各自挑選一個新的tablet然後系統恢復。 
-Lock伺服器形成一個分散式鎖服務。像開啟一個tablet來寫、Master調整和訪問控制檢查等都需要互斥 
10，一個locality組可以用來在物理上將相關的資料儲存在一起來得到更好的locality選擇 
11，tablet儘可能的快取在RAM裡 

硬體 
1，當你有很多機器時你怎樣組織它們來使得使用和花費有效？ 
2，使用非常廉價的硬體 
3，A 1,000-fold computerpower increase can be had for a 33 times lower cost if you you use afailure-prone infrastructure rather than an infrastructure built on highlyreliable components. You must build reliability on top of unreliability forthis strategy to work. 
4，Linux，in-house rack design，PC主機板，低端儲存 
5，Price per wattage onperformance basis isn't getting better. Have huge power and cooling issues 
6，使用一些collocation和Google自己的資料中心 

其他 
1，迅速更改而不是等待QA 
2，庫是構建程式的卓越方式 
3，一些程式作為服務提供 
4，一個基礎組織處理程式的版本，這樣它們可以釋出而不用害怕會破壞什麼東西 

Google將來的方向 
1，支援地理位置分佈的叢集 
2，為所有資料建立一個單獨的全域性名字空間。當前的資料由叢集分離 
3，更多和更好的自動化資料遷移和計算 
4，解決當使用網路劃分來做廣闊區域的備份時的一致性問題(例如保持服務即使一個叢集離線維護或由於一些損耗問題) 

學到的東西 
1，基礎組織是有競爭性的優勢。特別是對Google而言。Google可以很快很廉價的推出新服務，並且伸縮性其他人很難達到。許多公司採取完全不同的方式。許多公司認為基礎組織開銷太大。Google認為自己是一個系統工程公司，這是一個新的看待軟體構建的方式 
2，跨越多個資料中心仍然是一個未解決的問題。大部分網站都是一個或者最多兩個資料中心。我們不得不承認怎樣在一些資料中心之間完整的分佈網站是很需要技巧的 
3，如果你自己沒有時間從零開始重新構建所有這些基礎組織你可以看看Hadoop。Hadoop是這裡很多同樣的主意的一個開源實現 
4，平臺的一個優點是初級開發人員可以在平臺的基礎上快速並且放心的建立健全的程式。如果每個專案都需要發明同樣的分散式基礎組織的輪子，那麼你將陷入困境因為知道怎樣完成這項工作的人相對較少 
5，協同工作不一直是擲骰子。通過讓系統中的所有部分一起工作則一個部分的改進將幫助所有的部分。改進檔案系統則每個人從中受益而且是透明的。如果每個專案使用不同的檔案系統則在整個堆疊中享受不到持續增加的改進 
6，構建自管理系統讓你沒必要讓系統關機。這允許你更容易在伺服器之間平衡資源、動態新增更大的容量、讓機器離線和優雅的處理升級 
7，建立可進化的基礎組織，並行的執行消耗時間的操作並採取較好的方案 
8，不要忽略學院。學院有許多沒有轉變為產品的好主意。Most of what Googlehas done has prior art, just not prior large scale deployment. 
9，考慮壓縮。當你有許多CPU而IO有限時壓縮是一個好的選擇。

 

http://blog.daviesliu.net/2006/09/09/010620/

Lighttpd+Squid+Apache搭建高效率Web伺服器

架構原理

Apache通常是開源界的首選Web伺服器，因為它的強大和可靠，已經具有了品牌效應，可以適用於絕大部分的應用場合。但是它的強大有時候卻顯得笨重，配置檔案得讓人望而生畏，高併發情況下效率不太高。而輕量級的Web伺服器Lighttpd卻是後起之秀，其靜態檔案的響應能力遠高於Apache，據說是Apache的2-3倍。Lighttpd的高效能和易用性，足以打動我們，在它能夠勝任的領域，儘量用它。Lighttpd對PHP的支援也很好，還可以通過Fastcgi方式支援其他的語言，比如Python。

畢竟Lighttpd是輕量級的伺服器，功能上不能跟Apache比，某些應用無法勝任。比如Lighttpd還不支援快取，而現在的絕大部分站點都是用程式生成動態內容，沒有快取的話即使程式的效率再高也很難滿足大訪問量的需求，而且讓程式不停的去做同一件事情也實在沒有意義。首先，Web程式是需要做快取處理的，即把反覆使用的資料做快取。即使這樣也還不夠，單單是啟動Web處理程式的代價就不少，快取最後生成的靜態頁面是必不可少的。而做這個是 Squid的強項，它本是做代理的，支援高效的快取，可以用來給站點做反向代理加速。把Squid放在Apache或者Lighttpd的前端來快取 Web伺服器生成的動態內容，而Web應用程式只需要適當地設定頁面實效時間即可。

即使是大部分內容動態生成的網站，仍免不了會有一些靜態元素，比如圖片、JS指令碼、CSS等等，將Squid放在Apache或者Lighttp前端後，反而會使效能下降，畢竟處理HTTP請求是Web伺服器的強項。而且已經存在於檔案系統中的靜態內容再在Squid中快取一下，浪費記憶體和硬碟空間。因此可以考慮將Lighttpd再放在Squid的前面，構成 Lighttpd+Squid+Apache的一條處理鏈，Lighttpd在最前面，專門用來處理靜態內容的請求，把動態內容請求通過proxy模組轉發給Squid，如果Squid中有該請求的內容且沒有過期，則直接返回給Lighttpd。新請求或者過期的頁面請求交由Apache中Web程式來處理。經過Lighttpd和Squid的兩級過濾，Apache需要處理的請求將大大減少，減少了Web應用程式的壓力。同時這樣的構架，便於把不同的處理分散到多臺計算機上進行，由Lighttpd在前面統一把關。

在這種架構下，每一級都是可以進行單獨優化的，比如Lighttpd可以採用非同步IO方式，Squid可以啟用記憶體來快取，Apache可以啟用MPM 等，並且每一級都可以使用多臺機器來均衡負載，伸縮性很好