MySQL讀寫分離原理是什么

這篇文章主要講解了“MySQL讀寫分離原理是什么”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“MySQL讀寫分離原理是什么”吧！

一、讀寫分離的概念

讀寫分離是基于主從復制來實現的。在實際的應用環境中，肯定是讀操作多，就像我們在電商平臺上去購買東西，可能看了100個也就買了一兩個。所以讀操作永遠比寫這種更新操作多很多。所以我們基于主從復制的讀寫分離配置，就是讓一個主庫專門用來做數據的修改，寫的時候專門在主庫上寫，主庫通過主從復制把數據的更改通過binlog同步到從庫上去，那么其他的客戶端查詢的請求都會最終映射到從庫上去，而我們一個主庫帶上兩三個從庫，主庫專門用來做數據的更新（寫操作），從庫專門用來做讀操作這樣一來可以很好的分攤讀寫的壓力，不用全部都集中在主庫上，對于后端服務的并發處理能力有很大的提高，另外就是它的高可用容災，當主庫掛了以后，可以把指定的從庫變成主庫。

MySQL client通過mysql 提供的API，用mysql自定義的基于TCP的數據協議（簡稱mysql協議）與MySQL Server通信，訪問MySQL Server數據庫。

如果只有一臺服務器（單機環境），所有數據的增刪改查都是在一臺服務器上進行，隨著我們的服務被越來越多的人使用，流量逐漸變大，需要并發能力逐漸提升，所以如果我們發現數據庫性能到瓶頸了，我們可以做讀寫分離操作，提高后臺服務。

圖中的MySQL主服務器專門做寫操作，下面連著2個MySQL從服務器專門做讀操作，讀請求轉發到B、C，寫請求轉發到A。

如果我們在客戶端上直接用代碼寫死，insert、update等寫操作在A上做，show、select等讀操作在B、C上做，相當于代碼和主從環境就是強綁定的。這就導致代碼的穩定性不太好，因為和環境強相關了，我們寫代碼得時候必須得知道哪個機器是負責寫操作的主庫，哪個機器是負責讀操作的從庫，由代碼來選擇。而這時如果有某個機器掛掉了，代碼也不會知道，還是按照原來的方式轉發請求，通信就會出現問題，所以把讀寫分離用代碼實現肯定不合適。所以在實際的解決方案中，讀寫分離需要依賴數據庫的中間件。

二、引入中間件MyCat

實際上，讀寫分離，分庫分表都是需要依賴數據庫中間件（mycat），mycat就是代理服務器的角色。

客戶端實際上區分不出來連的是MyCat還是MySQL，因為通信都是遵守的是MySQL通信協議，之前怎么和MySQL通信，現在就怎么和MyCat通信，所以不用進行區分。

在MyCat上配置讀寫分離，我們在客戶端上的代碼不用做任何變更，代碼上不需要區分哪個請求是讀，哪個請求是寫，代碼直接訪問的是MyCat，由MyCat解析請求，根據SQL的讀寫性質轉發到負責相應操作的服務器，實現讀寫分離。

在MyCat上需要配置主服務器和從服務器的信息，有3種情況：一主一從、一主多從、多主多從

一主多從場景：當寫庫（master）掛了，MyCat還可以馬上把一個從庫（slave）直接變成一個寫庫（master），那相當于又回到一臺機器的處理，因為從庫和從庫之間并沒有主從復制的配置，所以我們還需要把變成寫庫的從庫還要和其他從庫之間配置一下主從復制。

多主多從：

可以看到圖中，MyCat服務器掛了兩套環境，如果其中1套的主庫宕機了（它對應的從庫也就不能用了），此時MyCat會自動切到另一套環境，因為M1和M2之間也是配置成互為主從的，所以M2可以同步M1的數據，提供與M1環境完全相同的服務，所以它的高可用容災能力是非常不錯的。

三、MyCat服務端口和管理端口

MySQL的服務端口是3306，MyCat服務端口是8066（這個端口也是可以改的），也就是MySQL Client連接的是8066端口，登錄8066端口看到的界面就和登錄MySQL Server的3306端口一樣。MyCat還有一個管理端口9066，登錄這個管理端口可以查看MyCat正在工作的所有狀態以及和后端服務器的連接，以及連接數據源的狀態等。

感謝各位的閱讀，以上就是“MySQL讀寫分離原理是什么”的內容了，經過本文的學習后，相信大家對MySQL讀寫分離原理是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！