出處：
摘要：本文作者曾負責dropbox的擴充套件性工作，經歷了使用者數從4,000到40,000,000的激增。在那段難忘的時光裡，作者和他的三名同事共同工作在後端。本文作者就擴充套件性，尤其是在乙個資源受限的快速增長環境中處理問題的心得。
本文作者曾負責dropbox的擴充套件性工作，經歷了使用者數從4,000到40,000,000的激增。在那段難忘的時光裡，作者和他的三名同事共同工作在後端。本文作者就擴充套件性，尤其是在乙個資源受限的快速增長環境中處理問題的心得。
我們經常使用的一種技術就是人工模擬站點的負荷。例如，我們經常模擬大量的超過常規的快取讀取。一旦快取出現故障，我們可以快速地切換重複查詢，並為提出解決方案贏得時間。為什麼不未雨綢繆呢？這是因為許多故障是突然的，我們幾乎無法檢測到。
這種解決方案並不完美。我們只是模擬了高負荷的讀操作，大量的讀負載可能會導致出現意外的問題，寫負載又很難模擬（資料風險，索爭用的問題）。但通過我們的經驗，額外的讀取操作已經足夠贏得時間了。
以圖表展現效能指標
通過數以萬計的伺服器圖形處理器聚合的自定義資料圖表變得越來越有用。現成的監控解決方案並不能處理這種型別的負載，我們想以行的方式新增資料，作為我們的統計方法。
我們採用memcached、crom和ganglia的組合實現了我們的監控解決方案。我們希望將所有發生的事件都以圖形的方式表現出來，每次事件都會儲存在本地執行緒的記憶體緩衝區中。每秒鐘，我們都會將資料匯集到快取中；每分鐘，我們都會將資料匯集到**伺服器上，並提交ganglia處理。這非常具有擴充套件性，使得我們可以實時處理數以千計的狀態資料。
下面是乙個彙總圖表的示例：
折線代表站點的平均響應時間，每段代表工作的時間間隔。大約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的社群支援也更強大，谷歌、雅虎和facebook都為mysql寫過補丁。
我們使用sqlalchemy作為自己的orm。其實我個人很討厭orm，因為它們總是會引發錯誤。使用它們並不必要，mysql的效能堅如磐石。
使用之前先進行模擬分析
後端工程相當龐大複雜，對於不同的產品，我們想發揮它們的優勢。所以，在實施之前，一定要進行模擬測試。
安全與便捷的權衡
安全非常重要，因為dropbox儲存了每個人的私人文件。服務各不相同，安全設定會影響到每個人，程式設計師或普通使用者。
例如，幾乎任何**登入時都會提示輸入使用者名稱和密碼，但如果輸入錯誤，它會提示錯誤，但不會告訴我們具體是哪乙個。這是乙個很好的安全策略，但如果作為使用者忘記了是使用哪乙個使用者名稱註冊的**，也許會因此如坐針氈。（張志平/編譯）
CSS可擴充套件性
今日在寫pc官網的時候，一直對於html css的結構編寫完全按照自己的思維方式，今天把 交給老大的時候，被他指出很多編寫 的錯誤性，比如 結構，標籤的使用，語義化，css的可擴充套件性，由於 主要還是需要做seo優化，所以在標籤使用上也有些不合理之處，給了我一些建議，自己記錄以下 1 在html標...
Flume的可擴充套件性
flume的可擴充套件性 flume採用了三層架構，分別為agent，collector和storage，每一層均可以水平擴充套件。其中，所有agent和 collector由master統一管理，這使得系統容易監控和維護，且master允許有多個 使用zookeeper進行管理和負載均衡 這就避 ...
Flume的可擴充套件性
flume的可擴充套件性 flume採用了三層架構，分別為agent，collector和storage，每一層均可以水平擴充套件。其中，所有agent和 collector由master統一管理，這使得系統容易監控和維護，且master允許有多個 使用zookeeper進行管理和負載均衡 這就避 ...