一、主從讀寫分離
大部分網際網路業務都是讀多寫少,是以優先考慮DB如何支撐更高查詢數,首先就需要區分讀、寫流量,這才友善針對讀流量單獨擴充,即主從讀寫分離。
若前端流量突增導緻從庫負載過高,DBA會優先做個從庫擴容上去,這樣對DB的讀流量就會落到多個從庫,每個從庫的負載就降了下來,然後開發再盡力将流量擋在DB層之上。
Cache V.S MySQL讀寫分離 由于從開發和維護的難度考慮,引入緩存會引入複雜度,要考慮緩存資料一緻性,穿透,防雪崩等問題,并且也多元護一類元件。是以推薦優先采用讀寫分離,扛不住了再使用Cache。
1.core
主從讀寫分離一般将一個DB的資料拷貝為一或多份,并且寫入到其它的DB伺服器中:
- 原始DB為主庫,負責資料寫入
- 拷貝目标DB為從庫,負責資料查詢
是以主從讀寫分離的關鍵:
- 資料的拷貝 即主從複制
- 屏蔽主從分離帶來的通路DB方式的變化 讓開發人員使用感覺依舊在使用單一DB
二、主從複制
MySQL的主從複制依賴于binlog,即記錄MySQL上的所有變化并以二進制形式儲存在磁盤上二進制日志檔案。
主從複制就是将binlog中的資料從主庫傳輸到從庫,一般異步:主庫操作不會等待binlog同步完成。
1.主從複制的過程
- 從庫在連接配接到主節點時會建立一個I/O線程,以請求主庫更新的binlog,并把接收到的binlog寫入relay log檔案,主庫也會建立一個log dump線程發送binlog給從庫;
- 從庫還會建立一個SQL線程,讀relay log,并在從庫中做回放,最終實作主從的一緻性。
使用獨立的log dump線程是異步,避免影響主庫的主體更新流程,而從庫在接收到資訊後并不是寫入從庫的存儲,是寫入一個relay log,這是為避免寫入從庫實際存儲會比較耗時,最終造成從庫和主庫延遲變長。
主從異步複制的過程
基于性能考慮,主庫寫入流程并沒有等待主從同步完成就傳回結果,極端情況下,比如主庫上binlog還沒來得及落盤,就發生磁盤損壞或機器掉電,導緻binlog丢失,主從資料不一緻。不過機率很低,可容忍。
主庫當機後,binlog丢失導緻的主從資料不一緻也隻能手動恢複。
主從複制後,即可:
- 在寫入時隻寫主庫
- 在讀資料時隻讀從庫
這樣即使寫請求會鎖表或鎖記錄,也不會影響讀請求執行。高并發下,可部署多個從庫共同承擔讀流量,即一主多從支撐高并發讀。
從庫也能當成個備庫,以避免主庫故障導緻資料丢失。
那無限制地增加從庫就能支撐更高并發嗎?NO!從庫越多,從庫連接配接上來的I/O線程越多,主庫也要建立同樣多log dump線程處理複制的請求,對于主庫資源消耗較高,同時受限于主庫的網絡帶寬,是以一般一個主庫最多挂3~5個從庫。
2.主從複制的副作用
比如發朋友圈這一操作,就存在資料的:
- 同步操作,如更新DB
- 異步操作,如将朋友圈内容同步給稽核系統
是以更新完主庫後,會将朋友圈ID寫入MQ,由Consumer依據ID在從庫擷取朋友圈資訊再發給稽核系統。此時若主從DB存在延遲,會導緻在從庫取不到朋友圈資訊,出現異常!
主從延遲對業務的影響示意圖
3.避免主從複制的延遲
這咋辦呢?其實解決方案有很多,核心思想都是 盡量不去從庫查詢資料。是以針對上述案例,就有如下方案:
1)資料備援
可在發MQ時,不止發送朋友圈ID,而是發給Consumer需要的所有朋友圈資訊,避免從DB重新查詢資料。
推薦該方案,因為足夠簡單,不過可能造成單條消息較大,進而增加消息發送的帶寬和時間。
2)使用Cache
在同步寫DB的同時,把朋友圈資料寫Cache,這樣Consumer在擷取朋友圈資訊時,優先查詢Cache,這也能保證資料一緻性。
該方案适合新增資料的場景。若是在更新資料場景下,先更新Cache可能導緻資料不一緻。比如兩個線程同時更新資料:
- 線程A把Cache資料更新為1
- 另一個線程B把Cache資料更新為2
- 然後線程B又更新DB資料為2
- 線程A再更新DB資料為1
最終DB值(1)和Cache值(2)不一緻!
3)查詢主庫
可以在Consumer中不查詢從庫,而改為查詢主庫。
使用要慎重,要明确查詢的量級不會很大,是在主庫的可承受範圍之内,否則會對主庫造成較大壓力。
若非萬不得已,不要使用該方案。因為要提供一個查詢主庫的接口,很難保證其他人不濫用該方法。
主從同步延遲也是排查問題時容易忽略。有時會遇到從DB擷取不到資訊的詭異問題,會糾結代碼中是否有一些邏輯把之前寫入内容删除了,但發現過段時間再去查詢時又能讀到資料,這基本就是主從延遲問題。是以,一般把從庫落後的時間作為一個重點DB名額,做監控和報警,正常時間在ms級,達到s級就要告警。
主從的延遲時間預警,那如何通過哪個資料庫中的哪個名額來判别?
在從從庫中,通過監控show slave status\G指令輸出的Seconds_Behind_Master參數的值判斷,是否有發生主從延時。這個參數值是通過比較sql_thread執行的event的timestamp和io_thread複制好的 event的timestamp(簡寫為ts)進行比較,而得到的這麼一個內插補點。
但如果複制同步主庫bin_log日志的io_thread線程負載過高,則Seconds_Behind_Master一直為0,即無法預警,通過Seconds_Behind_Master這個值來判斷延遲是不夠準确。其實還可以通過比對master和slave的binlog位置。
三、如何通路DB
使用主從複制将資料複制到多個節點,也實作了DB的讀寫分離,這時,對DB的使用也發生了變化:
- 以前隻需使用一個DB位址。
- 現在需使用一個主庫位址,多個從庫位址,且需區分寫入操作和查詢操作,再結合“分庫分表”,複雜度大大提升。
為降低實作的複雜度,業界湧現了很多DB中間件解決DB的通路問題,大緻分為:
1.應用程式内部
如TDDL( Taobao Distributed Data Layer),以代碼形式内嵌運作在應用程式内部。可看成是一種資料源代理,它的配置管理多個資料源,每個資料源對應一個DB,可能是主庫或從庫。當有一個DB請求時,中間件将SQL語句發給某個指定資料源,然後傳回處理結果。
優點:
- 簡單易用,部署成本低,因為植入應用程式内部,與程式一同運作,适合運維較弱的小團隊。
缺點:
- 缺乏多語言支援,都是Java語言開發的,無法支援其他的語言。版本更新也依賴使用方的更新。
2.獨立部署的代理層方案
如Mycat、Atlas、DBProxy。
這類中間件部署在獨立伺服器,業務代碼如同在使用單一DB,實際上它内部管理着很多的資料源,當有DB請求時,它會對SQL語句做必要的改寫,然後發往指定資料源。
優點:
- 一般使用标準MySQL通信協定,是以可支援多種語言
- 獨立部署,是以友善維護更新,适合有運維能力的大中型團隊
缺點:
- 所有的SQL語句都需要跨兩次網絡:從應用到代理層和從代理層到資料源,是以在性能上會有一些損耗。
四、總結
可以把主從複制引申為存儲節點之間互相複制存儲資料的技術,可以實作資料備援,以達到備份和提升橫向擴充能力。
使用主從複制時,需考慮:
- 主從的一緻性和寫入性能的權衡:若保證所有從節點都寫入成功,則寫性能一定受影響;若隻寫主節點就傳回成功,則從節點就可能出現資料同步失敗,導緻主從不一緻。網際網路項目,一般優先考慮性能而非資料的強一緻性。
- 主從的延遲:會導緻很多詭異的讀取不到資料的問題。
很多實際案例:
- Redis通過主從複制實作讀寫分離
- Elasticsearch中存儲的索引分片也可被複制到多個節點
- 寫入到HDFS中,檔案也會被複制到多個DataNode中
不同元件對于複制的一緻性、延遲要求不同,采用的方案也不同,但設計思想是相通的。
FAQ
若大量訂單,通過userId hash到不同庫,對前台使用者訂單查詢有利,但背景系統頁面需檢視全部訂單且排序,SQL執行就很慢。這該怎麼辦呢?
由于背景系統不能直接查詢分庫分表的資料,可考慮将資料同步至一個單獨的背景庫或同步至ES。
作者丨小爬
來源丨easemob.com/news/7093
dbaplus社群歡迎廣大技術人員投稿,投稿郵箱:[email protected]
活動推薦
2024 XCOPS智能運維管理人年會·廣州站将于5月24日舉辦,深究大模型、AI Agent等新興技術如何落地于運維領域,賦能企業智能運維水準提升,建構全面運維自治能力!
會議詳情:2024 XCOPS智能運維管理人年會-廣州站