Mysql 的架構演化
3.1 來自海豚的告白
3.2 單節點數據庫
3.3 一主一從架構
3.4 Master/Slave 復制原理及方式
3.5 一主多從架構
3.6 雙主多從架構
3.7 Mysql Sharding
3.8 小張講解
3.9 課后作業
3.1 來自海豚的告白
"我是一只海豚，我很孤獨，我遨游在我的世界里，有很多人喜歡我，也有很多人厭惡我，可是，我還是我。"
這是一只Mysql 海豚的獨白。
他是那么的清高，那么的傲慢，好像動物世界里的一朵奇葩，正是因為他的輕盈、他的開放，即使他這樣傲慢無理，
還是有很多粉絲的追捧。
幾乎大部分的互聯網公司都會選用Mysql做為數據庫，體現在它的擴展性，mysql 可以架構出一個分布式集群，
相對于oracle 這種大型數據庫來說，他顯得靈活，輕盈，而且他還是開源免費的。
為什么mysql 在互聯網公司那么受到青睞， 因為互聯網公司相對于傳統企業來說，他的數據量增長的很快，單點數據庫
已經無法滿足數據的實時查詢和存儲的要求了，所以需要擴展數據庫架構。
Mysql數據庫架構的演化分為幾個階段：
單節點數據庫
一主一從架構
一主多從架構
雙主多從架構
對比上面的架構圖，來具體看看這幾種架構的區別。
3.2 單節點數據庫
大部分的童鞋接觸到的都是這種單節點的數據庫架構，
一個JAVA程序使用數據庫連接池操作一個數據庫，這個是不是很熟悉，就是J2EE的典型應用。
上點代碼看看，更熟悉一點
架構上面來說就是 一個應用連接一個數據庫 ，十分簡單，也就不多說了，如下圖：
3.3 一主一從架構
隨著互聯網訪問量的迅速增加、以及數據量的增大，單點數據庫會出現延遲，假死，更嚴重的出現崩潰的情況，在用戶端看到的現象會是這樣的
這種情況下，數據庫已經負擔不起這么大的壓力了，海豚自恃清高也沒用，于是有人想出用兩個海豚來解決這個問題，最簡單的就是這種一主一從的架構
兩只海豚
為什么要這樣子來架構呢？
這樣我們先來分析一下 造成系統性能的瓶頸在哪里
從硬件計算機系統來說 ， 系統的性能主要取決于
CPU, 內存, 磁盤I/O, 網絡I/O
再仔細分析
內存的 讀寫速度 是 24165M/s
機械硬盤的讀寫速度 在100M/s
網絡帶寬一般機房可以到 千兆帶寬
很明顯我們可以看出， 硬盤的讀寫速度跟內存 相差200多倍
很容易找出，我們系統的瓶頸在硬盤讀寫這一塊，當然這里只是簡單的推理
也有一些專業的工具對其進行測試
現在我們有兩個方法來解決這個問題：
1. 提高硬盤的讀寫速度，讓其達到內存的速度
2. 分攤壓力，把硬盤讀寫的壓力分攤到不同的節點上面
第一個方法那是硬盤廠商的事情了，我們控制不了，當然現在市面上也有讀寫快的，例如固態硬盤可以選配
我們要說的就是如何用現有的硬件來解決問題，也就是第二種方法。
我們再來分析業務：
數據庫的操作 insert , delete ,update ,select
在正式的生產環境中，我們會發現，對比insert 寫的操作，用戶更多的在 select 查詢上面的操作.
例如： 我們經常瀏覽新聞、逛淘寶，還在看我寫的這篇文章，這些都是在 進行 讀查詢.
那么我們一主一從的架構 就是 讓應用從 2個節點上面讀取， 來進行分攤壓力，
而這種從兩個節點上面讀取的策略 可以 通過 負載均衡來實現，意思就是說 如果有10個請求過來
把5個讀的請求轉發到 A 節點， 另外5個轉發到B節點上面。
那么這個一主一從是如何實現的呢？
可以通過 MySQL replication 復制的方式來做
選定一個節點的MySQL作為 master
另外一個節點的MySQL作為 slave
插入更新數據 我們通過 master 完成 ，
master 會通過 replication 的方式來完成 對 slave 的同步更新.
這時 slave 就會有相同的數據， 應用就可以通過 從 slave 讀取數據 來減輕 master 的壓力.
3.4 Master/Slave 復制原理及方式
1. Master 所有的數據更新會記錄到 日志 binlog 中，Master A 把binlog日志傳給 Slave B
2. B 先把 A 的binlog日志 放到 稱為 relaylog 中繼日志的 地方
3. 最后 B 通過relaylog 日志中的內容對自己的binlog 進行更新，復制數據。
從這種機制上我們可以看出，可以保證A 和 B 的數據一致，但是同步或許會有延時(不考慮網絡因素)
A 的執行可以并發執行， 等A 的 binlog 日志寫 到 B 的 relaylog ，然后 B 從relaylog 讀取復制到binlog
這個過程中會發生延時.
于是出現了
同步復制 的方式 ：
同步復制 是 用戶在前端訪問，Master收到 insert 請求，這個時候 需要 等待 slave 復制完成后確認，
才能返回結果給用戶，
顯然這種方式不可取，因為會造成用戶請求變的很慢的情況。
而這種方式也不是 MySQL的默認方式。
異步復制：
Master 只要完成自己的數據更新就返回結果給 用戶，
而同步在異步狀態下進行。 MySQL 默認設置。
半同步復制：
即是 如果slave 有很多個 ， 也是后面講的 一主多從的 架構下， master只要保證 其中一個slave 同步復制成功，
就返回結果給用戶端。
3.5 一主多從架構
一主一從 是 一主多從 架構中的特例， 一主一從學會了，很容易理解 一主多從的架構了
在Mysql 的配置上面區別不大，后面實戰進行架構的搭建會講到。
這里就不衍生開了。
3.6 雙主多從架構
為什么會有雙主多從架構出現呢，肯定是為了解決某種問題而產生的。
是的，當我們用了一主多從架構以后，我們會發現一個致命的問題， 當我有5個節點，
肯定是 1個Master ，另外4 個是 slave , 這個時候 master 就相當于是中心領導的地位，
他這么重要，如果master 崩掉了怎么辦，整個系統就不能正常運行了，
這個時候采用 雙主多從，來用副領導保證。
就像master1 是一個總經理， 如果總經理不舒服或者有事走開了
這個時候就由 master2 副總 來接替他的工作。
3.7 Mysql Sharding
master-slave 這種架構，不管是 一主多從 還是 雙主多從，我們發現他的性能瓶頸是在
master 上面，整個系統也并不是可以通過增加master 來達到性能的倍數增長的。
slave 越多，master 復制到 slave 的 日志越多，master 的負擔就越重，同步的延時就越大
會出現讀取到臟數據，以及數據不一致的問題。
問題出現了，新的架構也隨之而來。
一種分表分庫的分布式架構就出現了。
簡單來講，分表分庫 不是 在master 和 slave 之間進行數據復制 以減輕 讀的壓力。
而是把數據內容進行切分，分別放到不同的節點上 。
例如 ： 現在有10個用戶的數據
master-slave 的做法是 復制10個用戶的數據到 slave 下面去，這個時候整個系統就有10 * N個slave的數據量了。
而 分表分庫則是 其中5個用戶數據放到 A 節點上 ， 另外5個用戶數據放到B節點上，整個系統數據還是10個數據量。
這里簡單講這些，詳細的放到后面章節中來講。
在分表分庫我們用Mycat 中間件， 在每個節點的分庫中 ，我們還可以采用Master-Slave 這種架構 作為 混合架構使用。
3.8 小張講解
讀寫分離
通過MySQL replication 我們可以復制數據到不同的數據庫中， 但是上面講到讀取需要從不同的節點中讀取，
還要有策略作負載均衡，這個功能邏輯就需要應用來進行實現。（應用要連接不同的數據庫節點，分離讀寫）
市面上有很多成熟的中間件可以實現 負載均衡、讀寫分離，例如：MySQL-Proxy ,
應用層可以像 剛開始那樣代碼不變，所有的 讀寫分離工作交給 MySQL-Proxy中間件來實現。
MySQL replication
下一節中 ，我們具體來動手來做一個一主一從這種架構，通過配置MySQL的 replication ,以及在應用層進行
負載均衡、讀寫分離的實現，用最輕的方式來進行性能的最大提升。
3.9 課后作業
1. 什么是一主一從？
2. 同步有哪幾種方式？
3. 實驗：
> 安裝centos 7 操作系統
> 安裝mysql5.7 數據庫
> 進行一主一從的Mysql 數據庫架構
> 應用層實現一個DEMO ， 進行讀寫分離以及負載均衡
來自：http://www.jianshu.com/p/2e6b4e0f2ee5