于敦德 2006-6-27
FeedBurner（以下簡(jiǎn)稱(chēng)FB，呵呵）我想應該是大家耳熟能詳的一個(gè)名字，在國內我們有一個(gè)同樣的服務(wù)商，叫做FeedSky。在2004年7月份，FB的流量是300kbps，托管是5600個(gè)源，到2005年4月份，流量已經(jīng)增長(cháng)到5Mbps，托管了47700個(gè)源；到2005年9月份流量增長(cháng)到20M，托管了109200個(gè)源，而到2006年4月份，流量已經(jīng)到了115Mbps，270000個(gè)源，每天點(diǎn)擊量一億次。
FB的服務(wù)使用Java實(shí)現，使用了Mysql數據庫。我們下面來(lái)看一下FB在發(fā)展的過(guò)程中碰到的問(wèn)題，以及解決的方案。
在2004年8月份，FB的硬件設備包括3臺Web服務(wù)器，3臺應用服務(wù)器和兩臺數據庫服務(wù)器，使用DNS輪循分布服務(wù)負載，將前端請求分布到三臺Web服務(wù)器上。說(shuō)實(shí)話(huà)，如果不考慮穩定性，給5600個(gè)源提供服務(wù)應該用不了這么多服務(wù)器?，F在的問(wèn)題是即使用了這么多服務(wù)器他們還是無(wú)法避免單點(diǎn)問(wèn)題，單點(diǎn)問(wèn)題將至少影響到1/3的用戶(hù)。FB采用了監控的辦法來(lái)解決，當監控到有問(wèn)題出現時(shí)及時(shí)重啟來(lái)避免更多用戶(hù)受到影響。FB采用了Cacti(http://www.cacti.net)和Nagios(http://www.nagios.org)來(lái)做監控。
FB碰到的第二個(gè)問(wèn)題是訪(fǎng)問(wèn)統計和管理?？梢韵胂?，每當我們在RSS閱讀器里點(diǎn)擊FB發(fā)布的內容，都需要做實(shí)時(shí)的統計，這個(gè)工作量是多么的巨大。大量寫(xiě)操作將導致系統的效率急劇下降，如果是Myisam表的話(huà)還會(huì )導致表的死鎖。FB一方面采用異步寫(xiě)入機制，通過(guò)創(chuàng )建執行池來(lái)緩沖寫(xiě)操作；只對本日的數據進(jìn)行實(shí)時(shí)統計，而以前的數據以統計結果形式存儲，進(jìn)而避免每次查看訪(fǎng)問(wèn)統計時(shí)的重復計算。所以每一天第一次訪(fǎng)問(wèn)統計信息時(shí)速度可能會(huì )慢，這個(gè)時(shí)候應該是FB在分析整理前一天的數據，而接下來(lái)的訪(fǎng)問(wèn)由于只針對當日數據進(jìn)行分析，數據量小很多，當然也會(huì )快很多。FB的Presentation是這樣寫(xiě)，但我發(fā)現好像我的FB里并沒(méi)有今天實(shí)時(shí)的統計，也許是我觀(guān)察的不夠仔細-_-!
現在第三個(gè)問(wèn)題出現了，由于大多數的操作都集中在主數據庫上，數據庫服務(wù)器的讀寫(xiě)出現了沖突，前面提到過(guò)Myiasm類(lèi)型的數據庫在寫(xiě)入的時(shí)候會(huì )鎖表，這樣就導致了讀寫(xiě)的沖突。在開(kāi)始的時(shí)候由于讀寫(xiě)操作比較少這個(gè)問(wèn)題可能并不明顯，但現在已經(jīng)到了不能忽視的程度。解決方案是平衡讀寫(xiě)的負載，以及擴展HibernateDaoSupport，區分只讀與讀寫(xiě)操作，以實(shí)現針對讀寫(xiě)操作的不同處理。
現在是第四個(gè)問(wèn)題：數據庫全面負載過(guò)高。由于使用數據庫做為緩存，同時(shí)數據庫被所有的應用服務(wù)器共享，速度越來(lái)越慢，而這時(shí)數據庫大小也到了Myisam的上限-4GB，FB的同學(xué)們自己都覺(jué)得自己有點(diǎn)懶?。解決方案是使用內存做緩存，而非數據庫，他們同樣使用了我們前面推薦的memcached，同時(shí)他們還使用了Ehcache(http://ehcache.sourceforge.net/)，一款基于Java的分布式緩存工具。
第五個(gè)問(wèn)題：流行rss源帶來(lái)大量重復請求，導致系統待處理請求的堆積。同時(shí)我們注意到在RSS源小圖標有時(shí)候會(huì )顯示有多少用戶(hù)訂閱了這一RSS源，這同樣需要服務(wù)器去處理，而目前所有的訂閱數都在同一時(shí)間進(jìn)行計算，導致對系統資源的大量占用。解決方案，把計算時(shí)間錯開(kāi)，同時(shí)在晚間處理堆積下來(lái)的請求，但這仍然不夠。
問(wèn)題六：狀態(tài)統計寫(xiě)入數據庫又一次出問(wèn)題了。越來(lái)越多的輔助數據（包括廣告統計，文章點(diǎn)擊統計，訂閱統計）需要寫(xiě)入數據庫，導致太多的寫(xiě)操作。解決方案：每天晚上處理完堆積下來(lái)的請求后對子表進(jìn)行截斷操作：
– FLUSH TABLES; TRUNCATE TABLE ad_stats0;
這樣的操作對Master數據庫是成功的，但對Slave會(huì )失敗，正確的截斷子表方法是：
– ALTER TABLE ad_stats TYPE=MERGE UNION=(ad_stats1,ad_stats2);
– TRUNCATE TABLE ad_stats0;
– ALTER TABLE ad_stats TYPE=MERGE UNION=(ad_stats0,ad_stats1,ad_stats2);
解決方案的另外一部分就是我們最常用的水平分割數據庫。把最常用的表分出去，單獨做集群，例如廣告啊，訂閱計算啊，
第七個(gè)問(wèn)題，問(wèn)題還真多，主數據庫服務(wù)器的單點(diǎn)問(wèn)題。雖然采用了Master-Slave模式，但主數據庫Master和Slave都只有一臺，當Master出問(wèn)題的時(shí)候需要太長(cháng)的時(shí)間進(jìn)行Myisam的修復，而Slave又無(wú)法很快的切換成為Master。FB試了好多辦法，最終的解決方案好像也不是非常完美。從他們的實(shí)驗過(guò)程來(lái)看，并沒(méi)有試驗Master-Master的結構，我想Live Journal的Master-Master方案對他們來(lái)說(shuō)應該有用，當然要實(shí)現Master-Master需要改應用，還有有些麻煩的。
第八個(gè)問(wèn)題，停電!芝加哥地區的供電狀況看來(lái)不是很好，不過(guò)不管好不好，做好備份是最重要的，大家各顯神通吧。
這個(gè)Presentation好像比較偏重數據庫，當然了，誰(shuí)讓這是在Mysql Con上的發(fā)言，不過(guò)總給人一種不過(guò)癮的感覺(jué)。另外一個(gè)感覺(jué)，FB的NO們一直在救火，沒(méi)有做系統的分析和設計。
最后FB的運維總監Joe Kottke給了四點(diǎn)建議：
1、 監控網(wǎng)站數據庫負載。
2、 “explain”所有的SQL語(yǔ)句。
3、 緩存所有能緩存的東西。
4、 歸檔好代碼。
最后，FB用到的軟件都不是最新的，夠用就好，包括：Tomcat5.0，Mysql 4.1，Hibernate 2.1，Spring，DBCP。
聯(lián)系客服
