在實際的生產環境中，對數據庫的讀和寫都在同一個數據庫服務器中，是不能滿足實際需求的。無論是在安全性、高可用性還是高併發等各個方面都是完全不能滿足實際需求的。因此，通過主從複製的方式來同步數據，再通過讀寫分離來提升數據庫的併發負載能力。
一、主從複製
1.mysq 支持的複製類型
1） 基於語句的複製。在服務器上執行 sql 語句，在從服務器上執行同樣的語句，mysql 默認採用基於語句的複製，執行效率高。
2） 基於行的複製。把改變的內容複製過去，而不是把命令在從服務器上執行一遍。
3） 混合類型的複製。默認採用基於語句的複製，一旦發現基於語句無法精確複製時，就會採用基於行的複製。
2.主（Master）從（Slave）複製的工作過程
1） 在每個事務更新數據完成之前，master 在二進制日誌記錄這些改變。寫入二進制日誌完成後，master 通知存儲引擎提交事務。
2） Slave 將 master 的 binary log 複製到其中繼日誌。首先 slave 開始一個工作線程（I/O），I/O 線程在 master 上打開一個普通的連接，然後開始 binlog dump process。binlog dump process 從 master 的二進制日誌中讀取事件，如果已經跟上 master，它會睡眠並等待 master 產生新的事件，I/O 線程將這些事件寫入中繼日誌。
3） Sql slave thread（sql 從線程）處理該過程的最後一步，sql 線程從中繼日誌讀取事件，並重放其中的事件而更新 slave 數據，使其與 master 中的數據一致，只要該線程與 I/O 線程保持一致，中繼日誌通常會位於 os 緩存中，所以中繼日誌的開銷很小。
3.主從複製的幾種方式
-
同步複製: master 的變化，必須等待 slave-1,slave-2,…,slave-n 完成後才能返回。 這樣，顯然不可取，也不是 MySQL 複製的默認設置。比如，在 WEB 前端頁面上，用戶增加了條記錄，需要等待很長時間。
-
異步複製:如同 AJAX 請求一樣。master 只需要完成自己的數據庫操作即可。至於 slaves 是否收到二進制日誌，是否完成操作，不用關心，MySQL 的默認設置。
-
半同步複製:master 只保證 slaves 中的一個操作成功，就返回，其他 slave 不管。 這個功能，是由 google 爲 MySQL 引入的。
4.隨着應用的日益增長，讀操作很多，我們可以擴展 slave，但是如果 master 滿足不了寫操作了，怎麼辦呢？
可以分庫【垂直拆分】，分表【水平拆分】。
二、讀寫分離
讀寫分離就是在主服務器上修改，數據會同步到從服務器，從服務器只能提供讀取數據，不能寫入，實現備份的同時也實現了數據庫性能的優化，以及提升了服務器安全。
前較爲常見的 Mysql 讀寫分離分爲以下兩種：
1）基於程序代碼內部實現
在代碼中根據 select 、insert 進行路由分類，這類方法也是目前生產環境下應用最廣泛的。優點是性能較好，因爲程序在代碼中實現，不需要增加額外的硬件開支，缺點是需要開發人員來實現，運維人員無從下手。
2） 基於中間代理層實現
代理一般介於應用服務器和數據庫服務器之間，代理數據庫服務器接收到應用服務器的請求後根據判斷後轉發到，後端數據庫，有以下代表性的程序。
- mysql_proxy。mysql_proxy 是 Mysql 的一個開源項目，通過其自帶的 lua 腳本進行 sql 判斷。
不是所有的應用都能夠在基於程序代碼中實現讀寫分離，像一些大型的 java 應用，如果在程序代碼中實現讀寫分離對代碼的改動就較大，所以，像這種應用一般會考慮使用代理層來實現
【Java 面試那點事】
這裏致力於分享 Java 面試路上的各種知識，無論是技術還是經驗，你需要的這裏都有！
這裏可以讓你【快速瞭解 Java 相關知識】，並且【短時間在面試方面有跨越式提升】
面試路上，你不孤單！
