發(fā)布時(shí)間：2011-09-07 8:06:58 作者：957515135@qq.com 閱讀次數：56
Flickr.com 是網(wǎng)上最受歡迎的照片共享網(wǎng)站之一，還記得那位給Windows Vista拍攝壁紙的HamadDarwish嗎？他就是將照片上傳到Flickr，后而被微軟看中成為Vista壁紙御用攝影師。
Flickr.com 是最初由位于溫哥華的Ludicorp公司開(kāi)發(fā)設計并于2004年2月正式發(fā)布的，由于大量應用了WEB2.0技術(shù)，注重用戶(hù)體驗，使得其迅速獲得了大量的用戶(hù)，2007年11月，Flickr迎來(lái)了第20億張照片，一年后，這個(gè)數字就達到了30億，并且還在以加速度增長(cháng)。2005年3月，雅虎公司以3千500萬(wàn)美元收購了Ludicorp公司和Flickr.com。雖然Flickr并不是最大的照片共享網(wǎng)站（Facebook以超過(guò)100億張照片排名第一），但這筆收購仍然被認為是WEB2.0浪潮中最精明的收購，因為僅僅一年后，Google就以16億美元的高價(jià)收購了YouTube，而2007年10月，微軟斥資2.4億美元收購 Facebook1.6%股份，此舉使Facebook估值高達150億美元。估計Ludicorp公司的創(chuàng )始人Stewart Butterfield和CaterinaFake夫婦現在還在后悔吧。
在2005年溫哥華PHP協(xié)會(huì )的簡(jiǎn)報以及隨后的一系列會(huì )議上，Flickr的架構師CalHenderson公開(kāi)了大部分Flickr所使用的后臺技術(shù)，使得我們能有機會(huì )來(lái)分享和研究其在構建可擴展Web站點(diǎn)的經(jīng)驗。本文大部分資料來(lái)自互聯(lián)網(wǎng)和自己的一點(diǎn)點(diǎn)心得，歡迎大家參與討論，要是能夠起到拋磚引玉的作用，本人將不勝榮幸。
Flickr整體框架圖
在討論Flickr 網(wǎng)站架構之前，讓我們先來(lái)看一組統計數據（數據來(lái)源：April 2007 MySQL Conf andExpo和Flickr網(wǎng)站）
每天多達40億次的查詢(xún)請求
squid總計約有3500萬(wàn)張照片（硬盤(pán)+內存）
squid內存中約有200萬(wàn)張照片
總計有大約4億7000萬(wàn)張照片，每張圖片又生成不同尺寸大小的4－5份圖片
每秒38，000次Memcached請求 (Memcached總共存儲了1200萬(wàn)對象)
超過(guò)2 PB 存儲，其中數據庫12TB
每天新增圖片超過(guò) 40萬(wàn)（周日峰值超過(guò)200萬(wàn)，約1.5TB)
超過(guò)8百50萬(wàn)注冊用戶(hù)
超過(guò)1千萬(wàn)的唯一標簽（tags)
響應4萬(wàn)個(gè)照片訪(fǎng)問(wèn)請求
處理10萬(wàn)個(gè)緩存操作
運行13萬(wàn)個(gè)數據庫查詢(xún)
這張是Flickr的網(wǎng)站架構圖，我們這里只作一些簡(jiǎn)要的描述，具體的分析請靜待后續文章。
Pair of ServerIron's做負載均衡方案
Squid Caches 代理，用于緩存靜態(tài)的HTML和照片
Net App公司的Filer, NAS存儲設備，用于存儲照片
PHP App Servers
－ 運行REDHAT LINUX,Apache上的PHP應用，Flickr網(wǎng)站的主體是大約6萬(wàn)行PHP代碼
－ 沒(méi)有使用PHP session, 應用是stateless,便于擴展，并避免PHP Server故障所帶來(lái)的Session失效。
－ 每個(gè)頁(yè)面有大約27～35個(gè)查詢(xún)（不知道為什么這么設計，個(gè)人覺(jué)得沒(méi)有必要）
－ 另有專(zhuān)門(mén)的Apache Web Farm 服務(wù)于靜態(tài)文件（HTML和照片）的訪(fǎng)問(wèn)
Storage Manager 運行私有的，適用于海量文件存儲的Flickr File System
Dual Tree Central Database
－ MySQL 數據庫，存放用戶(hù)表，記錄的信息是用戶(hù)主鍵以及此用戶(hù)對以的數據庫Shard區，從中心用戶(hù)表中查出用戶(hù)數據所在位置，然后直接從目標Shard中取出數據。
－ “Dual Tree"架構是”Master－Master"和“Master-Slave"的有效結合，雙Master 避免了“單點(diǎn)故障”，Master－Slave又提高了讀取速度，因為用戶(hù)表的操作90％以上是讀。
Master-master shards
－ MySQL 數據庫，存儲實(shí)際的用戶(hù)數據和照片的元數據（Meta Data)，每個(gè)Shard 大約40萬(wàn)個(gè)用戶(hù)，120GB 數據。每個(gè)用戶(hù)的所有數據存放在同一個(gè)shard中。
－ Shard中的每一個(gè)server的負載只是其可最大負載的50％，這樣在需要的時(shí)候可以Online停掉一半的server進(jìn)行升級或維護而不影響系統性能。
－ 為了避免跨Shard查詢(xún)所帶來(lái)的性能影響，一些數據有在不同的Shard有兩份拷貝，比如用戶(hù)對照片的評論，通過(guò)事務(wù)來(lái)保證其同步。
Memcached Cluster 中間層緩存服務(wù)器，用于緩存數據庫的SQL查詢(xún)結果等。
Big Search Engine
- 復制部分Shard數據（Owner’s single tag）到Search Engine Farm以響應實(shí)時(shí)的全文檢索。
- 其他全文檢索請求利用Yahoo的搜索引擎處理（Flickr是Yahoo旗下的公司
）
服務(wù)器的硬件配置：
- Intel或AMD 64位CPU，16GB RAM
- 6-disk 15K RPM RAID-10.
- 2U boxes.
服務(wù)器數量：(數據來(lái)源：April 2008 MySQL Conference & Expo)
166 DB servers, 244 web servers(不知道是否包括 squid server？), 14 Memcached servers
數據庫最初的擴展-Replication
也許有人不相信，不過(guò)Flickr確實(shí)是從一臺服務(wù)器起步的，即Apache/PHP和MySQL是運行在同一臺服務(wù)器上的，很快MySQL服務(wù)器就獨立了出來(lái)，成了雙服務(wù)器架構。隨著(zhù)用戶(hù)和訪(fǎng)問(wèn)量的快速增長(cháng)，MySQL數據庫開(kāi)始承受越來(lái)越大的壓力，成為應用瓶頸，導致網(wǎng)站應用響應速度變慢,MySQL的擴展問(wèn)題就擺在了Flickr的技術(shù)團隊面前。
不幸的是，在當時(shí)，他們的選擇并不多。一般來(lái)說(shuō)，數據庫的擴展無(wú)外是兩條路，Scale-Up和Scale-Out,所謂Scale-Up，簡(jiǎn)單的說(shuō)就是在同一臺機器內增加CPU,內存等硬件來(lái)增加數據庫系統的處理能力，一般不需要修改應用程序；而Scale-Out,就是我們通常所說(shuō)的數據庫集群方式，即通過(guò)增加運行數據庫服務(wù)器的數量來(lái)提高系統整體的能力，而應用程序則一般需要進(jìn)行相應的修改。在常見(jiàn)的商業(yè)數據庫中，Oracle具有很強的Scale-Up的能力，很早就能夠支持幾十個(gè)甚至數百個(gè)CPU，運行大型關(guān)鍵業(yè)務(wù)應用；而微軟的SQLSERVER，早期受Wintel架構所限，以Scale-Out著(zhù)稱(chēng)，但自從幾年前突破了Wintel體系架構8路CPU的的限制，Scale-Up的能力一路突飛猛進(jìn)，最近更是發(fā)布了SQL 2008在Windows 2008R2版運行256個(gè)CPU核心(core)的測試結果，開(kāi)始挑戰Oracle的高端市場(chǎng)。而MySQL，直到今年4月，在最終采納了GOOGLE公司貢獻的SMP性能增強的代碼后，發(fā)布了MySQL5.4后，才開(kāi)始支持16路CPU的X86系統和64路CPU的CMT系統(基于Sun UltraSPARC的系統）。
從另一方面來(lái)說(shuō)，Scale-Up受軟硬件體系的限制，不可能無(wú)限增加ＣＰＵ和內存，相反Scale-Out卻是可以"幾乎"無(wú)限的擴展,以Google為例，２006年Google一共有超過(guò)４５萬(wàn)臺服務(wù)器（誰(shuí)能告訴我現在他們有多少？?。?；而且大型ＳＭＰ服務(wù)器的價(jià)格遠遠超過(guò)普通的雙路服務(wù)器，對于很多剛剛起步或是業(yè)務(wù)增長(cháng)很難預測的網(wǎng)站來(lái)說(shuō)，不可能也沒(méi)必要一次性投資購買(mǎi)大型的硬件設備，因而雖然Scale-Out會(huì )隨著(zhù)服務(wù)器數量的增多而帶來(lái)管理，部署和維護的成本急劇上升，但確是大多數大型網(wǎng)站當然也包括Flickr的唯一選擇。
經(jīng)過(guò)統計，Flickr的技術(shù)人員發(fā)現，查詢(xún)即SELECT語(yǔ)句的數量要遠遠大于添加，更新和
刪除的數量，比例達到了大約13：1甚至更多，所以他們采用了“Master-Slave”的復制模式，即所有的“寫(xiě)”操作都在發(fā)生在“Master"，然后”異步“復制到一臺或多臺“Slave"上，而所有的”讀“操作都轉到”Slave"上運行，這樣隨著(zhù)“讀”交易量的增加，只需增加Slave服務(wù)器 就可以了。
讓我們來(lái)看一下應用系統應該如何修改來(lái)適應這樣的架構，除了”讀/寫(xiě)“分離外，對于”讀“操作最基本的要求是：1）應用程序能夠在多個(gè)”Slave“上進(jìn)行負載均分；2）當一個(gè)或多個(gè)”slave"出現故障時(shí)，應用程序能自動(dòng)嘗試下一個(gè)“slave”，如果全部“Slave"失效，則返回錯誤。Flickr曾經(jīng)考慮過(guò)的方案是在Web應用和”Slave“群之間加入一個(gè)硬件或軟件的”Load Balancer“，如下圖
這樣的好處是應用所需的改動(dòng)最小，因為對于應用來(lái)說(shuō)，所有的讀操作都是通過(guò)一個(gè)虛擬的Slave來(lái)進(jìn)行，添加和刪除“Slave"服務(wù)器對應用透明，Load Balancer實(shí)現對各個(gè)Slave服務(wù)器狀態(tài)的監控并將出現故障的Slave從可用節點(diǎn)列表里刪除，并可以實(shí)現一些復雜的負載分擔策略，比如新買(mǎi)的服務(wù)器處理能力要高過(guò)Slave群中其他的老機器，那么我們可以給這個(gè)機器多分配一些負載以最有效的利用資源。一個(gè)簡(jiǎn)單的利用Apacheproxy_balancer_module的例子如下：
1
2
3
4
5
6
7
8
9
10
11
。。。。。。。。。。。。。。
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
LoadModule proxy_http_module modules/mod_proxy_http.so
。。。。。。。。。。。。。。。。。。。。
<Proxy
balancer://mycluster>
BalancerMember "
http://slave1:8008/App" loadfactor=4
BalancerMember "
http://slave2:8008/App" loadfactor=3
BalancerMember "
http://slave3:8008/App" loadfactor=3
....................
///slave load ratio 4:3:3.
最終，Flickr采用了一種非?！拜p量”但有效的“簡(jiǎn)易”P(pán)HP實(shí)現，基本的代碼只有10幾行：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
function db_connect($hosts, $user, $pass){
shuffle($hosts); //shuffle()是PHP函數，作用是將數組中每個(gè)元素的順序隨機打亂。
foreach($hosts as $host){
debug("Trying to connect to $host...");
$dbh = @mysql_connect($host, $user, $pass, 1);
if ($dbh){
debug("Connected to $host!");
return $dbh;
}
debug("Failed to connect to $host!");
}
debug("Failed to connect to all hosts in list - giving up!");
return 0;
}
在上述代碼中，如果需要對特定的Slave賦予更高的負載，只要在$hosts中多出現一次或多次就可以了。這段代碼只要稍稍改進(jìn)，就可以實(shí)現更復雜的功能，如當connect失敗時(shí)自動(dòng)將host從hosts列表中去除等。
“Master”-"Slave"模式的缺點(diǎn)是它并沒(méi)有對于“寫(xiě)'操作提供擴展能力，而且存在單點(diǎn)故障，即一旦Master故障，整個(gè)網(wǎng)站將喪失“更新”的能力。解決的辦法采用“Master"-"Master"模式，即兩臺服務(wù)器互為”Master“-"Slave",這樣不僅”讀/寫(xiě)“能力擴展了一倍，而且有效避免了”單點(diǎn)故障“，結合已有的“Master"-"Slave",整個(gè)數據庫的架構就變成了下面的”雙樹(shù)“結構，
。
“雙樹(shù)”架構并沒(méi)有支撐太久的時(shí)間，大概6個(gè)月后，隨著(zhù)用戶(hù)的激增，系統再一次達到了極限，不僅”寫(xiě)”操作成為了瓶頸，而且“異步復制"也由于”Slave“服務(wù)器過(guò)于繁忙而出現了嚴重的滯后而造成讀數據的不一致。那么，能不能在現有架構加以解決，比如說(shuō)增加新的”Master“服務(wù)器和考慮采用”同步復制“呢？答案是否定的，在Master超過(guò)兩臺的設置中，只能采用”閉環(huán)鏈“的方式進(jìn)行復制，在大數據量的生產(chǎn)環(huán)境中，很容易造成在任意時(shí)刻沒(méi)有一個(gè)Master或Slave節點(diǎn)是具有全部最新數據的（有點(diǎn)類(lèi)似于”人一次也不能踏進(jìn)同一條河“？），這樣很難保障數據的一致性，而且一旦其中一個(gè)Master出現故障，將中斷整個(gè)復制鏈；而對于”同步復制“，當然這是消除”復制滯后“的最好辦法，不過(guò)在當時(shí)MySQL的同步復制還遠沒(méi)有成熟到可以運用在投產(chǎn)環(huán)境中。
Flickr網(wǎng)站的架構，需要一次大的變化來(lái)解決長(cháng)期持續擴展的問(wèn)題。
Shard - 大型網(wǎng)站數據庫擴展的終極武器？
2005年７月，另一位大牛(MySQL 2005、2006年度 "Application of the Year Award"獲得者)DathanPattishall加入了Flickr團隊。一個(gè)星期之內，Dathan解決了Flickr數據庫40%的問(wèn)題，更重要的是，他為Flickr引進(jìn)了Shard架構，從而使Flickr網(wǎng)站具備了真正“線(xiàn)性”Scale-Out的增長(cháng)能力，并一直沿用至今，取得了巨大的成功。
Shard主要是為了解決傳統數據庫Master/Slave模式下單一Master數據庫的“寫(xiě)”瓶頸而出現的，簡(jiǎn)單的說(shuō)Shard就是將一個(gè)大表分割成多個(gè)小表，每個(gè)小表存儲在不同機器的數據庫上，從而將負載分散到多個(gè)機器并行處理而極大的提高整個(gè)系統的“寫(xiě)”擴展能力。相比傳統方式，由于每個(gè)數據庫都相對較小，不僅讀寫(xiě)操作更快，甚至可以將整個(gè)小數據庫緩存到內存中，而且每個(gè)小數據庫的備份，恢復也變得相對容易，同時(shí)由于分散了風(fēng)險，單個(gè)小數據庫的故障不會(huì )影響其他的數據庫，使整個(gè)系統的可靠性也得到了顯著(zhù)的提高。
對于大多數網(wǎng)站來(lái)說(shuō)，以用戶(hù)為單位進(jìn)行Shard分割是最合適不過(guò)的，常見(jiàn)的分割方法有按地域（比如郵編），按Key值（比如Hash用戶(hù)ID),這些方法可以簡(jiǎn)單的通過(guò)應用配置文件或算法來(lái)實(shí)現，一般不需要另外的數據庫，缺點(diǎn)是一旦業(yè)務(wù)增加，需要再次分割Shard時(shí)要修改現有的應用算法和重新計算所 有的ShardKEY值；而最為靈活的做法是以“目錄”服務(wù)為基礎的分割，即在Shard之前加一個(gè)中央數據庫（Global LookupCluster），應用要先根據用戶(hù)主鍵值查詢(xún)中央數據庫，獲得用戶(hù)數據所在的Shard，隨后的操作再轉向Shard所在數據庫，例如下圖：
而應用的主要修改在于要添加一個(gè)Lookup訪(fǎng)問(wèn)層，例如將以下的代碼：
1
2
3
string connectionString = @"Driver={MySQL};SERVER=dbserver;DATABASE=CustomerDB;";
OdbcConnection conn = new OdbcConnection(connectionString);
conn.Open();
變?yōu)椋?div style="height:15px;">
DualTree Central Database就是中央數據庫，存放用戶(hù)表，記錄的信息是用戶(hù)主鍵以及此用戶(hù)對以的數據庫Shard區；而Master-MasterShards就是一個(gè)個(gè)的Shard用戶(hù)數據庫，存儲實(shí)際的用戶(hù)數據和照片的元數據（Meta Data)。
Flickr Shard的設計我們在Flickr網(wǎng)站架構研究（１）中已經(jīng)總結過(guò)了，在此不再贅述。我們在此談一下Shard架構的主要問(wèn)題和Flickr的解決辦法：１）Shard只適用于不需要join操作的表，因為跨Shard join操作的開(kāi)銷(xiāo)太大，解決的辦法是將一個(gè)用戶(hù)的所有數據全部存放在同一個(gè)Shard里，對于一些傳統方式下需要跨Shard查詢(xún)的數據，只能采取冗余的方法，比如Shard1的用戶(hù)A對Shard2的用戶(hù)B的照片進(jìn)行了評論，那么這條評論將同時(shí)存放在Shard1和Shard2中。這樣就存在一個(gè)數據一致性的問(wèn)題，常規的做法是用數據庫事務(wù)(Transaction)、”兩階段提交“(2 phasecommit)來(lái)解決，但做過(guò)兩階段提交（2PC）應用的都知道，2PC的效率相對較差，而且實(shí)際上也不能100%保證數據的完整性和一致性；另外，一旦由于其中一個(gè)Shard故障而提交失敗回滾，用戶(hù)只能放棄或再試一遍，用戶(hù)體驗較差。Flickr對于數據一致性的解決方案是Queue（Flickr用PHP開(kāi)發(fā)了一個(gè)強大的Queue系統，將所有可以異步的任務(wù)都用Queue來(lái)實(shí)現，每天處理高達１千萬(wàn)以上的任務(wù)。）,事實(shí)上當用戶(hù)A對用戶(hù)B的照片進(jìn)行評論時(shí)，他并不關(guān)心這條評論什么時(shí)候出現在用戶(hù)B的界面上，即將這條評論添加到用戶(hù)B的交易是可以異步的，允許一定的遲延，通過(guò)Queue處理，既保證了數據的一致性，又縮短了用戶(hù)端的相應時(shí)間，提高了系統性能。２）Shard的另一個(gè)主要問(wèn)題Rebalancing,既當現有Shard的負載達到一定的閥值，如何將現有數據再次分割，Flickr目前的方式依然是手工的，既人工來(lái)確定哪些用戶(hù)需要遷移，然后運行一個(gè)后臺程序進(jìn)行數據遷移，遷移的過(guò)程用戶(hù)賬戶(hù)將被鎖住。（據說(shuō)Google做到了完全自動(dòng)的Rebalancing,本著(zhù)”薩大“坑里不再挖坑的原則，如果有機會(huì )的話(huà)，留到下一個(gè)系列再研究 吧）
大家應該已經(jīng)注意到，Flickr為中央數據庫配置了Memcached作為數據庫緩存，接下來(lái)的問(wèn)題是，為什么用Memcached?為什么Shard不需要Memcached?Memcached和Master,Slave的關(guān)系怎樣？筆者將試圖回答這些問(wèn)題供大家參考，網(wǎng)上的相關(guān)爭論很多，有些問(wèn)題尚未有定論。
Memecached是一個(gè)高性能的，分布式的，開(kāi)源的內存對象緩存系統，顧名思義，它的主要目的是將經(jīng)常讀取的對象放入內存以提高整個(gè)系統，尤其是數據庫的擴展能力。Memcached的主要結構是兩個(gè)Hash Table,Server端的HashTable以key-valuepair的方式存放對象值，而Client端的HashTable的則決定某一對象存放在哪一個(gè)MemcachedServer.舉個(gè)例子說(shuō)，后臺有３個(gè)MemecachedServer,A、B、C,Client1需要將一個(gè)對象名為”userid123456“，值為“魯丁"的存入，經(jīng)過(guò)Client1的Hash計算，"userid123456"的值應該放入Memcached ServerB,而這之后，Client2需要讀取"userid123456"的值，經(jīng)過(guò)同樣的Hash計算，得出"userid123456"的值如果存在的話(huà)應該在Memcached ServerB，并從中取出。最妙的是Server之間彼此是完全獨立的，完全不知道對方的存在，沒(méi)有一個(gè)類(lèi)似與Master或AdminServer的存在，增加和減少Server只需在Client端"注冊"并重新Hash就可以了。
Memcached作為數據庫緩存的作用主要在于減輕甚至消除高負載數據庫情況下頻繁讀取所帶來(lái)的DiskI/O瓶頸，相對于數據庫自身的緩存來(lái)說(shuō)，具有以下優(yōu)點(diǎn)：１）Memecached的緩存是分布式的，而數據庫的緩存只限于本機；２）Memcached緩存的是對象，可以是經(jīng)過(guò)復雜運算和查詢(xún)的最終結果，并且不限于數據，可以是任何小于１MB的對象，比如html文件等；而數據庫緩存是以"row"為單位的，一旦"row"中的任何數據更新，整個(gè)“row"將進(jìn)行可能是對應用來(lái)說(shuō)不必要的更新；３）Memcached的存取是輕量的，而數據庫的則相對較重，在低負載的情況下，一對一的比較,Memcached的性能未必能超過(guò)數據庫，而在高負載的情況下則優(yōu)勢明顯。
Memcached并不適用于更新頻繁的數據，因為頻繁更新的數據導致大量的Memcached更新和較低的緩沖命中率，這可能也是為什么Shard沒(méi)有集成它的原因；Memcached更多的是擴展了數據庫的”讀“操作，這一點(diǎn)上它和Slave的作用有重疊，以至于有人爭論說(shuō)應該讓"Relication"回到它最初的目的”OnlineBackup"數據庫上，而通過(guò)Memcached來(lái)提供數據庫的“讀”擴展。（當然也有人說(shuō)，考慮到Memcached的對應用帶來(lái)的復雜性，還是慎用。）
然而，在體系架構中增加Memecached并不是沒(méi)有代價(jià)的，現有的應用要做適當的修改來(lái)同步Memcached和數據庫中的數據，同時(shí)Memcached不提供任何冗余和“failover”功能，這些復雜的控制都需要應用來(lái)實(shí)現?；镜膽眠壿嬋缦拢?div style="height:15px;">
