FeedBurner:基于MySQL和JAVA的可擴展Web應(yīng)用

于敦德 2006-6-27

FeedBurner（以下簡稱FB，呵呵）我想應(yīng)該是大家耳熟能詳?shù)囊粋€名字，在國內(nèi)我們有一個同樣的服務(wù)商，叫做FeedSky。在2004年7月份，F(xiàn)B的流量是300kbps，托管是5600個源，到2005年4月份，流量已經(jīng)增長到5Mbps，托管了47700個源；到 2005年9月份流量增長到20M，托管了109200個源，而到2006年4月份，流量已經(jīng)到了115Mbps，270000個源，每天點擊量一億次。

FB的服務(wù)使用Java實現(xiàn)，使用了Mysql數(shù)據(jù)庫。我們下面來看一下FB在發(fā)展的過程中碰到的問題，以及解決的方案。

在2004年8月份，F(xiàn)B的硬件設(shè)備包括3臺Web服務(wù)器，3臺應(yīng)用服務(wù)器和兩臺數(shù)據(jù)庫服務(wù)器，使用DNS輪循分布服務(wù)負載，將前端請求分布到三臺 Web服務(wù)器上。說實話，如果不考慮穩(wěn)定性，給5600個源提供服務(wù)應(yīng)該用不了這么多服務(wù)器。現(xiàn)在的問題是即使用了這么多服務(wù)器他們還是無法避免單點問題，單點問題將至少影響到1/3的用戶。FB采用了監(jiān)控的辦法來解決，當監(jiān)控到有問題出現(xiàn)時及時重啟來避免更多用戶受到影響。FB采用了Cacti(http://www.cacti.net)和Nagios(http://www.nagios.org)來做監(jiān)控。

FB碰到的第二個問題是訪問統(tǒng)計和管理。可以想象，每當我們在RSS閱讀器里點擊FB發(fā)布的內(nèi)容，都需要做實時的統(tǒng)計，這個工作量是多么的巨大。大量寫操作將導致系統(tǒng)的效率急劇下降，如果是Myisam表的話還會導致表的死鎖。FB一方面采用異步寫入機制，通過創(chuàng)建執(zhí)行池來緩沖寫操作；只對本日的數(shù)據(jù)進行實時統(tǒng)計，而以前的數(shù)據(jù)以統(tǒng)計結(jié)果形式存儲，進而避免每次查看訪問統(tǒng)計時的重復計算。所以每一天第一次訪問統(tǒng)計信息時速度可能會慢，這個時候應(yīng)該是 FB在分析整理前一天的數(shù)據(jù)，而接下來的訪問由于只針對當日數(shù)據(jù)進行分析，數(shù)據(jù)量小很多，當然也會快很多。FB的Presentation是這樣寫，但我發(fā)現(xiàn)好像我的FB里并沒有今天實時的統(tǒng)計，也許是我觀察的不夠仔細-_-!

現(xiàn)在第三個問題出現(xiàn)了，由于大多數(shù)的操作都集中在主數(shù)據(jù)庫上，數(shù)據(jù)庫服務(wù)器的讀寫出現(xiàn)了沖突，前面提到過Myiasm類型的數(shù)據(jù)庫在寫入的時候會鎖表，這樣就導致了讀寫的沖突。在開始的時候由于讀寫操作比較少這個問題可能并不明顯，但現(xiàn)在已經(jīng)到了不能忽視的程度。解決方案是平衡讀寫的負載，以及擴展 HibernateDaoSupport，區(qū)分只讀與讀寫操作，以實現(xiàn)針對讀寫操作的不同處理。

現(xiàn)在是第四個問題：數(shù)據(jù)庫全面負載過高。由于使用數(shù)據(jù)庫做為緩存，同時數(shù)據(jù)庫被所有的應(yīng)用服務(wù)器共享，速度越來越慢，而這時數(shù)據(jù)庫大小也到了 Myisam的上限-4GB，F(xiàn)B的同學們自己都覺得自己有點懶?。解決方案是使用內(nèi)存做緩存，而非數(shù)據(jù)庫，他們同樣使用了我們前面推薦的 memcached，同時他們還使用了Ehcache(http://ehcache.sourceforge.net/)，一款基于Java的分布式緩存工具。

第五個問題：流行rss源帶來大量重復請求，導致系統(tǒng)待處理請求的堆積。同時我們注意到在RSS源小圖標有時候會顯示有多少用戶訂閱了這一RSS 源，這同樣需要服務(wù)器去處理，而目前所有的訂閱數(shù)都在同一時間進行計算，導致對系統(tǒng)資源的大量占用。解決方案，把計算時間錯開，同時在晚間處理堆積下來的請求，但這仍然不夠。

問題六：狀態(tài)統(tǒng)計寫入數(shù)據(jù)庫又一次出問題了。越來越多的輔助數(shù)據(jù)（包括廣告統(tǒng)計，文章點擊統(tǒng)計，訂閱統(tǒng)計）需要寫入數(shù)據(jù)庫，導致太多的寫操作。解決方案：每天晚上處理完堆積下來的請求后對子表進行截斷操作：

– FLUSH TABLES; TRUNCATE TABLE ad_stats0;

這樣的操作對Master數(shù)據(jù)庫是成功的，但對Slave會失敗，正確的截斷子表方法是：

– 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);

解決方案的另外一部分就是我們最常用的水平分割數(shù)據(jù)庫。把最常用的表分出去，單獨做集群，例如廣告啊，訂閱計算啊，

第七個問題，問題還真多，主數(shù)據(jù)庫服務(wù)器的單點問題。雖然采用了Master-Slave模式，但主數(shù)據(jù)庫Master和Slave都只有一臺，當 Master出問題的時候需要太長的時間進行Myisam的修復，而Slave又無法很快的切換成為Master。FB試了好多辦法，最終的解決方案好像也不是非常完美。從他們的實驗過程來看，并沒有試驗Master-Master的結(jié)構(gòu)，我想Live Journal的Master-Master方案對他們來說應(yīng)該有用，當然要實現(xiàn)Master-Master需要改應(yīng)用，還有有些麻煩的。

第八個問題，停電!芝加哥地區(qū)的供電狀況看來不是很好，不過不管好不好，做好備份是最重要的，大家各顯神通吧。

這個Presentation好像比較偏重數(shù)據(jù)庫，當然了，誰讓這是在Mysql Con上的發(fā)言，不過總給人一種不過癮的感覺。另外一個感覺，F(xiàn)B的NO們一直在救火，沒有做系統(tǒng)的分析和設(shè)計。

最后FB的運維總監(jiān)Joe Kottke給了四點建議：

1、 監(jiān)控網(wǎng)站數(shù)據(jù)庫負載。

2、 “explain”所有的SQL語句。

3、 緩存所有能緩存的東西。

4、 歸檔好代碼。

最后，F(xiàn)B用到的軟件都不是最新的，夠用就好，包括：Tomcat5.0，Mysql 4.1，Hibernate 2.1，Spring，DBCP。

文章參考了Joe Kottke在MySQL Users Conference 2006上的發(fā)言。