MYSQL如何探索在非互聯網企業中的讀寫分離架構

MYSQL如何探索在非互聯網企業中的讀寫分離架構，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

MYSQL的高可用和使用大多都是基于互聯網的方式，MHA，PXC，這些方式在互聯網里面大量的使用，并且使用的非常好，互聯網企業充斥著各種修改MYSQL 原代碼的“高端人才”。 

反觀，為什么傳統企業，金融企業使用MYSQL，并讓這個數據庫發揚光大的缺失鳳毛菱角。

拋出去互聯網企業敢給錢，敢雇人，做什么都可以在做中碰釘子，在改善的基本思想。大量的支持和維護運維的力量是不可以忽視的。

傳統企業在這方面是差的比較遠，所以MYSQL這樣的數據庫用的不順手，在加上業務的緊密和開發方式等等 bulabula . MYSQL 的架構在使用了上面那些企業給運維帶來很多不便。

個人認為（也許需要繼續改善），傳統企業或者金融企業需要的MYSQL的架構好維護，好使用，更要妥協開發的傳統業務的某些方式。

你可以使用ORACLE  RAC ，Dataguard, SQL SERVER 的  Cluster ,  Always-on 等等，至少在讀寫分離上或高密集的操作中，基本上不會給你太尷尬的表現。  MYSQL 以前一直是主從復制，而要保證主從復制的一致性，除了用半同步這樣的“單條虎”，然后就是各種開發要求，要支持互聯網動輒幾百人甚至上千人的開發團隊是有技術力量來將那些密集型的操作去化解的。而傳統企業沒有那么多的資金來雇傭那么多的開發人員，運維人員。

一個可靠的MYSQL架構就顯得尤為重要了，目前MGR 作為MYSQL的復制或者說高可用的方式，已經推開。當然也有問題，但至少他能給你做到的，1 數據的一致性 2 搭建方式的簡單  3維護方式相對其他方式要簡單，配上可靠的中間件，基本上傳統的開發人員就可以實現他們想要的讀寫分離，以及運維人員需要的FAILOVER ，及對應用程序的透明切換。

那還是來點實際的，下面是一MYSQL高可用加讀寫分離的架構圖

其實中間件使用哪個可能無所謂，但為了更好的簡化運維的工作，我們其實可以使用DOCKER 來將中間件容器化，這樣能降低中間件的FAILOVER的工作量，同時也能節省資源（通常傳統企業的訪問量不大）。架構中還有一點估計是有人想 challange的， 就是為什么要用兩個中間件，說實話可以不用，一個中間件就可以，但兩個的中間件也是考慮傳統企業的開發人員，你要他完全將所有的 SELECT 語句 都走從庫，這對他本身來說也是一項挑戰，其中的問題也會不少，這邊兩個中間件，就是給運維和開發一個緩沖。如果想進行在寫庫的操作那就走 一個中間件，如果想僅僅是只讀的方式使用，則去訪問另一個走只讀的中間件即可，對開發和運維都還算比較友好。

這樣既能滿足遷就傳統企業開發和運維的LEVEL 也能更簡單的批量定制化的部署。同時對于應用也是透明的切換（standby -- primary）

可能還有人問，中間件為什么不復用，多套MGR 用一個中間件做FAILOVER 不也是OK ，其實是可以的，但如果使用了DOCKER 的情況下，其實分開更好，一套MGR 用自己的，這樣降低耦合，出了問題也不是大面積性的，只會影響相關的對應的MGR。

1  正常的狀態

2  主節點故障切換狀態

3  切換后的狀態

剩下的就是落實DOCKER 中間件的部署以及DOCKER FAILOVER的問題。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。