一主多從架構主要應用場景：讀寫分離。讀寫分離的主要目標是分攤主庫的壓力。
讀寫分離架構
讀寫分離架構一
架構一結構圖：
這種結構模式下，一般會把數據庫的連接信息放在客戶端的連接層，由客戶端主動做負載均衡。也就是說由客戶端來選擇后端數據庫進行查詢。
讀寫分離架構二
架構二結構圖：
該架構模式下，在MySQL和客戶端之間有一個中間代理層proxy， 客戶端只連接proxy， 由proxy根據請求類型和上下文決定請求的分發路由。
兩種架構的區別
1）客戶端直連方案
因為少了一層proxy轉發， 所以查詢性能稍微好一點兒， 并且整體架構簡單， 排查問題更方便。 但是這種方案， 由于要了解后端部署細節， 所以在出現主備切換、 庫遷移等操作的時候， 客戶端都會感知到， 并且需要調整數據庫連接信息。
你可能會覺得這樣客戶端也太麻煩了， 信息大量冗余， 架構很丑。 其實也未必， 一般采用這樣的架構， 一定會伴隨一個負責管理后端的組件， 比如Zookeeper， 盡量讓業務端只專注于業務邏輯開發。
2）帶proxy架構
帶proxy的架構， 對客戶端比較友好。 客戶端不需要關注后端細節， 連接維護、 后端信息維護等工作， 都是由proxy完成的。 但這樣的話， 對后端維護團隊的要求會更高。 而且， proxy也需要有高可用架構。 因此， 帶proxy架構的整體就相對比較復雜。
注：無論使用哪種架構都會遇到主從延遲問題（即在從庫上會讀到系統的一個過期狀態），且主從延遲是不能100%避免的。
問：處理主從延遲有哪些方案？
答：主從延遲處理方案有以下幾種：
- 強制走主庫方案
- Sleep方案
- 判斷主備無延遲方案
- 配合semi-sync方案
- 等主庫位點方案
- 等GTID方案
下面對這幾種方案詳細介紹。
強制走主庫方案
強制走主庫方案思路：對查詢請求進行分類，對于必須要拿到最新結果的請求，強制將其發到主庫上。對于可以讀到舊數據的請求，才將其發到從庫上。
這個方案最大的問題在于， 有時候你會碰到“所有查詢都不能是過期讀”的需求， 比如一些金融類的業務。 這樣的話， 你就要放棄讀寫分離， 所有讀寫壓力都在主庫， 等同于放棄了擴展性。
盡管如此，該方案仍是用的最多的一種方案。
Sleep方案
Sleep方案思路：主庫更新后， 讀從庫之前先sleep一下。 具體的方案就是， 類似于執行一條select sleep(1)命令。
注：這個方案的假設是， 大多數情況下主備延遲在1秒之內， 做一個sleep可以有很大概率拿到最新的數據。
示例：
以賣家發布商品為例， 商品發布后， 用Ajax（Asynchronous JavaScript + XML， 異步JavaScript和XML） 直接把客戶端輸入的內容作為“新的商品”顯示在頁面上， 而不是真正地去數據庫做查詢。
這樣， 賣家就可以通過這個顯示， 來確認產品已經發布成功了。 等到賣家再刷新頁面， 去查看商品的時候， 其實已經過了一段時間， 也就達到了sleep的目的， 進而也就解決了過期讀的問題。
但從嚴格意義上來說，這個方案存在不精確問題。這個不精確主要包含兩層意思：
1）假設一個查詢請求原本可以在0.5s就可以在從庫上拿到正確結果，此時也會等1s。
2）如果延遲超過1s，還是會出現主從延遲。
判斷主備無延遲方案
確保備庫無延遲，通常有以下三種做法：
查看seconds_behind_master確保主備無延遲
每次從庫執行查詢請求前，先執行show slave status\G判斷seconds_behind_master是否已經等于0。 如果還不等于0 ， 那就必須等到這個參數變為0才能執行查詢請求。注：seconds_behind_master的單位是秒。show slave status\G結果的部分截圖：
對比位點確保主備無延遲
1）Master_Log_File和Read_Master_Log_Pos， 表示的是讀到的主庫的最新位點。
2）Relay_Master_Log_File和Exec_Master_Log_Pos， 表示的是備庫執行的最新位點。
如果Master_Log_File和Relay_Master_Log_File、 Read_Master_Log_Pos和Exec_Master_Log_Pos這兩組值完全相同， 就表示接收到的日志已經同步完成。
show slave status\G結果部分截圖：
對比GTID集合確保主備無延遲
1）Auto_Position=1 ， 表示這對主備關系使用了GTID協議。
2）Retrieved_Gtid_Set， 是備庫收到的所有日志的GTID集合。
3）Executed_Gtid_Set， 是備庫所有已經執行完成的GTID集合。
如果這兩個集合相同， 也表示備庫接收到的日志都已經同步完成。
可見， 對比位點和對比GTID這兩種方法， 都要比判斷seconds_behind_master是否為0更準確。
show slave status\G結果部分截圖：
問：在執行查詢請求之前， 先判斷從庫是否同步完成的方法， 相比于sleep方案， 準確度確實提升了不少， 但還是沒有達到“精確”的程度。 為什么這么說呢？
一個事務的binlog在主備庫之間的狀態：
1）主庫執行完成， 寫入binlog， 并反饋給客戶端。
2）binlog被從主庫發送給備庫， 備庫收到。
3）在備庫執行binlog完成。
上面判斷主備無延遲的邏輯， 是“備庫收到的日志都執行完成了”。 但是， 從binlog在主備之間狀態的分析中， 不難看出還有一部分日志， 處于客戶端已經收到提交確認， 而備庫還沒收到日志的狀態。
示例場景如下：
這時， 主庫上執行完成了三個事務trx1、 trx2和trx3， 其中：
1）trx1和trx2已經傳到從庫， 并且已經執行完成了。
2）trx3在主庫執行完成， 并且已經回復給客戶端， 但是還沒有傳到從庫中。
如果這時候你在從庫B上執行查詢請求， 按照我們上面的邏輯， 從庫認為已經沒有同步延遲， 但還是查不到trx3的。 嚴格地說， 就是出現了主從延遲。
配合semi-sync方案
該方案可以解決“對比GTID集合確保主備無延遲”中提到的不“精確”問題。
semi-sync replication（半同步復制）主備間的狀態：
1）事務提交的時候，主庫把binlog發給從庫。
2）從庫收到binlog后，給主庫返回一個ack，表示收到了。
3）主庫收到這個ack后，才能給客戶端返回“事務完成”的確認。
也就是說，如果啟用了semi-sync， 就表示所有給客戶端發送過確認的事務， 都確保了備庫已經收到了這個日志。
問1：如果主庫掉電的時候，有些binlog還來不及發給從庫，會不會導致系統數據丟失？
1）如果使用的是普通的異步復制模式，則有可能會丟失數據。
2）如果使用的是semi-sync+位點判斷的方案，則可以解決數據丟失問題。
需要注意的是，semi-sync+位點判斷的方案，只對一主一備的場景成立。在一主多從場景中，主庫只要等到一個從庫的ack，就會開始給客戶端返回確認。此時，在從庫上執行查詢請求，有以下兩種情況：
1）如果查詢落在這個響應了ack的從庫上，能夠確保讀到最新數據。
2）如果查詢落到其它從庫上，他們可能還沒有收到最新的日志，就可能會產生主從延遲。
注：如果在業務高峰期， 主庫的位點或者GTID集合更新很快， 那么上面的兩個位點等值判斷就會一直不成立， 很可能出現從庫上遲遲無法響應查詢請求的情況。
問2：當發起一個查詢請求后，如果要求得到準確結果，是否需要等到“主備完全同步”，才能執行查詢請求？
答：不需要。
示例如下：
圖中備庫B下的虛線框， 分別表示relaylog（備庫執行的最新位點）和binlog中的事務。 可以看到， 圖中從狀態1 到狀態4， 一直處于延遲一個事務的狀態。
備庫B一直到狀態4都和主庫A存在延遲， 如果用上面必須等到無延遲才能查詢的方案， select語句直到狀態4都不能被執行。
但是， 其實客戶端是在發完trx1更新后發起的select語句， 我們只需要確保trx1已經執行完成就可以執行select語句了。 也就是說， 如果在狀態3執行查詢請求， 得到的就是預期結果了。
semi-sync+主備無延遲方案，存在兩個問題：
1）一主多從的時候， 在某些從庫執行查詢請求會存在主從延遲問題。
2）在持續延遲的情況下， 可能出現過度等待的問題。
等主庫位點方案
該方案能解決“semi-sync+主備無延遲方案”存在的兩個問題。
下面先來看一條命令：
select master_pos_wait(file, pos[, timeout]);這條命令的邏輯如下：
1）它是在從庫執行的。
2）參數file和pos指的是主庫上的文件名和位置。
3）timeout可選， 設置為正整數N表示這個函數最多等待N秒。
這條命令返回結果如下：
1）如果執行期間， 備庫同步線程發生異常， 則返回NULL。
2）如果等待超過N秒， 就返回-1。
3）如果剛開始執行的時候， 就發現已經執行過這個位置了， 則返回0。
4）如果返回的是一個正整數M， 表示從命令開始執行， 到應用完file和pos表示的binlog位置， 執行了多少事務。
對于上圖中先執行trx1， 再執行一個查詢請求的邏輯， 要保證能夠查到正確的數據， 我們可以使用這個邏輯：
1）trx1事務更新完成后， 馬上執行show master status得到當前主庫執行到的File和Position。
2）選定一個從庫執行查詢語句。
3）在從庫上執行select master_pos_wait(File, Position, 1)。
4）如果返回值是>=0的正整數， 則在這個從庫執行查詢語句。
5）否則， 到主庫執行查詢語句。
上述邏輯流程圖：
這里我們假設， 這條select查詢最多在從庫上等待1秒。 那么， 如果1秒內master_pos_wait返回一個大于等于0的整數， 就確保了從庫上執行的這個查詢結果一定包含了trx1的數據。
步驟5到主庫執行查詢語句， 是這類方案常用的退化機制（兜底方案）。 因為從庫的延遲時間不可控， 不能無限等待， 所以如果等待超時， 就應該放棄， 然后到主庫去查。
GTID方案
MySQL中同樣提供了一個類似的命令：
select wait_for_executed_gtid_set(gtid_set, 1);這條命令的邏輯是：
1）等待， 直到這個庫執行的事務中包含傳入的gtid_set， 返回0。
2）超時返回1。
在前面等位點的方案中， 我們執行完事務后， 還要主動去主庫執行show master status。 而MySQL 5.7.6版本開始， 允許在執行完更新類事務后， 把這個事務的GTID返回給客戶端， 這樣等GTID的方案就可以減少一次查詢。
等GTID的執行流程：
1）trx1事務更新完成后， 從返回包直接獲取這個事務的GTID， 記為gtid1。
2）選定一個從庫執行查詢語句。
3）在從庫上執行 select wait_for_executed_gtid_set(gtid1, 1)。
4）如果返回值是0， 則在這個從庫執行查詢語句。
5）否則， 到主庫執行查詢語句。
上述邏輯流程圖：
問：怎么能夠讓MySQL在執行事務后， 返回包中帶上GTID呢？
答：把參數session_track_gtids設置為OWN_GTID， 然后通過API接口mysql_session_track_get_first從返回包解析出GTID的值即可。
小結：思考題
思考：假設你的系統采用了等GTID的方案， 現在你要對主庫的一張大表做DDL，在做讀寫分離時可能會出現什么情況呢？ 為了避免這種情況， 你會怎么做呢？
假設，這條語句在主庫上要執行10分鐘，提交后傳到備庫就要10分鐘（典型的大事務）。那么，在主庫DDL之后再提交的事務的GTID，去備庫查的時候，就會等10分鐘才出現。
這樣，這個讀寫分離機制在這10分鐘之內都會超時，然后走主庫。
這種預期內的操作，應該在業務低峰期的時候，確保主庫能夠支持所有業務查詢，然后把讀請求都切到主庫，再在主庫上做DDL。等備庫延遲追上以后，再把讀請求切回備庫。
通過這個思考題，我主要想讓關注的是，大事務對等位點方案的影響。
當然了，使用gh-ost方案來解決這個問題也是不錯的選擇。
)
)
