FeedBurner:基于MySQL和JAVA的可擴展Web應用

于敦德 2006-6-27

FeedBurner（以下簡稱FB，呵呵）我想應該是大家耳熟能詳的一個名字，在國內我們有一個同樣的服務商，叫做FeedSky。在2004年7月份，FB的流量是300kbps，托管是5600個源，到2005年4月份，流量已經增長到5Mbps，托管了47700個源；到 2005年9月份流量增長到20M，托管了109200個源，而到2006年4月份，流量已經到了115Mbps，270000個源，每天點擊量一億次。

FB的服務使用Java實現，使用了Mysql數據庫。我們下面來看一下FB在發展的過程中碰到的問題，以及解決的方案。

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

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

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

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

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

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

– FLUSH TABLES; TRUNCATE TABLE ad_stats0;

這樣的操作對Master數據庫是成功的，但對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);

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

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

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

這個Presentation好像比較偏重數據庫，當然了，誰讓這是在Mysql Con上的發言，不過總給人一種不過癮的感覺。另外一個感覺，FB的NO們一直在救火，沒有做系統的分析和設計。

最后FB的運維總監Joe Kottke給了四點建議：

1、 監控網站數據庫負載。

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

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

4、 歸檔好代碼。

最后，FB用到的軟件都不是最新的，夠用就好，包括：Tomcat5.0，Mysql 4.1，Hibernate 2.1，Spring，DBCP。

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