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讀寫分離 內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！