MySQL如何支撐起億級流量

1 主從讀寫分離

大部分互聯網業務都是讀多寫少,因此優先考慮DB如何支撐更高查詢數,首先就需要區分讀、寫流量,這才方便針對讀流量單獨擴展,即主從讀寫分離。

若前端流量突增導致從庫負載過高,DBA會優先做個從庫擴容上去,這樣對DB的讀流量就會落到多個從庫,每個從庫的負載就降瞭下來,然後開發再盡力將流量擋在DB層之上。

Cache V.S MySQL讀寫分離
由於從開發和維護的難度考慮,引入緩存會引入復雜度,要考慮緩存數據一致性,穿透,防雪崩等問題,並且也多維護一類組件。所以推薦優先采用讀寫分離,扛不住瞭再使用Cache。

1.1 core

主從讀寫分離一般將一個DB的數據拷貝為一或多份,並且寫入到其它的DB服務器中:

  • 原始DB為主庫,負責數據寫入
  • 拷貝目標DB為從庫,負責數據查詢

所以主從讀寫分離的關鍵:

  • 數據的拷貝

即主從復制

  • 屏蔽主從分離帶來的訪問DB方式的變化

讓開發人員使用感覺依舊在使用單一DB

2 主從復制

MySQL的主從復制依賴於binlog,即記錄MySQL上的所有變化並以二進制形式保存在磁盤上二進制日志文件。

主從復制就是將binlog中的數據從主庫傳輸到從庫,一般異步:主庫操作不會等待binlog同步完成。

2.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.2 主從復制的副作用

比如發朋友圈這一操作,就存在數據的:

  • 同步操作

如更新DB

  • 異步操作

如將朋友圈內容同步給審核系統

所以更新完主庫後,會將朋友圈ID寫入MQ,由Consumer依據ID在從庫獲取朋友圈信息再發給審核系統。
此時若主從DB存在延遲,會導致在從庫取不到朋友圈信息,出現異常!

主從延遲對業務的影響示意圖

 

2.3 避免主從復制的延遲

這咋辦呢?其實解決方案有很多,核心思想都是 盡量不去從庫查詢數據。因此針對上述案例,就有如下方案:

2.3.1 數據冗餘

可在發MQ時,不止發送朋友圈ID,而是發給Consumer需要的所有朋友圈信息,避免從DB重新查詢數據。

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

2.3.2 使用Cache

在同步寫DB的同時,把朋友圈數據寫Cache,這樣Consumer在獲取朋友圈信息時,優先查詢Cache,這也能保證數據一致性。

該方案適合新增數據的場景。若是在更新數據場景下,先更新Cache可能導致數據不一致。比如兩個線程同時更新數據:

  • 線程A把Cache數據更新為1
  • 另一個線程B把Cache數據更新為2
  • 然後線程B又更新DB數據為2
  • 線程A再更新DB數據為1

最終DB值(1)和Cache值(2)不一致!

2.3.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位置。

3 如何訪問DB

使用主從復制將數據復制到多個節點,也實現瞭DB的讀寫分離,這時,對DB的使用也發生瞭變化:

  • 以前隻需使用一個DB地址
  • 現在需使用一個主庫地址,多個從庫地址,且需區分寫入操作和查詢操作,再結合“分庫分表”,復雜度大大提升。

為降低實現的復雜度,業界湧現瞭很多DB中間件解決DB的訪問問題,大致分為:

3.1 應用程序內部

如TDDL( Taobao Distributed Data Layer),以代碼形式內嵌運行在應用程序內部。可看成是一種數據源代理,它的配置管理多個數據源,每個數據源對應一個DB,可能是主庫或從庫。
當有一個DB請求時,中間件將SQL語句發給某個指定數據源,然後返回處理結果。

優點

簡單易用,部署成本低,因為植入應用程序內部,與程序一同運行,適合運維較弱的小團隊。

缺點

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

3.2 獨立部署的代理層方案

如Mycat、Atlas、DBProxy。

這類中間件部署在獨立服務器,業務代碼如同在使用單一DB,實際上它內部管理著很多的數據源,當有DB請求時,它會對SQL語句做必要的改寫,然後發往指定數據源。

優點

  • 一般使用標準MySQL通信協議,所以可支持多種語言
  • 獨立部署,所以方便維護升級,適合有運維能力的大中型團隊

缺點

  • 所有的SQL語句都需要跨兩次網絡:從應用到代理層和從代理層到數據源,所以在性能上會有一些損耗。

4 總結

可以把主從復制引申為存儲節點之間互相復制存儲數據的技術,可以實現數據冗餘,以達到備份和提升橫向擴展能力。

使用主從復制時,需考慮:

  • 主從的一致性和寫入性能的權衡

若保證所有從節點都寫入成功,則寫性能一定受影響;若隻寫主節點就返回成功,則從節點就可能出現數據同步失敗,導致主從不一致。互聯網項目,一般優先考慮性能而非數據的強一致性

  • 主從的延遲

會導致很多詭異的讀取不到數據的問題

很多實際案例:

  • Redis通過主從復制實現讀寫分離
  • Elasticsearch中存儲的索引分片也可被復制到多個節點
  • 寫入到HDFS中,文件也會被復制到多個DataNode中

不同組件對於復制的一致性、延遲要求不同,采用的方案也不同,但設計思想是相通的。

FAQ

若大量訂單,通過userId hash到不同庫,對前臺用戶訂單查詢有利,但後臺系統頁面需查看全部訂單且排序,SQL執行就很慢。這該怎麼辦呢?

由於後臺系統不能直接查詢分庫分表的數據,可考慮將數據同步至一個單獨的後臺庫或同步至ES。

到此這篇關於MySQL如何支撐起億級流量的文章就介紹到這瞭,更多相關MySQL 億級流量內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet!

推薦閱讀: