系統擴展一直是個讓人頭疼的事情，MatinKleppmann通過本文分享了他自己的6條經驗，外加網友的一條建議，這些經驗對于擴展Twitter這樣規模的系統或許幫助不大，但是對于百萬用戶級別的系統擴展就另當別論了。

【編者按】面對系統擴展的難題，我們做過不少的經驗分享，學習別人的系統擴展經驗可以讓我們少走很多彎路，今天給大家介紹的這篇文章來自High Scalability網站，MatinKleppmann針對百萬用戶級別的系統擴展，總結了幾條有用的經驗，當然這些經驗對于像Twitter這樣規模的系統就不一定有用了。

以下為原文：

系統擴展一直是個讓人頭疼的事情，但系統擴展過程中你是不是也經常會產生一些新的想法？同樣，別人擴展系統的經驗也一定會給你帶來很多幫助，MatinKleppmann通過本文分享了他自己的一些經驗。

這些經驗對于擴展Twitter這樣規模的系統或許沒有什么幫助，但是針對百萬用戶級別系統的擴展（很多項目面臨這樣的難題），MatinKleppmann的經驗無疑會帶來很多幫助：

構建可擴展系統沒有什么樂趣可言，這是一個枯燥而又繁瑣的任務。雖然大量的工具已經預先準備好了，可現有的那些開源解決方案有著各種各樣缺點（當然你自己的方案也不一定有多好，但至少能夠幫你解決特定的問題）。

在這里，MatinKleppmann分享了他的6個重要的系統擴展經驗（外加網友的一條有用評論）：

1. 實際工作中的負載測試非常困難

負載測試需要讓系統承擔不同的工作量，有些工作量甚至超出了你現有的數據量水平，通過負載測試，評估系統在不同工作量條件下的性能，以及持續常態運行的能力。具體還需要測試出系統的響應速率、事務處理速率等參數。然而測試一個大型分布式系統和做科學實驗不同，科學實驗可以在理想條件下進行，而負載測試則要難得多了，這對于搞計算機科學的人來說可能很難接受。你很難知道你實際訪問的是怎樣的模式，很難測試比你實際擁有數據更大的綜合數據集，很難將舊系統與新系統進行比較，所以為防新代碼出現錯誤，你要隨時準備好回滾。

2. 數據演變（data evolution）很困難

想象一下，你的機房被數據“淹沒”的情形，到處都是數據——數據庫中、日志中，以及一系列二進制數據塊中。這時候如果要更新數據格式，你就需要改變一個巨大的時槽，而大公司在這些處理的自動化和優化上有著豐富的經驗，可以適當借鑒大公司的數據演變經驗，節約數據演變的時間成本。

3. 數據庫連接是一個瓶頸

當系統在服務和節點數增加時，數據庫連接數以難以置信的速度增加。每個連接都會消耗資源，不僅僅是機器資源，還有人力資源，因為你的開發人員需要去弄明白怎樣解決這些問題。通過使用連接池或者編寫數據訪問層，你可以通過API進行數據庫訪問。

4. 讀取副本是一步痛苦的操作

但讀取副本從主服務器中解除數據庫訪問也是一種常用的擴展策略。同樣，這也需要花費大量的精力來建立和維護這些系統，畢竟故障處理是一個始終存在的問題。

5. 考慮內存效率

峰值延遲通常是由內存問題引起的，想要更有效地利用RAM可能很困難，因為你很難判斷出RAM的實際使用情況。通過購買更多的RAM可以解決很多性能問題，如果可能的話，可以在RAM中加入索引，注意是對字符串的哈希表建立索引，而不是針對字符串本身。

6. 更改捕獲（change capture）是一個有效的方法

比如更改系統中的數據，這樣的更改必須通過許多服務，比如數據庫、搜索索引、圖、索引、副本讀取、緩存無效化。你可能認為可以每次在應用更新時將其寫到多個位置，但實際上很少這樣做。你也許認為可以通過應用程序讀取數據庫日志，但這對于有些系統是不可行的。更改捕獲系統是一個不錯的解決方案，該系統捕獲所有寫操作并將它們存儲到數據庫中。應用程序可以實時接收這些更新，它們會形成更改的歷史記錄。該方法的好處是將數據生產者和消費者分開，這為你進行實驗提供了很大的方便，而不用去擔心對主要站點造成影響。

7. 針對高速緩存和緩存無效化（cache invalidation）

Mysteriousllama的一篇文章評論為我們提供了額外的經驗：如果沒有正確地緩存，又沒有有效的緩存失效策略，那數據庫就危險了。使用Redis和Memcache來緩存可能出現的一切，而且要切記：不到萬不得已，不要連接數據庫。確保你可以輕松使任何緩存無效化，保持事務原子性，避免系統在紊亂狀態下運行。通過鎖定，以確保當緩存無效時，數據庫不會堆滿同一查詢的多個副本。你或許會認為選擇數據庫中的查詢緩存可能同樣有效，但相信我，這不太可能。當然，除了緩存簡單的查詢，你還可以緩存更高級別的對象。

根據你對可靠性的要求，你還可能會考慮將緩存用作回寫和數據庫后臺的批處理寫入。由于多種因素的影響，這一般都要比單個寫入效率更高，許多大型網站都將這作為它們進行系統擴展的常用策略。