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 離預期目標還差的很遠。期待羅馬早日建成
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站點工作
-更多信息參考Google Architecture，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 on bottlenecks：
-軟件：DB，緩存
-OS：硬盤I/O
-硬件：內存，RAID
7，You succeed as a team。擁有一個跨越條律的瞭解整個系統並知道系統內部是什麼樣的團隊，如安裝打印機，安裝機器，安裝網絡等等的人。With a good team all things are possible。
http://hideto.iteye.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 File System)
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 computer power increase can be had for a 33 times lower cost if you you use a failure-prone infrastructure rather than an infrastructure built on highly reliable components. You must build reliability on top of unreliability for this strategy to work.
4，Linux，in-house rack design，PC主板，低端存儲
5，Price per wattage on performance 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 Google has 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 等，並且每一級都可以使用多臺機器來均衡負載，伸縮性很好。
轉自：http://147175882.iteye.com/blog/281438