摘要：系統(tǒng)擴(kuò)展一直是個(gè)讓人頭疼的事情，MatinKleppmann通過(guò)本文分享了他自己的6條經(jīng)驗(yàn)，外加網(wǎng)友的一條建議，這些經(jīng)驗(yàn)對(duì)于擴(kuò)展Twitter這樣規(guī)模的系統(tǒng)或許幫助不大，但是對(duì)于百萬(wàn)用戶級(jí)別的系統(tǒng)擴(kuò)展就另當(dāng)別論了。

【編者按】面對(duì)系統(tǒng)擴(kuò)展的難題，我們做過(guò)不少的經(jīng)驗(yàn)分享，學(xué)習(xí)別人的系統(tǒng)擴(kuò)展經(jīng)驗(yàn)可以讓我們少走很多彎路，今天給大家介紹的這篇文章來(lái)自High Scalability網(wǎng)站，MatinKleppmann針對(duì)百萬(wàn)用戶級(jí)別的系統(tǒng)擴(kuò)展，總結(jié)了幾條有用的經(jīng)驗(yàn)，當(dāng)然這些經(jīng)驗(yàn)對(duì)于像Twitter這樣規(guī)模的系統(tǒng)就不一定有用了。

---

CSDN推薦：歡迎免費(fèi)訂閱《Hadoop與大數(shù)據(jù)周刊》獲取更多Hadoop技術(shù)文獻(xiàn)、大數(shù)據(jù)技術(shù)分析、企業(yè)實(shí)戰(zhàn)經(jīng)驗(yàn)，生態(tài)圈發(fā)展趨勢(shì)。?

---

以下為原文：

系統(tǒng)擴(kuò)展一直是個(gè)讓人頭疼的事情，但系統(tǒng)擴(kuò)展過(guò)程中你是不是也經(jīng)常會(huì)產(chǎn)生一些新的想法？同樣，別人擴(kuò)展系統(tǒng)的經(jīng)驗(yàn)也一定會(huì)給你帶來(lái)很多幫助，MatinKleppmann通過(guò)本文分享了他自己的一些經(jīng)驗(yàn)。

這些經(jīng)驗(yàn)對(duì)于擴(kuò)展Twitter這樣規(guī)模的系統(tǒng)或許沒有什么幫助，但是針對(duì)百萬(wàn)用戶級(jí)別系統(tǒng)的擴(kuò)展（很多項(xiàng)目面臨這樣的難題），MatinKleppmann的經(jīng)驗(yàn)無(wú)疑會(huì)帶來(lái)很多幫助：

構(gòu)建可擴(kuò)展系統(tǒng)沒有什么樂趣可言，這是一個(gè)枯燥而又繁瑣的任務(wù)。雖然大量的工具已經(jīng)預(yù)先準(zhǔn)備好了，可現(xiàn)有的那些開源解決方案有著各種各樣缺點(diǎn)（當(dāng)然你自己的方案也不一定有多好，但至少能夠幫你解決特定的問題）。

在這里，MatinKleppmann分享了他的6個(gè)重要的系統(tǒng)擴(kuò)展經(jīng)驗(yàn)（外加網(wǎng)友的一條有用評(píng)論）：

1. 實(shí)際工作中的負(fù)載測(cè)試非常困難

負(fù)載測(cè)試需要讓系統(tǒng)承擔(dān)不同的工作量，有些工作量甚至超出了你現(xiàn)有的數(shù)據(jù)量水平，通過(guò)負(fù)載測(cè)試，評(píng)估系統(tǒng)在不同工作量條件下的性能，以及持續(xù)常態(tài)運(yùn)行的能力。具體還需要測(cè)試出系統(tǒng)的響應(yīng)速率、事務(wù)處理速率等參數(shù)。然而測(cè)試一個(gè)大型分布式系統(tǒng)和做科學(xué)實(shí)驗(yàn)不同，科學(xué)實(shí)驗(yàn)可以在理想條件下進(jìn)行，而負(fù)載測(cè)試則要難得多了，這對(duì)于搞計(jì)算機(jī)科學(xué)的人來(lái)說(shuō)可能很難接受。你很難知道你實(shí)際訪問的是怎樣的模式，很難測(cè)試比你實(shí)際擁有數(shù)據(jù)更大的綜合數(shù)據(jù)集，很難將舊系統(tǒng)與新系統(tǒng)進(jìn)行比較，所以為防新代碼出現(xiàn)錯(cuò)誤，你要隨時(shí)準(zhǔn)備好回滾。

2. 數(shù)據(jù)演變（data evolution）很困難

想象一下，你的機(jī)房被數(shù)據(jù)“淹沒”的情形，到處都是數(shù)據(jù)——數(shù)據(jù)庫(kù)中、日志中，以及一系列二進(jìn)制數(shù)據(jù)塊中。這時(shí)候如果要更新數(shù)據(jù)格式，你就需要改變一個(gè)巨大的時(shí)槽，而大公司在這些處理的自動(dòng)化和優(yōu)化上有著豐富的經(jīng)驗(yàn)，可以適當(dāng)借鑒大公司的數(shù)據(jù)演變經(jīng)驗(yàn)，節(jié)約數(shù)據(jù)演變的時(shí)間成本。

3. 數(shù)據(jù)庫(kù)連接是一個(gè)瓶頸

當(dāng)系統(tǒng)在服務(wù)和節(jié)點(diǎn)數(shù)增加時(shí)，數(shù)據(jù)庫(kù)連接數(shù)以難以置信的速度增加。每個(gè)連接都會(huì)消耗資源，不僅僅是機(jī)器資源，還有人力資源，因?yàn)槟愕拈_發(fā)人員需要去弄明白怎樣解決這些問題。通過(guò)使用連接池或者編寫數(shù)據(jù)訪問層，你可以通過(guò)API進(jìn)行數(shù)據(jù)庫(kù)訪問。

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

但讀取副本從主服務(wù)器中解除數(shù)據(jù)庫(kù)訪問也是一種常用的擴(kuò)展策略。同樣，這也需要花費(fèi)大量的精力來(lái)建立和維護(hù)這些系統(tǒng)，畢竟故障處理是一個(gè)始終存在的問題。

5. 考慮內(nèi)存效率

峰值延遲通常是由內(nèi)存問題引起的，想要更有效地利用RAM可能很困難，因?yàn)槟愫茈y判斷出RAM的實(shí)際使用情況。通過(guò)購(gòu)買更多的RAM可以解決很多性能問題，如果可能的話，可以在RAM中加入索引，注意是對(duì)字符串的哈希表建立索引，而不是針對(duì)字符串本身。

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

比如更改系統(tǒng)中的數(shù)據(jù)，這樣的更改必須通過(guò)許多服務(wù)，比如數(shù)據(jù)庫(kù)、搜索索引、圖、索引、副本讀取、緩存無(wú)效化。你可能認(rèn)為可以每次在應(yīng)用更新時(shí)將其寫到多個(gè)位置，但實(shí)際上很少這樣做。你也許認(rèn)為可以通過(guò)應(yīng)用程序讀取數(shù)據(jù)庫(kù)日志，但這對(duì)于有些系統(tǒng)是不可行的。更改捕獲系統(tǒng)是一個(gè)不錯(cuò)的解決方案，該系統(tǒng)捕獲所有寫操作并將它們存儲(chǔ)到數(shù)據(jù)庫(kù)中。應(yīng)用程序可以實(shí)時(shí)接收這些更新，它們會(huì)形成更改的歷史記錄。該方法的好處是將數(shù)據(jù)生產(chǎn)者和消費(fèi)者分開，這為你進(jìn)行實(shí)驗(yàn)提供了很大的方便，而不用去擔(dān)心對(duì)主要站點(diǎn)造成影響。

7. 針對(duì)高速緩存和緩存無(wú)效化（cache invalidation）

Mysteriousllama的一篇文章評(píng)論為我們提供了額外的經(jīng)驗(yàn)：如果沒有正確地緩存，又沒有有效的緩存失效策略，那數(shù)據(jù)庫(kù)就危險(xiǎn)了。使用Redis和Memcache來(lái)緩存可能出現(xiàn)的一切，而且要切記：不到萬(wàn)不得已，不要連接數(shù)據(jù)庫(kù)。確保你可以輕松使任何緩存無(wú)效化，保持事務(wù)原子性，避免系統(tǒng)在紊亂狀態(tài)下運(yùn)行。通過(guò)鎖定，以確保當(dāng)緩存無(wú)效時(shí)，數(shù)據(jù)庫(kù)不會(huì)堆滿同一查詢的多個(gè)副本。你或許會(huì)認(rèn)為選擇數(shù)據(jù)庫(kù)中的查詢緩存可能同樣有效，但相信我，這不太可能。當(dāng)然，除了緩存簡(jiǎn)單的查詢，你還可以緩存更高級(jí)別的對(duì)象。

根據(jù)你對(duì)可靠性的要求，你還可能會(huì)考慮將緩存用作回寫和數(shù)據(jù)庫(kù)后臺(tái)的批處理寫入。由于多種因素的影響，這一般都要比單個(gè)寫入效率更高，許多大型網(wǎng)站都將這作為它們進(jìn)行系統(tǒng)擴(kuò)展的常用策略。

原文鏈接： Six Lessons Learned The Hard Way About Scaling A Million User System?

總結(jié)

以上是生活随笔為你收集整理的百万用户规模的系统如何扩展的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。