讀寫分離是基於主從複製來實現的。在實際的應用環境中，肯定是讀取操作多，就像我們在電商平台上去買東西，可能看了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還是MySQL，因為通訊都是遵守的是MySQL通訊協議，怎麼和MySQL通信，現在就怎麼和MyCat通信，所以不用區分。
在MyCat上配置讀寫分離，我們在客戶端上的程式碼不用做任何變更，程式碼上不需要區分哪個請求是讀，哪個請求是寫，程式碼直接訪問的是MyCat，由MyCat解析請求，依照SQL的讀寫性質轉送到負責對應操作的伺服器，實現讀寫分離。
在MyCat上需要設定主伺服器和從伺服器的資訊，有3種情況：一主一從、一主多從、多主多從
一主多從場景：當寫函式庫（master）掛了，MyCat還可以馬上把一個從函式庫（slave）直接變成一個寫函式庫（master），那相當於又回到一台機器的處理，因為從庫和從庫之間並沒有主從複製的配置，所以我們還需要把變成寫庫的從庫還要和其他從庫之間配置一下主從複製。
多主多從：
#可以看到圖中，MyCat伺服器掛了兩套環境，如果其中1套的主庫宕機了（它對應的從庫也就不能用了），此時MyCat會自動切到另一套環境，因為M1和M2之間也是配置成互為主從的，所以M2可以同步M1的數據，提供與M1環境完全相同的服務，所以它的高可用容災能力是非常不錯的。
MySQL的服務埠是3306，MyCat服務埠是8066（這個埠也是可以改的），也就是MySQL Client連接的是8066端口，登入8066端口看到的介面就和登入MySQL Server的3306端口一樣。 MyCat還有一個管理埠9066，登入這個管理埠可以查看MyCat正在工作的所有狀態以及和後端伺服器的連接，以及連接資料來源的狀態等。
以上是MySQL讀寫分離原理是什麼的詳細內容。更多資訊請關注PHP中文網其他相關文章！
