來自 Dropbox 的可擴展性設計經驗

jopen 12年前發布 | 27K 次閱讀 Dropbox

導讀:本文作者曾負責Dropbox的擴展性工作,經歷了用戶數從4,000到40,000,000的激增。在那段難忘的時光里,作者和他的三名同事共同工作在后端。本文作者就擴展性,尤其是在一個資源受限的快速增長環境中處理問題的心得。

我們經常使用的一種技術就是人工模擬站點的負荷。例如,我們經常模擬大量的超過常規的緩存讀取。一旦緩存出現故障,我們可以快速地切換重復查詢,并為提出解決方案贏得時間。為什么不未雨綢繆呢?這是因為許多故障是突然的,我們幾乎無法檢測到。

這種解決方案并不完美。我們只是模擬了高負荷的讀操作,大量的讀負載可能會導致出現意外的問題,寫負載又很難模擬(數據風險,索爭用的問題)。但通過我們的經驗,額外的讀取操作已經足夠贏得時間了。

以圖表展現性能指標

通過數以萬計的服務器圖形處理器聚合的自定義數據圖表變得越來越有用。現成的監控解決方案并不能處理這種類型的負載,我們想以行的方式添加數據,作為我們的統計方法。

我們采用memcached、crom和ganglia的組合實現了我們的監控 解決方案。我們希望將所有發生的事件都以圖形的方式表現出來,每次事件都會存儲在本地線程的內存緩沖區中。每秒鐘,我們都會將數據匯集到緩存中;每分鐘, 我們都會將數據匯集到中央服務器上,并提交ganglia處理。這非常具有擴展性,使得我們可以實時處理數以千計的狀態數據。

下面是一個匯總圖表的示例:

來自 Dropbox 的可擴展性設計經驗

折線代表站點的平均響應時間,每段代表工作的時間間隔。大約1點左右,折線有一個波峰,這是MySQL提交造成的。我們的圖形數據還可以體現更多的信息,這便于我們直觀地發現問題。

用Bash進行數據分析

也許你還沒有使用Shell,不太了解Shell是如何快速執行任務(借助Perl這樣的編程語言)。比如說,我們想監控Web服務器。但是Web服務器的日志相當龐大,以分鐘為單位的日志檢索不能提供足夠的細粒度。

Apr 8 2012 14:33:59 POST ...

Apr 8 2012 14:34:00 GET ...

Apr 8 2012 14:34:00 GET ...

Apr 8 2012 14:34:01 POST ...

我們可以這樣運用Shell:

cut -d ' ' -f1-4 log.txt | xargs -L1 -I_ date +%s -d_ | uniq -c | (echo "plot '-' using 2:1 with lines"; cat) | gnuplot 

我們很快就會得到運行狀態的漂亮圖表,而且非常易于定制。如果你不熟悉命令行工具,推薦你了解一下以下命令:

sed,awk,grep,cut,head,tail,sort,uniq,tr,date,xargs

垃圾日志也有它的用處

垃圾日志并非全無作用。雖然我們非常討厭冗繁、龐雜的日志,但這也許是跟蹤代碼的方式。所以當我刪除很長一段時間間隔的日志之后,當我發現它的價值,也曾倍感后悔。

故障轉移測試

如果有失敗的可能性,那么就要對故障轉移進行測試。進行故障轉移時請注意:

從上次故障轉移群集之后增加的負載可能會導致這次故障轉移群集的級聯效應;從上次故障轉移群集之后增加的腳本可能需要舊的依賴資源才能正常運行。

最后在故障未發生之前進行故障轉移測試,這就像消防演練一樣。

保持同質化的重要性

保持同質化對數據非常重要。我曾經有兩個用戶數據切片,隨著它們的增長,我需要以新的數據切片予以替代,但令人頭疼的是,它們的增長速度并不相同。

同質化對于硬件也同樣非常重要,這可以簡化容量規劃。最佳的方式就是保持盡可能少的服務器類型。

保留停機日志

每次站點關閉,都要記錄好停機的時間,并將故障原因標注清楚。日后,我們可以根據記錄進行分析,提出更好的應對方案,以盡可能減少停機時間。

UTC

讓一切運行在UTC之下。保證服務器與數據庫遵循UTC時間,可以了卻許多令我們頭疼的問題。

我們使用的技術

我們采用了如下軟件技術:

1.Python/C

2.MySQL

3.Paster/Pylons/Cheetah(Web框架)

4.S3/EC2用于文件存儲

5.服務器前端和服務器間協調處理采用緩存技術

6.Ganglia用作圖形處理

7.Nginx作為前端服務器

8.Haproxy在Nginx之后為應用服務器提供負載均衡

9.Nagios作為內部安全監控

10.Pingdom作為外部服務監控

11.GeoIP映射IP地址

以上選擇都遵循了相同的原則,簡單可靠。選擇MySQL而不選擇PostgreSQL,是因為當時PostgreSQL對復制的支持并不夠好,而且在網絡上來自MySQL的社區支持也更強大,谷歌、雅虎和非死book都為MySQL寫過補丁。

我們使用SQLAlchemy作為自己的ORM。其實我個人很討厭ORM,因為它們總是會引發錯誤。使用它們并不必要,MySQL的性能堅如磐石。

使用之前先進行模擬分析

后端工程相當龐大復雜,對于不同的產品,我們想發揮它們的優勢。所以,在實施之前,一定要進行模擬測試。

安全與便捷的權衡

安全非常重要,因為Dropbox保存了每個人的私人文檔。服務各不相同,安全設置會影響到每個人,程序員或普通用戶。

例如,幾乎任何網站登錄時都會提示輸入用戶名和密碼,但如果輸入錯誤,它會提示錯誤,但不會告訴我們具體是哪一個。這是一個很好的安全策略,但如果作為用戶忘記了是使用哪一個用戶名注冊的網站,也許會因此如坐針氈。(張志平/編譯)

原文鏈接:Scaling lessons learned at Dropbox, part 1
中文翻譯:http://cloud.csdn.net/a/20120718/2807466.html

 本文由用戶 jopen 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
 轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!