mysql是否支持分布式

下文主要給大家帶來mysql是否支持分布式，希望這些內容能夠帶給大家實際用處，這也是我編輯mysql是否支持分布式這篇文章的主要目的。好了，廢話不多說，大家直接看下文吧。

首先數據庫是一個軟件，最基礎的功能就是數據存儲和數據查詢。對于數據的處理方式如果通泛來說是分為讀和寫，所以分布式方案的很多場景其實也是圍繞著這兩個維度來做的。

在開始分布式方案前，要說下為什么要有分布式方案。如果單機可以解決的事情，其實完全沒有必要去再考慮分布式了。如果要分，其實就不能再很自然的合起來，這也是分布式方案里需要掌握的一個平衡。 現在行業里說的HTAP方案，其實就是融合了OLTP+OLAP的場景，如果從單機的角度來說，Oracle肯定是最好的HTAP解決方案了。 但是oracle里面除了價格的問題之外，還有一個問題，那就是擴展性，暫不說sharding的細節，Oracle里面的設計思想就是share everything,所以分區表的方案還是比較合適的。

但是MySQL顯然不行，因為你幾乎聽不到互聯網行業里在用分區表的方案，因為再怎么分，怎么擴展，數據都是在單機上，況且單機性能還差強人意。 所以單機容量，單機性能都是一個瓶頸，那么就可以有兩個或者多個實例來分擔壓力。

我來簡單舉個例子。從數據的處理角度來說，數據有讀寫需求，那么我們的需求就可以分別對讀需求和寫需求做擴展。

讀需求的擴展相對來說簡單一些，就是常說的讀寫分離了。這種一般的中間件都可以支持。

就如同下圖的方案里面的左下角所示，對讀的需求可以輕松實現讀擴展，這里的讀擴展是線性的，不是指數級的，對業務來說是透明的。

難點就在于寫擴展了，寫擴展的核心是涉及到分布式事務的部分，能不拆就不拆，如果實在要拆，那么我們可以分不同的維度，比如對于流水型數據，這類數據的前后依賴度很低，所以寫需求就是insert，寫的需求比較單一。這種方式可以使用中間件的方案來輔助，做到sharding的分片方案。 我們通常理解的分布式方案其實很多也是在說這個。這種方案的擴展是指數級別的，比如2個節點，變為4個，4個變為8個等等，對業務算是透明的。

但是還有一類更為復雜的，那就是狀態型數據，我們不能直接拆，或者說直接分片，我們可以根據業務的維度來拆分，這種拆分就不建議直接使用中間件了。 比如一個業務如果拆分可以拆分為業務1，業務2，業務3。。。業務8，那么這8個業務的拆分邏輯建議不是做成hash的平滑方式，而是建議根據業務邏輯的優先級和其他維度來組合，比如業務1的優先級高，那么完全可以是一個獨立的節點，業務3-業務6的數據量和優先級不同，則完全可以是一個節點。數據的寫入路由規則建議還是通過應用層面來進行處理。這是一種更加可控的方案。這種擴展方案對應用不是透明的，需要應用的配合和處理。但是收益也顯然是最佳的平衡狀態，比如游戲行業里很常見的游戲服概念，就是這種分法，所以擴展起來可以是線性的。

如果要說這個基礎之上的分布式方案，其實是把一套集群或者業務當做一個透明的節點，使用其他的輔助方案來達到擴展的需求，基于關系型的分布式方案更多是基于靜態路由來處理，對于擴容來說還是需要做很多額外的工作，沒法做到平滑的彈性。這一點上自然是NoSQL,NewSQL的用武之地了。

所以在方案的選擇上，要有大局觀和更高的視野，不一定什么都是MySQL,Oracle，深耕下去自然是不錯的，還可以考慮其他更好的方案。

對于以上關于mysql是否支持分布式，大家是不是覺得非常有幫助。如果需要了解更多內容，請繼續關注我們的行業資訊，相信你會喜歡上這些內容的。