1.MySQL主從複製
在我們進行系統架構時，MySQL的master-slave模式是我們經常採用的一種模式。
為什麼要用這種模式呢？
a. 系統擴展性
擴展性是搭建系統要考慮的重要指標之一，在系統初期，我們採用單庫模式，快速開發上線，db承載著系統所有的讀寫操作，隨著系統負載的增加，
單個數據庫很容易成為瓶頸。主從複製，讓寫入和更新操作在主庫，從庫分擔讀操作；
b.負載均衡
對於讀遠大於寫的系統，這種架構優化效果明顯，通過nginx或lvs等一些軟件，我們可以達到負載均衡的效果。
c.更好的數據安全性
在單庫中，如果db出了問題，會造成整個系統癱瘓，功能無法使用，而在主從模式中，如果主庫宕機，從庫還是可以提供讀服務，而且可以切換成
主庫進行讀寫操作，將影響降到最低。
那麼有了主從架構，是不是db不需要備份了呢，當然不是，備份和主從是為了解決不同的問題，如果你誤操作了數據表，主從最終會一致，如果沒有備份，數據就無法恢復了，備份還是必須的，主從是讓你的系統更健壯。
d.系統升級
作為程序猿，系統升級是家常便飯了，你的系統是怎麼升級的呢；
停服-更新-開服，是這樣嗎，今天系統升級，估計又要通宵了，是不是讓人很崩潰呢！
滾動升級，升級從庫，從庫提供服務，然後升級主庫，主庫再作為從庫！
其實不僅僅是數據庫，我們的web服務器、緩存服務、隊列服務的集群升級都可以採用這種方法。
一般主從架構是這個樣子的
master-slave架構
2. 主從複製過程：
MySQL的主從複製是通過binlog進行的，步驟如下：
a.主庫寫binlog
b.從庫向master詢問是否有寫入
c.master上的binlog轉儲線程向IO線程發送binlog
d.slave把binlog寫入自己的中繼log中
e.slave對中繼log事件進行回放。
大致流程如下：
m-s同步流程
3.需要注意的問題
引入主從架構，是不是就高枕無憂了呢，當然不是，凡事都有兩面性，沒有完美的方案。
我們看一下對系統的影響：
a.性能上：主從複製對系統的影響主要在於binlog產生的IO開銷，從庫越多，開銷越大；
b.功能延時：主從之間的sql線程和IO線程是異步的，所以主從之間會有延時。而且延時時間是不可控的，如果是多級複製，延時就更多。
當我們引入一個方案時，如何衡量好壞：
首先看它解決了什麼問題，會帶來哪些問題，很多方案都是一個權衡的過程。
對於性能的影響，開啟binlog大概有1%的影響，對於高可用系統，這點性能損耗是可以接受的；
對於延時問題，數據敏感場景，我們一般採用讀主庫，或寫cache；數據不敏感的場景，如後臺功能、點贊、閱讀量統計等這些，用戶並不在乎。
最後：
對於一個數據庫來說，最重要的是數據完整性，集群數據一致性，如果意外宕機，在單庫場景，MySQL通過redo日誌保證事務數據完整性，而主從模式下，主從通過binlog保證主從的一致性，那麼redo日誌和binlog會不會不一致，MySQL是如何保證兩個日誌的一致性呢，下篇文章我們再詳細說。
redo流程圖
