大部分互聯(lián)網(wǎng)業(yè)務(wù)都是讀多寫少，因此優(yōu)先考慮DB如何支撐更高查詢數(shù)，首先就需要區(qū)分讀、寫流量，這才方便針對讀流量單獨擴(kuò)展，即主從讀寫分離。

若前端流量突增導(dǎo)致從庫負(fù)載過高，DBA會優(yōu)先做個從庫擴(kuò)容上去，這樣對DB的讀流量就會落到多個從庫，每個從庫的負(fù)載就降了下來，然后開發(fā)再盡力將流量擋在DB層之上。

Cache V.S MySQL讀寫分離
由于從開發(fā)和維護(hù)的難度考慮，引入緩存會引入復(fù)雜度，要考慮緩存數(shù)據(jù)一致性，穿透，防雪崩等問題，并且也多維護(hù)一類組件。所以推薦優(yōu)先采用讀寫分離，扛不住了再使用Cache。

主從讀寫分離一般將一個DB的數(shù)據(jù)拷貝為一或多份，并且寫入到其它的DB服務(wù)器中：

• 原始DB為主庫，負(fù)責(zé)數(shù)據(jù)寫入

• 拷貝目標(biāo)DB為從庫，負(fù)責(zé)數(shù)據(jù)查詢

所以主從讀寫分離的關(guān)鍵：

• 數(shù)據(jù)的拷貝
  即主從復(fù)制

• 屏蔽主從分離帶來的訪問DB方式的變化
  讓開發(fā)人員使用感覺依舊在使用單一DB

MySQL的主從復(fù)制依賴于binlog，即記錄MySQL上的所有變化并以二進(jìn)制形式保存在磁盤上二進(jìn)制日志文件。

主從復(fù)制就是將binlog中的數(shù)據(jù)從主庫傳輸?shù)綇膸?，一般異步：主庫操作不會等待binlog同步完成。

• 從庫在連接到主節(jié)點時會創(chuàng)建一個I/O線程，以請求主庫更新的binlog，并把接收到的binlog寫入relay log文件，主庫也會創(chuàng)建一個log dump線程發(fā)送binlog給從庫

• 從庫還會創(chuàng)建一個SQL線程，讀relay log，并在從庫中做回放，最終實現(xiàn)主從的一致性

使用獨立的log dump線程是異步，避免影響主庫的主體更新流程，而從庫在接收到信息后并不是寫入從庫的存儲，是寫入一個relay log，這是為避免寫入從庫實際存儲會比較耗時，最終造成從庫和主庫延遲變長。

• 主從異步復(fù)制的過程

基于性能考慮，主庫寫入流程并沒有等待主從同步完成就返回結(jié)果，極端情況下，比如主庫上binlog還沒來得及落盤，就發(fā)生磁盤損壞或機(jī)器掉電，導(dǎo)致binlog丟失，主從數(shù)據(jù)不一致。不過概率很低，可容忍。

主庫宕機(jī)后，binlog丟失導(dǎo)致的主從數(shù)據(jù)不一致也只能手動恢復(fù)。

主從復(fù)制后，即可：

• 在寫入時只寫主庫

• 在讀數(shù)據(jù)時只讀從庫

這樣即使寫請求會鎖表或鎖記錄，也不會影響讀請求執(zhí)行。高并發(fā)下，可部署多個從庫共同承擔(dān)讀流量，即一主多從支撐高并發(fā)讀。

從庫也能當(dāng)成個備庫，以避免主庫故障導(dǎo)致數(shù)據(jù)丟失。

那無限制地增加從庫就能支撐更高并發(fā)嗎？
NO！從庫越多，從庫連接上來的I/O線程越多，主庫也要創(chuàng)建同樣多l(xiāng)og dump線程處理復(fù)制的請求，對于主庫資源消耗較高，同時受限于主庫的網(wǎng)絡(luò)帶寬，所以一般一個主庫最多掛3～5個從庫。

比如發(fā)朋友圈這一操作，就存在數(shù)據(jù)的：

• 同步操作
  如更新DB

• 異步操作
  如將朋友圈內(nèi)容同步給審核系統(tǒng)

所以更新完主庫后，會將朋友圈ID寫入MQ，由Consumer依據(jù)ID在從庫獲取朋友圈信息再發(fā)給審核系統(tǒng)。

此時若主從DB存在延遲，會導(dǎo)致在從庫取不到朋友圈信息，出現(xiàn)異常！

• 主從延遲對業(yè)務(wù)的影響示意圖
  

這咋辦呢？其實解決方案有很多，核心思想都是 盡量不去從庫查詢數(shù)據(jù)。因此針對上述案例，就有如下方案：

可在發(fā)MQ時，不止發(fā)送朋友圈ID，而是發(fā)給Consumer需要的所有朋友圈信息，避免從DB重新查詢數(shù)據(jù)。

推薦該方案，因為足夠簡單，不過可能造成單條消息較大，從而增加消息發(fā)送的帶寬和時間。

在同步寫DB的同時，把朋友圈數(shù)據(jù)寫Cache，這樣Consumer在獲取朋友圈信息時，優(yōu)先查詢Cache，這也能保證數(shù)據(jù)一致性。

該方案適合新增數(shù)據(jù)的場景。若是在更新數(shù)據(jù)場景下，先更新Cache可能導(dǎo)致數(shù)據(jù)不一致。比如兩個線程同時更新數(shù)據(jù)：

• 線程A把Cache數(shù)據(jù)更新為1

• 另一個線程B把Cache數(shù)據(jù)更新為2

• 然后線程B又更新DB數(shù)據(jù)為2

• 線程A再更新DB數(shù)據(jù)為1

最終DB值（1）和Cache值（2）不一致！

可以在Consumer中不查詢從庫，而改為查詢主庫。

使用要慎重，要明確查詢的量級不會很大，是在主庫的可承受范圍之內(nèi)，否則會對主庫造成較大壓力。

若非萬不得已，不要使用該方案。因為要提供一個查詢主庫的接口，很難保證其他人不濫用該方法。

主從同步延遲也是排查問題時容易忽略。
有時會遇到從DB獲取不到信息的詭異問題，會糾結(jié)代碼中是否有一些邏輯把之前寫入內(nèi)容刪除了，但發(fā)現(xiàn)過段時間再去查詢時又能讀到數(shù)據(jù)，這基本就是主從延遲問題。
所以，一般把從庫落后的時間作為一個重點DB指標(biāo)，做監(jiān)控和報警，正常時間在ms級，達(dá)到s級就要告警。

主從的延遲時間預(yù)警，那如何通過哪個數(shù)據(jù)庫中的哪個指標(biāo)來判別？在從從庫中，通過監(jiān)控show slave
status\G命令輸出的Seconds_Behind_Master參數(shù)的值判斷，是否有發(fā)生主從延時。
這個參數(shù)值是通過比較sql_thread執(zhí)行的event的timestamp和io_thread復(fù)制好的
event的timestamp(簡寫為ts)進(jìn)行比較，而得到的這么一個差值。
但如果復(fù)制同步主庫bin_log日志的io_thread線程負(fù)載過高，則Seconds_Behind_Master一直為0，即無法預(yù)警，通過Seconds_Behind_Master這個值來判斷延遲是不夠準(zhǔn)確。其實還可以通過比對master和slave的binlog位置。

使用主從復(fù)制將數(shù)據(jù)復(fù)制到多個節(jié)點，也實現(xiàn)了DB的讀寫分離，這時，對DB的使用也發(fā)生了變化：

• 以前只需使用一個DB地址

• 現(xiàn)在需使用一個主庫地址，多個從庫地址，且需區(qū)分寫入操作和查詢操作，再結(jié)合“分庫分表”，復(fù)雜度大大提升。

為降低實現(xiàn)的復(fù)雜度，業(yè)界涌現(xiàn)了很多DB中間件解決DB的訪問問題，大致分為：

如TDDL（ Taobao Distributed Data Layer），以代碼形式內(nèi)嵌運行在應(yīng)用程序內(nèi)部。可看成是一種數(shù)據(jù)源代理，它的配置管理多個數(shù)據(jù)源，每個數(shù)據(jù)源對應(yīng)一個DB，可能是主庫或從庫。
當(dāng)有一個DB請求時，中間件將SQL語句發(fā)給某個指定數(shù)據(jù)源，然后返回處理結(jié)果。

簡單易用，部署成本低，因為植入應(yīng)用程序內(nèi)部，與程序一同運行，適合運維較弱的小團(tuán)隊。

缺乏多語言支持，都是Java語言開發(fā)的，無法支持其他的語言。版本升級也依賴使用方的更新。

如Mycat、Atlas、DBProxy。

這類中間件部署在獨立服務(wù)器，業(yè)務(wù)代碼如同在使用單一DB，實際上它內(nèi)部管理著很多的數(shù)據(jù)源，當(dāng)有DB請求時，它會對SQL語句做必要的改寫，然后發(fā)往指定數(shù)據(jù)源。

• 一般使用標(biāo)準(zhǔn)MySQL通信協(xié)議，所以可支持多種語言

• 獨立部署，所以方便維護(hù)升級，適合有運維能力的大中型團(tuán)隊

所有的SQL語句都需要跨兩次網(wǎng)絡(luò)：從應(yīng)用到代理層和從代理層到數(shù)據(jù)源，所以在性能上會有一些損耗。

可以把主從復(fù)制引申為存儲節(jié)點之間互相復(fù)制存儲數(shù)據(jù)的技術(shù)，可以實現(xiàn)數(shù)據(jù)冗余，以達(dá)到備份和提升橫向擴(kuò)展能力。

使用主從復(fù)制時，需考慮：

• 主從的一致性和寫入性能的權(quán)衡
  若保證所有從節(jié)點都寫入成功，則寫性能一定受影響；若只寫主節(jié)點就返回成功，則從節(jié)點就可能出現(xiàn)數(shù)據(jù)同步失敗，導(dǎo)致主從不一致?；ヂ?lián)網(wǎng)項目，一般優(yōu)先考慮性能而非數(shù)據(jù)的強(qiáng)一致性

• 主從的延遲
  會導(dǎo)致很多詭異的讀取不到數(shù)據(jù)的問題

業(yè)界也有很多實際應(yīng)用案例：

• Redis通過主從復(fù)制實現(xiàn)讀寫分離

• Elasticsearch中存儲的索引分片也可被復(fù)制到多個節(jié)點

• 寫入到HDFS中，文件也會被復(fù)制到多個DataNode中

不同組件對于復(fù)制的一致性、延遲要求不同，采用的方案也不同，但設(shè)計思想是相通的。

FAQ

若大量訂單，通過userId hash到不同庫，對前臺用戶訂單查詢有利，但后臺系統(tǒng)頁面需查看全部訂單且排序，SQL執(zhí)行就很慢。這該怎么辦呢？

由于后臺系統(tǒng)不能直接查詢分庫分表的數(shù)據(jù)，可考慮將數(shù)據(jù)同步至一個單獨的后臺庫或同步至ES。