摘要：容量和可擴(kuò)展性并不依賴于性能。容量是車道乘以最大安全時(shí)速。至此，關(guān)于擴(kuò)展性的概念描述告一段落。但現(xiàn)實(shí)是誒，小九啊，咱們系統(tǒng)提升下性能要多久啊三天應(yīng)該差不多了吧，最多不能超過(guò)一周，上次提升性能，小六一天就搞定了的。

我們應(yīng)該接觸過(guò)或者聽說(shuō)過(guò)數(shù)據(jù)庫(kù)的性能瓶頸問(wèn)題。對(duì)于一個(gè)單機(jī)應(yīng)用而言，提升數(shù)據(jù)庫(kù)性能的最快路徑就是氪金 - 買更高性能的數(shù)據(jù)庫(kù)服務(wù)器，只要錢到位，性能不是問(wèn)題。

但是當(dāng)系統(tǒng)性能增加到一定地步時(shí)，你會(huì)發(fā)現(xiàn)，原先花 3000 塊提升了 50% 的性能，現(xiàn)在花 30000 塊，才提升了不到 10%。

也就是說(shuō)，我們花了錢，但沒有得到等價(jià)的性能提升，這個(gè)時(shí)候，我們就要考慮數(shù)據(jù)庫(kù)的可擴(kuò)展性了。

要討論 MySQL 的可擴(kuò)展性，就要先明確可擴(kuò)展性的定義。在此之前，我們先拋開 MySQL，專注于擴(kuò)展性，搞清楚什么是擴(kuò)展性，才能更有針對(duì)性的去提升數(shù)據(jù)庫(kù)的擴(kuò)展性。

我們常常把“可擴(kuò)展性”、“高可用性”以及“性能”用作同義詞，但事實(shí)上它們是完全不同的。簡(jiǎn)單來(lái)說(shuō)，性能是響應(yīng)時(shí)間，可用性是宕機(jī)時(shí)間，而擴(kuò)展性表明了當(dāng)需要增加資源以執(zhí)行更多工作時(shí)，系統(tǒng)能夠獲得等價(jià)的性能提升的能力。換種說(shuō)法，可擴(kuò)展性就是我們能夠盡可能的花費(fèi)相同的資源提升等價(jià)的性能。而缺乏擴(kuò)展能力的系統(tǒng)在達(dá)到收益遞減的轉(zhuǎn)折點(diǎn)后，將無(wú)法進(jìn)一步增長(zhǎng)。

容量是一個(gè)和可擴(kuò)展性相關(guān)的概念。系統(tǒng)容量表示在一定時(shí)間內(nèi)能夠完成的工作量。

容量和可擴(kuò)展性并不依賴于性能。以高速公路上的汽車來(lái)類比的話：

性能是汽車的時(shí)速。

容量是車道乘以最大安全時(shí)速。

可擴(kuò)展性就是在不減慢交通的情況下，能增加更多車和車道的程度。

在上面這個(gè)類比中，可擴(kuò)展性依賴多個(gè)條件：換道設(shè)計(jì)是否合理、路上有多少車拋錨或發(fā)生事故、汽車行駛速度不同以及是否頻繁變換車道。但一般來(lái)說(shuō)，和汽車的引擎是否強(qiáng)大無(wú)關(guān)。

這并不是說(shuō)性能不重要，性能確實(shí)重要，只是要注意的是，即使系統(tǒng)性能不是很高的系統(tǒng)也可以具備可擴(kuò)展性。

從較高層次看，可擴(kuò)展性就是能夠通過(guò)增加資源來(lái)提升容量的能力。

對(duì)于容量，我們可以簡(jiǎn)單的認(rèn)為是處理負(fù)載的能力，而從不同的角度考慮負(fù)載對(duì)我們優(yōu)化擴(kuò)展性很有幫助。

數(shù)據(jù)量

應(yīng)用所能累計(jì)的數(shù)據(jù)量是可擴(kuò)展性最普遍的挑戰(zhàn)，特別是對(duì)于現(xiàn)在的互聯(lián)網(wǎng)應(yīng)用而言，因?yàn)閺牟粍h除數(shù)據(jù)。

用戶量

首先，即使每個(gè)用戶只有少量的數(shù)據(jù)，但在累計(jì)到一定數(shù)量的用戶后，數(shù)據(jù)量也會(huì)開始不成比例的增長(zhǎng)，且速度快過(guò)用戶數(shù)增長(zhǎng)。其次，更多的用戶意味著要處理更多的事務(wù)，并且事務(wù)數(shù)可能和用戶數(shù)不成比例。最后，大量用戶也意味著更多復(fù)雜的查詢。

用戶活躍度

不是所有的用戶活躍度都相同，并且用戶活躍度也不總是不變的。如果用戶突然變得活躍，例如 github 給小團(tuán)隊(duì)免費(fèi)開放了私有化倉(cāng)庫(kù)，那么其對(duì)應(yīng)的負(fù)載可能會(huì)明顯提升。要注意的是，用戶活躍度不僅僅指頁(yè)面瀏覽數(shù)（PV），即使同樣的 PV，如果網(wǎng)站的某個(gè)需要執(zhí)行大量查詢工作的功能變得更受歡迎，也可能導(dǎo)致更多的工作。

相關(guān)數(shù)據(jù)集的大小

如果用戶間存在關(guān)系，應(yīng)用可能需要在整個(gè)相關(guān)聯(lián)用戶群體上執(zhí)行查詢和計(jì)算，這比處理一個(gè)個(gè)的用戶和用戶數(shù)據(jù)要復(fù)雜的多。

說(shuō)了這么多，只是為了讓我們更好的理解可擴(kuò)展性的讓我們用下面圖表來(lái)更明確的表達(dá)可擴(kuò)展性。

假設(shè)有一個(gè)只有一臺(tái)服務(wù)器的系統(tǒng)，并且能夠測(cè)量它的最大容量，如圖 1 所示：

假設(shè)我們現(xiàn)在增加一臺(tái)服務(wù)器，系統(tǒng)的能力加倍，如圖 2 所示：

圖 2 就是線性擴(kuò)展。我們?cè)黾恿艘槐兜姆?wù)器，增加了一倍的容量。然而，理想是美好的，現(xiàn)實(shí)是骨感的。大部分系統(tǒng)并不是線性擴(kuò)展的，而是如圖 3 所示的擴(kuò)展方式：

大部分系統(tǒng)都只能以比線性擴(kuò)展略低的擴(kuò)展系數(shù)進(jìn)行擴(kuò)展。這就導(dǎo)致，多數(shù)系統(tǒng)最終會(huì)達(dá)到一個(gè)最大吞吐量臨界點(diǎn)，超過(guò)這個(gè)點(diǎn)后增加投入可能反而會(huì)降低系統(tǒng)的吞吐量。

到這一步，大家對(duì)擴(kuò)展性應(yīng)該已經(jīng)有一個(gè)較為清晰的概念了。在此基礎(chǔ)上，讓我們?cè)偕钊胍徊剑篈mdahl 擴(kuò)展 和 USL 擴(kuò)展。

簡(jiǎn)而言之，USL 說(shuō)的是線下擴(kuò)展的偏差可通過(guò)兩個(gè)因素來(lái)建立模型：

無(wú)法并發(fā)執(zhí)行的一部分工作；

需要交互的另外一部分工作。

在對(duì)第一個(gè)因素繼續(xù)建模后，就有了著名的（聽過(guò)這個(gè)著名嗎？）阿姆達(dá)爾定律（Amdahl）。第一個(gè)因素最終會(huì)導(dǎo)致吞吐量趨于平緩。如果部分任務(wù)無(wú)法并行，那么不管你如果分而治之，該任務(wù)至少需要串行部分的時(shí)間。這句話很重要，讓我們用一個(gè)栗子再簡(jiǎn)單闡述下：
假設(shè)大家都做過(guò)韭菜煎蛋這道菜，我們做這道菜時(shí)，有幾個(gè)必要步驟：

切韭菜，耗時(shí) t1；

打蛋液，耗時(shí) t2；

開煎，耗時(shí) t3；

就上面 3 個(gè)步驟而言，你可以在切韭菜的時(shí)候，讓你女票幫你打蛋液，也就是說(shuō) 1、2 是可以并行的，但是我們能邊切菜邊煎嗎？或者邊打蛋液邊煎嗎？顯示是不行的。因此，步驟 3 和 1、2 是串行的。

這時(shí)候，我們就會(huì)發(fā)現(xiàn)，做韭菜煎蛋這個(gè)任務(wù)需要的時(shí)間 t 為：

t = MAX(t1, t2) + t3;

對(duì)第二個(gè)因素，需要交互的工作而言，交互就意味著內(nèi)部節(jié)點(diǎn)間或者進(jìn)程間的通信。這種通信的代價(jià)取決于通信信道的數(shù)量，而信道的數(shù)量將按照系統(tǒng)內(nèi)工作者數(shù)量的二次方增長(zhǎng)，所以最終開銷比帶來(lái)的收益增長(zhǎng)的更快，這就是產(chǎn)生擴(kuò)展性倒退的原因。由此和 Amdahl 定律，就得出了 USL。

圖 4 闡明了目前討論的三個(gè)概念：線性擴(kuò)展、Amdahl 擴(kuò)展以及 USL 擴(kuò)展。而大多數(shù)真實(shí)系統(tǒng)看起來(lái)更像 USL 曲線。

至此，關(guān)于擴(kuò)展性的概念描述告一段落。接下來(lái)，我們回到正題，看看 MySQL 的擴(kuò)展性如何規(guī)劃。

什么情況下需要擴(kuò)展？，這是個(gè)值得我們牢記的問(wèn)題。當(dāng)我們提到系統(tǒng)的可擴(kuò)展性時(shí)，一般只有兩種情況：

剛開始規(guī)劃一個(gè)應(yīng)用；

當(dāng)前應(yīng)用無(wú)法滿足增加的負(fù)載；

上述兩種情況，大多數(shù)情況下我們碰到的應(yīng)該都是后者。具體表現(xiàn)為：

CPU 密集型變成 I/O 密集型；

并發(fā)查詢競(jìng)爭(zhēng)；

不斷增大的延遲；

如果是可擴(kuò)展的應(yīng)用，可以簡(jiǎn)單地增加更多的服務(wù)器來(lái)分擔(dān)負(fù)載。但如果是可擴(kuò)展性比較差的，你就會(huì)發(fā)現(xiàn) - 只剩下提高可擴(kuò)展性這一條路可走。

只有一條路，那就且行且 996 吧！

走上了提升擴(kuò)展性這條路，接下來(lái)的問(wèn)題就是，如何提高可擴(kuò)展性？這里比較困難的部分是估算應(yīng)用承擔(dān)的負(fù)載到底有多少？這個(gè)值不一定非常精確，但必須在一定的數(shù)量級(jí)范圍內(nèi)。什么？你問(wèn)為什么要在一定范圍內(nèi)？不清楚敵人的火力，咱們是準(zhǔn)備用高射炮打蚊子還是用大刀對(duì)機(jī)槍呢？

除此之外，為了能幫助我們更好的規(guī)劃可擴(kuò)展性，咱們最好還能想清楚下面這個(gè)問(wèn)題：

應(yīng)用的核心功能完成了多少？很多可擴(kuò)展性方案可能會(huì)導(dǎo)致某些功能實(shí)現(xiàn)起來(lái)更加復(fù)雜。在核心功能沒完成前，問(wèn)問(wèn)自己，真的要走提升擴(kuò)展性這條路嗎？換個(gè)說(shuō)法，準(zhǔn)備好迎接 996 了嗎？

程序員們理想的開發(fā)環(huán)境應(yīng)該是：計(jì)劃先行、有足夠能夠一起戰(zhàn)斗的同伴、有花不完的預(yù)算等等。但現(xiàn)實(shí)是：

boss：誒，小九啊，咱們系統(tǒng)提升下性能要多久??？三天應(yīng)該差不多了吧，最多不能超過(guò)一周，上次提升性能，小六一天就搞定了的。

小九：。。。卒

正常情況下，提升系統(tǒng)的擴(kuò)展性的難度可能要比重構(gòu)的難度還要大。因此，在你沒有完全把系統(tǒng)摸熟悉，或?qū)U(kuò)展性還模糊的時(shí)候，千萬(wàn)別給老板說(shuō)要提升系統(tǒng)的擴(kuò)展性。

在老板要求提升性能時(shí)，你要想盡一切辦法滿足他提升性能的需求，同時(shí)，要多想下如何提高系統(tǒng)的擴(kuò)展性，為將來(lái)提升擴(kuò)展性贏得時(shí)間。

可以通過(guò)以下工作先提升系統(tǒng)性能：

優(yōu)化性能。很多時(shí)候可以通過(guò)一個(gè)簡(jiǎn)單的改動(dòng)來(lái)獲得明顯的性能提升。例如為表建立正確的索引，或從 MyISAM 切換到 InnoDB。再進(jìn)一步，可以通過(guò)慢日志來(lái)分析。

購(gòu)買性能更強(qiáng)的硬件。在應(yīng)用早期，升級(jí)或增加服務(wù)器可以顯著的提升系統(tǒng)性能，并且還能快速的完成。就像我們把服務(wù)器從 1 臺(tái)增加到 3 臺(tái)，可能就能讓性能提升 100%，但是當(dāng)我們的服務(wù)器已經(jīng)到達(dá) 100 臺(tái)時(shí)，再?gòu)?100 增加到 300，這時(shí)候的復(fù)雜度和成本可能已經(jīng)讓你心甘情愿走上提升系統(tǒng)擴(kuò)展性的道路上了。

擴(kuò)展性是當(dāng)需要增加資源以執(zhí)行更多工作時(shí)，系統(tǒng)能夠獲得等價(jià)的性能提升的能力。

不準(zhǔn)確評(píng)估應(yīng)用負(fù)載的擴(kuò)展，都是耍流氓。