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

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

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

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

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

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

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

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

性能是汽車的時速。

容量是車道乘以最大安全時速。

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

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

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

從較高層次看，可擴展性就是能夠通過增加資源來提升容量的能力。

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

數(shù)據(jù)量

應(yīng)用所能累計的數(shù)據(jù)量是可擴展性最普遍的挑戰(zhàn)，特別是對于現(xiàn)在的互聯(lián)網(wǎng)應(yīng)用而言，因為從不刪除數(shù)據(jù)。

用戶量

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

用戶活躍度

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

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

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

說了這么多，只是為了讓我們更好的理解可擴展性的讓我們用下面圖表來更明確的表達可擴展性。

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

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

圖 2 就是線性擴展。我們增加了一倍的服務(wù)器，增加了一倍的容量。然而，理想是美好的，現(xiàn)實是骨感的。大部分系統(tǒng)并不是線性擴展的，而是如圖 3 所示的擴展方式：

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

到這一步，大家對擴展性應(yīng)該已經(jīng)有一個較為清晰的概念了。在此基礎(chǔ)上，讓我們再深入一步：Amdahl 擴展 和 USL 擴展。

簡而言之，USL 說的是線下擴展的偏差可通過兩個因素來建立模型：

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

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

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

切韭菜，耗時 t1；

打蛋液，耗時 t2；

開煎，耗時 t3；

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

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

t = MAX(t1, t2) + t3;

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

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

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

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

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

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

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

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

并發(fā)查詢競爭；

不斷增大的延遲；

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

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

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

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

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

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

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

小九：。。。卒

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

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

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

優(yōu)化性能。很多時候可以通過一個簡單的改動來獲得明顯的性能提升。例如為表建立正確的索引，或從 MyISAM 切換到 InnoDB。再進一步，可以通過慢日志來分析。

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

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

不準確評估應(yīng)用負載的擴展，都是耍流氓。