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

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

但是當系統性能增加到一定地步時，你會發現，原先花 3000 塊提升了 50% 的性能，現在花 30000 塊，才提升了不到 10%。

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

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

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

容量是一個和可擴展性相關的概念。系統容量表示在一定時間內能夠完成的工作量。

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

性能是汽車的時速。

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

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

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

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

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

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

數據量

應用所能累計的數據量是可擴展性最普遍的挑戰，特別是對于現在的互聯網應用而言，因為從不刪除數據。

用戶量

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

用戶活躍度

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

相關數據集的大小

如果用戶間存在關系，應用可能需要在整個相關聯用戶群體上執行查詢和計算，這比處理一個個的用戶和用戶數據要復雜的多。

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

假設有一個只有一臺服務器的系統，并且能夠測量它的最大容量，如圖 1 所示：

假設我們現在增加一臺服務器，系統的能力加倍，如圖 2 所示：

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

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

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

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

無法并發執行的一部分工作；

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

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

切韭菜，耗時 t1；

打蛋液，耗時 t2；

開煎，耗時 t3；

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

這時候，我們就會發現，做韭菜煎蛋這個任務需要的時間 t 為：

t = MAX(t1, t2) + t3;

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

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

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

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

剛開始規劃一個應用；

當前應用無法滿足增加的負載；

上述兩種情況，大多數情況下我們碰到的應該都是后者。具體表現為：

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

并發查詢競爭；

不斷增大的延遲；

如果是可擴展的應用，可以簡單地增加更多的服務器來分擔負載。但如果是可擴展性比較差的，你就會發現 - 只剩下提高可擴展性這一條路可走。

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

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

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

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

程序員們理想的開發環境應該是：計劃先行、有足夠能夠一起戰斗的同伴、有花不完的預算等等。但現實是：

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

小九：。。。卒

正常情況下，提升系統的擴展性的難度可能要比重構的難度還要大。因此，在你沒有完全把系統摸熟悉，或對擴展性還模糊的時候，千萬別給老板說要提升系統的擴展性。

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

可以通過以下工作先提升系統性能：

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

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

擴展性是當需要增加資源以執行更多工作時，系統能夠獲得等價的性能提升的能力。

不準確評估應用負載的擴展，都是耍流氓。