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支援分散式嗎的詳細內容。更多資訊請關注PHP中文網其他相關文章！