資料庫讀寫分離mysql

『壹』 mysql的讀寫分離和主從復制的區別在哪裡

讀寫分離的意思是，寫入的時候向 a 伺服器寫入，而讀出的時候從 b c d 甚至更多的伺服器讀出；這樣的架構適合於讀多寫少的應用，最典型的就是火車購票系統，一般我們買票的時候要先查詢好多次，包括車次啊，時間啊，這都是讀操作，而最後可能只買一張車票，這是寫操作；做了讀寫分離之後，可以將資源分配到最合理的地方，不會使某些資源閑置，而另一些資源不夠用；

但是讀寫分離必然引發主從復制，試想一共有 10 張票，買了 1 張票，讀的時候如果還是讀到 10 張余票就不對了，因此需要主從復制，再讀的時候，就只能讀到 9 張余票了；

『貳』 mysql讀寫分離和用Redis做緩存，這兩種方案有什麼異同

讀寫分離一般都是結合Master/Slave模式使用，Master處理寫請求，Slave處理讀請求，這樣做的好處是：
1、提高資料庫的並發處理能力；
2、避免寫請求鎖表阻塞讀請求；
3、避免單點，提高資料庫的可用性；
而使用Redis作為DB前面的緩存，是為了減少對MySQL的壓力，提高系統的處理效率。

二者解決的問題域不同，不存在誰替代誰。

一般高並發應用都是結合二者使用。

『叄』 SpringBoot項目中實現MySQL讀寫分離

但我們仔細觀察我們會發現，當我們的項目都是用的單體資料庫時，那麼就可能會存在如下問題：

為了解決上述提到的兩個問題，我們可以准備兩 (多) 台MySQL，一台主( Master )伺服器，一台從( Slave )伺服器，主庫的 數據變更 (寫、更新、刪除這些操作) ，需要 同步 到從庫中 (主從復制) 。而用戶在訪問我們項目時，如果是 寫操作 (insert、update、delete)，則直接操作 主庫 ；如果是 讀操作 (select) ，則直接操作從庫，這種結構就是 讀寫分離 啦。

在這種讀寫分離的結構中，從庫是可以有多個的

MySQL主從復制是一個 非同步 的復制過程，底層是基於Mysql資料庫自帶的 二進制日誌 功能。就是一台或多台MySQL資料庫（slave，即 從庫 ）從另一台MySQL資料庫（master，即 主庫 ）進行日誌的復制，然後再解析日誌並應用到自身，最終實現 從庫 的數據和 主庫 的數據保持一致。MySQL主從復制是 MySQL資料庫自帶功能，無需藉助第三方工具。

二進制日誌（BINLOG）記錄了所有的 DDL（數據定義語言）語句和 DML（數據操縱語言）語句，但是不包括數據查詢語句。此日誌對於災難時的數據恢復起著極其重要的作用，MySQL的主從復制， 就是通過該binlog實現的。默認MySQL是未開啟該日誌的。

在環境搭建之前，我們需要准備好兩台伺服器，如果生活富裕使用的是兩台雲伺服器的時候記得要開放安全組，即防火牆；如果是比狗子我生活好點但也是用的虛擬機的話，記得別分這么多內存啟動藍屏了（別問怎麼知道的）

這里就不給大家展示資料庫的安裝和防火牆的操作了，這個我感覺網上好多資源都能夠滿足遇到的問題，在搭建主從庫的時候有在網上見到過說MySQL版本要一致的，我也沒太留意直接就在之前的MySQL上操作了，大家可以自己去驗證一下。

伺服器：192.168.150.100（別試了黑不了的，這是虛擬機的ip）

這里有三個方法都能重啟MySQL，最簡單的無疑就是一關一開：

登錄進去MySQL之後才能夠執行下面的命令，因為這是SQL命令，linux不認識這玩意是啥。

這個時候還 不用退出MySQL ，因為下面的命令還是SQL命令，執行下面的SQL，可以拿到我們後面需要的兩個重要參數。

執行完這一句SQL之後，==不要再操作主庫！不要再操作主庫！不要再操作主庫！==重要的事情說三遍，因為再操作主庫之後可能會導致紅框中的 兩個屬性值會發生變化 ，後面如果發生了錯誤可能就和這里有那麼兩毛錢關系了。

伺服器：192.168.150.101（別試了黑不了的，這也是虛擬機的ip）

這里要注意server-id和主庫以及其他從庫都不能相同，否則後面將會配置不成功。

這里有三個方法都能重啟MySQL，最簡單的無疑就是一關一開：

登錄進去MySQL之後才能夠執行下面的命令，因為這是SQL命令

參數說明：

這個時候還 不用退出MySQL ，因為下面的命令還是SQL命令，執行下面的SQL，可以看到從庫的狀態信息。通過狀態信息中的 Slave_IO_running 和 Slave_SQL_running 可以看出主從同步是否就緒，如果這兩個參數全為 Yes ，表示主從同步已經配置完成。

這可能是由於linux 是復制出來的，MySQL中還有一個 server_uuid 是一樣的，我們也需要修改。 vim /var/lib/mysql/auto.cnf

這應該就是各位大牛設置server_id的時候不小心設置相同的id了，修改過來就行，步驟在上面的配置中。

這是狗子在操作過程中搞出來的一個錯誤……

出錯的原因是在主庫中刪除了用戶信息，但是在從庫中同步的時候失敗導致同步停止，下面記錄自己的操作（是在進入MySQL的操作且是從庫）。

在資料庫中操作時，一定要注意當前所在的資料庫是哪個，作為一個良好的實踐：在SQL語句前加 USE dbname 。

Sharding-JDBC定位為 輕量級Java框架 ，在Java的JDBC層提供的額外服務。 它使用客戶端直連資料庫，以 jar包 形式提供服務，無需額外部署和依賴，可理解為增強版的JDBC驅動， 完全兼容JDBC和各種ORM框架 。

使用Sharding-JDBC可以在程序中輕松的實現資料庫 讀寫分離 。

Sharding-JDBC具有以下幾個特點：

下面我們將用ShardingJDBC在項目中實現MySQL的讀寫分離。

在pom.xml文件中導入ShardingJDBC的依賴坐標

在application.yml中增加數據源的配置

這時我們就可以對我們項目中的配置進行一個測試，下面分別調用一個更新介面和一個查詢介面，通過查看日誌中記錄的數據源來判斷是否能夠按照我們預料中的跑。

搞定！！！程序正常按照我們預期的成功跑起來了，成功藉助ShardingJDBC在我們項目中實現了資料庫的讀寫分離。