參考文檔:html
http://www.cnblogs.com/crazylqy/p/5542558.html前端
http://www.cnblogs.com/gl-developer/p/6170423.htmljava
https://mp.weixin.qq.com/s?__biz=MzAxMTEyOTQ5OQ==&mid=400643724&idx=1&sn=82e5b5ec9e0567abea4cc1d960265d9e#rdmysql
https://www.jianshu.com/p/89ad5129a8b7sql
在實際的生產環境中,若是把對數據庫的讀和寫操做都放在同一個數據庫服務器上來進行,不管從安全性、高可用性仍是高併發等各個方面都是不可取的。所以,通常來講都是經過主從複製(Master-Slave)的方式來同步數據,再經過讀寫分離(MySQL-Proxy)來提高數據庫的併發負載能力。以下圖所示:數據庫
主從複製和讀寫分離的好處:後端
1. 將讀操做和寫操做分離到不一樣的數據庫上,避免主服務器出現性能瓶頸;緩存
2. 主服務器進行寫操做時,不影響查詢應用服務器的查詢性能,下降阻塞,提升併發;安全
3. 數據擁有多個容災副本,提升數據安全性,同時當主服務器故障時,可當即切換到其餘服務器,提升系統可用性;服務器
1. MySQL支持的複製類型
2.主從複製的工做過程
a. 在每一個事務更新數據完成以前,master在二進制日誌記錄(binary log)這些改變。寫入二進制日誌完成後,master通知存儲引擎提交事務。
b. Slave將master的binary log複製到其中繼日誌(Relay log)。首先slave開始一個工做線程(I/O),I/O線程在master上打開一個普通的鏈接,而後開始binlog dump process。binlog dump process從master的二進制日誌中讀取事件,若是已經跟上master,它會睡眠並等待master產生新的事件,I/O線程將這些事件寫入中繼日誌。
c. Sql slave thread(sql從線程)處理該過程的最後一步,sql線程從中繼日誌讀取事件,並重放其中的事件而更新slave數據,使其與master中的數據一致,只要該線程與I/O線程保持一致,中繼日誌一般會位於os緩存中,因此中繼日誌的開銷很小。
整個過程以下圖所示:
3. 主從複製的三種方式
所謂的同步複製,意思是master的變化,必須等待slave-1,slave-2,...,slave-n完成後才能返回。
這樣,顯然不可取,也不是MYSQL複製的默認設置。好比,在WEB前端頁面上,用戶增長了條記錄,須要等待很長時間。
master只保證slaves中的一個操做成功,就返回,其餘slave無論。
這個功能,是由google爲MYSQL引入的。
讀寫分離指的是在主服務器上進行修改操做(如insert/delete/update這些更新數據庫的操做),從服務器只能提供讀取數據(select),不能寫入。這樣,在實現了備份的同時也實現了數據庫性能的優化,以及提高了服務器安全。以下圖所示:
目前較爲常見的MySQL讀寫分離分爲如下兩種:
1. 基於程序代碼內部實現
在代碼中根據select 、insert進行路由分類,這類方法也是目前生產環境下應用最普遍的。優勢是性能較好,由於程序在代碼中實現,不須要增長額外的硬件開支,缺點是須要開發人員來實現,運維人員無從下手。
2.基於中間代理層實現
代理通常介於應用服務器和數據庫服務器之間,代理數據庫服務器接收到應用服務器的請求後根據判斷後轉發到後端數據庫。代理有如下表明性的程序。
通過上述簡單的比較,不是全部的應用都可以在基於程序代碼中實現讀寫分離,像一些大型的java應用,若是在程序代碼中實現讀寫分離對代碼的改動就較大,因此,像這種應用通常會考慮使用代理層來實現。