系統(tǒng)擴(kuò)展一直是個讓人頭疼的事情，MatinKleppmann通過本文分享了他自己的6條經(jīng)驗(yàn)，外加網(wǎng)友的一條建議，這些經(jīng)驗(yàn)對于擴(kuò)展Twitter這樣規(guī)模的系統(tǒng)或許幫助不大，但是對于百萬用戶級別的系統(tǒng)擴(kuò)展就另當(dāng)別論了。
【編者按】面對系統(tǒng)擴(kuò)展的難題，我們做過不少的經(jīng)驗(yàn)分享，學(xué)習(xí)別人的系統(tǒng)擴(kuò)展經(jīng)驗(yàn)可以讓我們少走很多彎路，今天給大家介紹的這篇文章來自High Scalability網(wǎng)站，MatinKleppmann針對百萬用戶級別的系統(tǒng)擴(kuò)展，總結(jié)了幾條有用的經(jīng)驗(yàn)，當(dāng)然這些經(jīng)驗(yàn)對于像Twitter這樣規(guī)模的系統(tǒng)就不一定有用了。
以下為原文：
系統(tǒng)擴(kuò)展一直是個讓人頭疼的事情，但系統(tǒng)擴(kuò)展過程中你是不是也經(jīng)常會產(chǎn)生一些新的想法？同樣，別人擴(kuò)展系統(tǒng)的經(jīng)驗(yàn)也一定會給你帶來很多幫助，MatinKleppmann通過本文分享了他自己的一些經(jīng)驗(yàn)。
這些經(jīng)驗(yàn)對于擴(kuò)展Twitter這樣規(guī)模的系統(tǒng)或許沒有什么幫助，但是針對百萬用戶級別系統(tǒng)的擴(kuò)展（很多項(xiàng)目面臨這樣的難題），MatinKleppmann的經(jīng)驗(yàn)無疑會帶來很多幫助：
構(gòu)建可擴(kuò)展系統(tǒng)沒有什么樂趣可言，這是一個枯燥而又繁瑣的任務(wù)。雖然大量的工具已經(jīng)預(yù)先準(zhǔn)備好了，可現(xiàn)有的那些開源解決方案有著各種各樣缺點(diǎn)（當(dāng)然你自己的方案也不一定有多好，但至少能夠幫你解決特定的問題）。
在這里，MatinKleppmann分享了他的6個重要的系統(tǒng)擴(kuò)展經(jīng)驗(yàn)（外加網(wǎng)友的一條有用評論）：
1. 實(shí)際工作中的負(fù)載測試非常困難
負(fù)載測試需要讓系統(tǒng)承擔(dān)不同的工作量，有些工作量甚至超出了你現(xiàn)有的數(shù)據(jù)量水平，通過負(fù)載測試，評估系統(tǒng)在不同工作量條件下的性能，以及持續(xù)常態(tài)運(yùn)行的能力。具體還需要測試出系統(tǒng)的響應(yīng)速率、事務(wù)處理速率等參數(shù)。然而測試一個大型分布式系統(tǒng)和做科學(xué)實(shí)驗(yàn)不同，科學(xué)實(shí)驗(yàn)可以在理想條件下進(jìn)行，而負(fù)載測試則要難得多了，這對于搞計(jì)算機(jī)科學(xué)的人來說可能很難接受。你很難知道你實(shí)際訪問的是怎樣的模式，很難測試比你實(shí)際擁有數(shù)據(jù)更大的綜合數(shù)據(jù)集，很難將舊系統(tǒng)與新系統(tǒng)進(jìn)行比較，所以為防新代碼出現(xiàn)錯誤，你要隨時(shí)準(zhǔn)備好回滾。
2. 數(shù)據(jù)演變（data evolution）很困難
想象一下，你的機(jī)房被數(shù)據(jù)“淹沒”的情形，到處都是數(shù)據(jù)——數(shù)據(jù)庫中、日志中，以及一系列二進(jìn)制數(shù)據(jù)塊中。這時(shí)候如果要更新數(shù)據(jù)格式，你就需要改變一個巨大的時(shí)槽，而大公司在這些處理的自動化和優(yōu)化上有著豐富的經(jīng)驗(yàn)，可以適當(dāng)借鑒大公司的數(shù)據(jù)演變經(jīng)驗(yàn)，節(jié)約數(shù)據(jù)演變的時(shí)間成本。
3. 數(shù)據(jù)庫連接是一個瓶頸
當(dāng)系統(tǒng)在服務(wù)和節(jié)點(diǎn)數(shù)增加時(shí)，數(shù)據(jù)庫連接數(shù)以難以置信的速度增加。每個連接都會消耗資源，不僅僅是機(jī)器資源，還有人力資源，因?yàn)槟愕拈_發(fā)人員需要去弄明白怎樣解決這些問題。通過使用連接池或者編寫數(shù)據(jù)訪問層，你可以通過API進(jìn)行數(shù)據(jù)庫訪問。
4. 讀取副本是一步痛苦的操作
但讀取副本從主服務(wù)器中解除數(shù)據(jù)庫訪問也是一種常用的擴(kuò)展策略。同樣，這也需要花費(fèi)大量的精力來建立和維護(hù)這些系統(tǒng)，畢竟故障處理是一個始終存在的問題。
5. 考慮內(nèi)存效率
峰值延遲通常是由內(nèi)存問題引起的，想要更有效地利用RAM可能很困難，因?yàn)槟愫茈y判斷出RAM的實(shí)際使用情況。通過購買更多的RAM可以解決很多性能問題，如果可能的話，可以在RAM中加入索引，注意是對字符串的哈希表建立索引，而不是針對字符串本身。
6. 更改捕獲（change capture）是一個有效的方法
比如更改系統(tǒng)中的數(shù)據(jù)，這樣的更改必須通過許多服務(wù)，比如數(shù)據(jù)庫、搜索索引、圖、索引、副本讀取、緩存無效化。你可能認(rèn)為可以每次在應(yīng)用更新時(shí)將其寫到多個位置，但實(shí)際上很少這樣做。你也許認(rèn)為可以通過應(yīng)用程序讀取數(shù)據(jù)庫日志，但這對于有些系統(tǒng)是不可行的。更改捕獲系統(tǒng)是一個不錯的解決方案，該系統(tǒng)捕獲所有寫操作并將它們存儲到數(shù)據(jù)庫中。應(yīng)用程序可以實(shí)時(shí)接收這些更新，它們會形成更改的歷史記錄。該方法的好處是將數(shù)據(jù)生產(chǎn)者和消費(fèi)者分開，這為你進(jìn)行實(shí)驗(yàn)提供了很大的方便，而不用去擔(dān)心對主要站點(diǎn)造成影響。
7. 針對高速緩存和緩存無效化（cache invalidation）
Mysteriousllama的一篇文章評論為我們提供了額外的經(jīng)驗(yàn)：如果沒有正確地緩存，又沒有有效的緩存失效策略，那數(shù)據(jù)庫就危險(xiǎn)了。使用Redis和Memcache來緩存可能出現(xiàn)的一切，而且要切記：不到萬不得已，不要連接數(shù)據(jù)庫。確保你可以輕松使任何緩存無效化，保持事務(wù)原子性，避免系統(tǒng)在紊亂狀態(tài)下運(yùn)行。通過鎖定，以確保當(dāng)緩存無效時(shí)，數(shù)據(jù)庫不會堆滿同一查詢的多個副本。你或許會認(rèn)為選擇數(shù)據(jù)庫中的查詢緩存可能同樣有效，但相信我，這不太可能。當(dāng)然，除了緩存簡單的查詢，你還可以緩存更高級別的對象。
根據(jù)你對可靠性的要求，你還可能會考慮將緩存用作回寫和數(shù)據(jù)庫后臺的批處理寫入。由于多種因素的影響，這一般都要比單個寫入效率更高，許多大型網(wǎng)站都將這作為它們進(jìn)行系統(tǒng)擴(kuò)展的常用策略。