MySQL - 擴展性 2 擴展策略：氪金氪腦任君選

若是將應用的全部數據簡單地放在一臺 MySQL 服務器實例上，就不用談什麼擴展性了。可是業務能穩定持續的增加，那麼應用確定會碰到性能瓶頸。

對於不少類型的應用而言，購買更高性能的機器能解決一大部分性能問題，這也是咱們常說的 「垂直擴展」 或者 「向上擴展」。

另外一個與之相反的方法是將任務分配的多臺機器上，這一般被稱爲 「水平擴展」 或者 「向外擴展」。

接下來，咱們將討論如何聯合使用向上擴展和向外擴展，以及如何使用集羣方案來進行擴展。

最後，大部分應用還會有一些不多或者從不須要的數據，這些數據能夠被清理或歸檔，咱們能夠稱這種方案爲 「向內擴展」。

1 向上擴展

向上擴展（也叫垂直擴展）意味着購買更多性能強悍的機器。這種策略有較多優勢：

• 更容易維護和開發，顯著節約開銷；
• 單臺服務器備份和恢復較爲簡單，無需關心一致性；

所以，從複雜性的成原本說，大多時候，向上擴展比向外擴展更簡單。

另外，不要以爲向上擴展很快就走到「盡頭」，要相信科技的進步速度。如今，擁有 0.5TB 內存、32 核（或者更多）CPU 以及更強悍 I/O 性能的商用服務器很容易得到。優秀的應用和數據庫設計，再加上很好的性能優化技能，已經能夠知足絕大多數商業應用。

不過遺憾的，雖然高性能服務器比較容易得到，可是 MySQL 並不能擴展到對應的規模。爲了更好地在大型服務器上運行 MySQL，必定要儘可能選擇最新的版本。即便如此，當前合理的 「收益遞減點」 的機器配置大約是：

• 256G RAM
• 32 核 CPU
• PCIe flash 驅動器

若是繼續提高硬件配置，MySQL 性能雖然還能有所提高，但性價比就會下降。

所以，咱們建議，若是系統確實有可能碰到可規劃性的天花板，而且會致使嚴重的業務問題，那就不要無限制的作向上擴展的規劃。對於龐大的應用，能夠短時間內購買更優的服務器，但最終仍是須要向外擴展的。

2 向外擴展

向外擴展（也叫橫向擴展或水平擴展）策略一般分爲三個部分：複製、拆分和數據分片。

最多見的向外擴展就是讀寫分離。經過複製將數據分發到多個服務器上，而後將備庫用於讀查詢。這種技術對於以讀爲主的應用頗有效。

另外一個比較常見的向外擴展方法是將工做負載分佈到多個 「節點」。接下來咱們要了解的主要是這種擴展方法。

在此以前，咱們先明確下節點的概念。在 MySQL 架構中，一個節點就是一個功能部件。通常的，咱們會將一臺服務器做爲一個幾點。但若是咱們考慮到節點的高可用性，那麼一個節點一般多是下面的幾種：

• 一個主 - 主 複製雙機結構，擁有一個主動服務器和被動服務器。
• 一個主庫和多個備庫。
• 一個主動服務器，並使用分佈式複製塊設備（DRBD）做爲備用服務器。
• 一個基於存儲區域網絡（SAN）的 「集羣」。

2.1 按功能拆分

按功能拆分，或者說按職責拆分，意味着不一樣的節點執行不一樣的任務。

例如，若是有一個網站，各個部分無需共享數據，那麼能夠按照網站的功能區域進行劃分。像咱們常見的門戶網站，通常都是把不一樣欄目放在一塊兒，但實際上能夠將網站新聞、論壇、尋求支持等功能放到專用的 MySQL 服務器。如圖 2-1

2.2 數據分片

在目前用於擴展大型 MySQL 應用的方案中，數據分片是最通用且最成功的方法。它把數據分割成一小片，或者說一塊，而後存儲到不一樣的節點中。

在使用分片前，要牢記一個通用原則：如非必要，儘可能不分片。

除此以前，對於分片，咱們只會對須要的數據作分片。這裏 「須要的數據」 一般是那些增加很是龐大的數據。而像對於用戶信息這些全局數據，通常是存儲在單個節點上，一般保存在相似 redis 這樣的緩存中。

對於分片，咱們一般要考慮下列問題：

1. 選擇合適的分區鍵（partition key）。
2. 是否須要多個分區鍵？
3. 跨分片查詢如何處理？
4. 如何分片數據、分片和節點？
5. 如何在節點上部署分片？
6. 如何生成全局惟一 ID？

2.3 經過多實例擴展

上面提到過，MySQL 不能徹底發揮現代硬件的性能。當擴展到超過 24 個 CPU 核心時，MySQL 的性能開始趨於平緩，再也不上升。當內存超過 128G 時也一樣如此。對於此種狀況，咱們能夠經過多實例策略充分發揮硬件的性能。

多實例策略的基本思路是：

1. 數據分片足夠小，可使得在每臺機器上都能放置多個分片；
2. 每臺服務器運行多個實例；
3. 給每一個實例劃分服務器的硬件資源；

能夠看出，這是一種向上擴展和向外擴展的組合方案。這種方案還能夠經過將每一個 MySQL 實例綁定到特定的 CPU 核心上來優化性能。這種優化，主要有兩個好處：

1. 因爲 MySQL 內部的可擴展性限制，當核心數較少時，可以在每一個核心上得到更好的性能；
2. 當實例在多個核心上運行線程時，因爲須要在多核心上同步共享數據，於是會有額外的開銷。

而咱們把實例和 CPU 核心綁定後，能夠減小 CPU 核心直接的切換和交互。要注意的，將進程綁定到具備相同物理套接字的核心上能夠得到最優的效果。

3 向內擴展

對於不斷增加的數據和負載，最簡單的方法是對再也不須要的數據進行歸檔和清理。這種操做可能會帶來顯著的效果。這種作法並不能代替其餘策略，但能夠做爲爭取時間的短時間策略，也能夠做爲處理大數據量的長期計劃之一。

在設計歸檔和清理策略時須要考慮以下幾點：

1. 對應用的影響。設計良好的歸檔系統可以在不影響事務處理的狀況下，從一個高負債的 OLTP 服務器上移除數據。
2. 要歸檔的行。考慮清楚哪些數據能夠清理或歸檔。
3. 維護數據一致性。數據間存在聯繫時，歸檔任務系統要可以保證數據的邏輯一致性。
4. 避免數據丟失。歸檔時要保證歸檔數據已經成功保存，再講源數據刪除。
5. 解除歸檔。考慮清楚歸檔系統中的解除歸檔策略。能夠經過設置一些檢查點讓系統檢查是否有須要歸檔的數據。

若是不能及時的把老數據歸檔和清理時，咱們也能夠經過如下隔離冷熱數據的方式來提升性能：

1. 將表劃分爲幾個部分。分割大表中的冷熱數據，保證加載到內存中的數據中，熱數據的比例；
2. MySQL 分區。使用MySQL 自帶的分區的功能，能夠幫助咱們把最近的數據留在內存中；
3. 基於時間的數據分區。若是應用不斷有新數據儘可能，通常新數據老是比舊數據更加活躍。所以，咱們能夠將新數據完整的保留在內存中，同時使用複製來保證主庫失效時有一份能夠的備份，而舊數據就而言放到別的地方。

總結

• 向上氪金，向外氪腦。三思然後行。
• 能不分片，就儘可能不分片。