面試被問mysql擴展性設計相關的點，你知道該如何回答嗎
什麼是擴展性
數據庫的擴展主要體現在兩個方面，一個是橫向擴展(Scale Out)，另外一個是縱向擴展（Scale Up）
- 橫向擴展(Scale Out) 向外擴展、通過增加節點的方式來提高整體處理能力，通俗點講就是通過增加機器來增加整體的處理能力
- 縱向擴展（Scale Up）向上擴展、通過增加當前的節點的處理能力來提高整體的處理能力，通過升級現有服務器的配置、如增加內存、增加cpu
橫向擴展(Scale Out) 和縱向擴展（Scale Up）區別
橫向擴展
- Scale Out 優點
- 成本低
- 不太容易遇到瓶頸，很容易通過添加主機來增加處理能力
- 單個節點故障對系統整體影響小，也存在缺點，都是服務器主機，整個系統的維護性的提高，成本維護增加
- Scale Out 缺點
- 處理節點多。造成系統架構過於複雜，應該程序複雜度提高
- 集羣維護難度提高，維護成本大
縱向擴展
-
Scale Up 優點
- 處理節點少、維護相對簡單
- 所有數據集中在一起、系統架構相對簡單、開發相對容易
-
Scale Up 缺點
- 高端設備成本高、且競爭少，容易受到廠家的限制
- 受硬件設備的發展限制、單臺主機的處理能力總是有極限的。容易遇到無法解決的性能瓶頸
事務相關性最小化原則
解決方案
- 第一：Scale Out 設計的時候合理設計切分規則，儘可能保證事務所需數據在同 一個 MySQL Server 上，避免分佈式事務
- 第二：大事務切分成多個小事務， 數據庫保證各個小事務的完整性， 應用控制各個事小 務之間的整體事務完整性
- 上述兩種解決方案，結合使用，整合各自的優勢、避免其劣勢、通過這樣相互平衡設計的原則， 我們既可以避免應用程序需要處理太多的小事務來證保其整的完整性， 同時也能夠避免拆分規則太多複雜而帶來後期維護難度的增加及擴展受性阻的情況
敲黑板、化重點
最後， 我們還需要明白一個觀點， 那就是事務並不是越多越好， 而是越少越好越好小。越不論我們使用何種解決方案， 那就是在我們設計應用程序的時候，都需要儘可能做到讓據數的事務相關性更小，甚至是不需要事務相關性。 當然，這只是相對的， 也肯定只有部分據數 能夠做到。 但可能就是某部分數據做到了無事務相關性之後， 系統整體複雜度就會降低大很一個層次，應用程序和數據庫系統兩方面都可能少付出很多的代價
數據一致性原則
背景
不論是 Scale Up 還是 Scale Out， 不論我們如何設計自己的架構， 保證數據的最一終 致性都是絕對不能違背的原則， 保證這個原則的重要性我想各位讀者肯定也都是非常明清白楚的。
而且，數據一致性的保證就像事務完整性一樣，在我們對系統進行Scale Out 設計的 時候，也可能會遇到一些問題。當然，如果是 Scale Up，可能就很少會遇到這類麻煩了。 當然， 在很多人眼中， 數據的一致性在某種程度上面也是屬於事務完整性的範疇。 不過裏這 爲了突出其重要性和相關特性，我還是將他單獨提出來分析。
那我們又如何在 Scale Out 的同時又較好的保證數據一致性呢?很多時候這個問題和 保證事務完整性一樣讓我們頭疼， 也同樣受到了很多架構師的關注。 經過很多人的實踐大家最後總結出了 BASE 模型。即:基本可用，柔性狀態，基本一致和最終一致。這幾個看詞 着挺複雜挺深奧，其實大家可以簡單的理解爲非實時的一致性原則。
解決方案
也就是說， 應用系統通過相關的技術實現， 讓整個系統在滿足用戶使用的基礎上，許允數據短時間內處於非實時狀態， 而通過後續技術來保證數據在最終保證處於一致狀態。個這理論模型說起來確實聽簡單，但實際實現過程中我們也會遇到不少難題。
首先
第一個問題就是我們需要讓所有數據都是非實時一致嗎?我想大多數讀者朋肯友 定是投反對票的。 那如果不是所有的數據都是非實時一致， 那我們又該如何來確定哪些據數 需要實時一致哪些數據又只需要非實時的最終一致呢?其實這基本可以說是一個各模塊業 務優先級的劃分， 對於優先級高的自然是規屬於保證數據實時一致性的陣營， 而優先級低略 的應用， 則可以考慮劃分到允許短時間端內不一致而最終一致的陣營。 這是一個非常棘的手 問題。 我們不能隨便拍腦袋就決定， 而是需要通過非常詳細的分析和仔細的評估才能作決出 定。 因爲不是所有數據都可以出現在系統能不短時間段內不一致狀態， 也不是所有數據都可 以通過後期處理的使數據最終達到一致的狀態，所以之少這兩類數據就是需要實時一致的。 而如何區分出這兩類數據， 就必須經過詳細的分析業務場景商業需求後進行充分的評估能才 得出結論。
其次
如何讓系統中的不一致數據達到最終一致?一般來說， 我們必須將這類數據設所 計到的業務模塊和需要實時一致數據的業務模塊明確的劃分開來。 然後通過相關的異步制機 技術， 利用相應的後臺進程， 通過系統中的數據， 日誌等信息將當前並不一致的數據進進行 一步處理， 使最終數據處於完全一致狀態。 對於不同的模塊， 使用不同的後臺進程， 既以可 避免數據出現紊亂， 也可以併發執行， 提高處理效率。 如對用戶的消息通知之類的信息就， 沒有必要做到嚴格的實時一致性， 只需要現記錄下需要處理的消息， 然後讓後臺的處理程進 依次處理，避免造成前臺業務的擁塞。
最後
避免實時一致與最終一致兩類數據的前臺在線交互。 由於兩類數據狀態的不致一 性， 很可能會導致兩類數據在交互過程中出現紊亂， 應該儘量讓所有非實時一致的數據實和 時一致數據在應用程序中得到有效的隔離。 甚至在有些特別的場景下， 記錄在不同的MySQL Server 中來進行物理隔離都是有必要的。