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。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/9tQ3IZiCkaxSXtj8r1PZbw