MySQL主從延遲讀寫分離問題怎樣解決

2024-07-24 12:32:55

字體：大中小

來源：轉載

供稿：網友

　　本文小編為大家詳細介紹“MySQL主從延遲、讀寫分離問題如何解決”，內容詳細，步驟清晰，細節處理妥當，希望這篇“MySQL主從延遲、讀寫分離問題如何解決”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來學習新知識吧。

　　我們都知道互聯網數據有個特性，大部分場景都是讀多寫少，比如：微博、微信、淘寶電商，按照二八原則，讀流量占比甚至能達到 90%

　　結合這個特性，我們對底層的數據庫架構也會做相應調整。采用讀寫分離

　　處理過程：

　　客戶端會集成 SDK，每次執行 SQL 時，會判斷是寫或讀操作

　　如果是寫 SQL，請求會發到主庫

　　主數據庫執行SQL，事務提交后，會生成 binlog ，并同步給從庫

　　從庫通過 SQL 線程回放 binlog ，并在從庫表中生成相應數據

　　如果是讀 SQL，請求會通過負載均衡策略，挑選一個從庫處理用戶請求

　　看似非常合理，細想卻不是那么回事

　　主庫與從庫是采用異步復制數據，如果這兩者之間數據還沒有同步怎么辦？

　　主庫剛寫完數據，從庫還沒來得及拉取最新數據，讀請求就來了，給用戶的感覺，數據丟了？？？

　　針對這個問題，今天，我們就來探討下有什么解決方案？

　　一、強制走主庫

　　針對不用的業務訴求，區別性對待

　　場景一：

　　如果是對數據的實時性要求不是很高，比如：大V有千萬粉絲，發布一條微博，粉絲晚幾秒鐘收到這條信息，并不會有特別大的影響。這時，可以走從庫。

　　場景二：

　　如果對數據的實時性要求非常高，比如金融類業務。我們可以在客戶端代碼標記下，讓查詢強制走主庫。

　　二、從庫延遲查詢

　　由于主從庫之間數據同步需要一定的時間間隔，那么有一種策略是延遲從從庫查詢數據。

　　比如：

　　select sleep(1)

　　select * from order where order_id=11111;

　　在正式的業務查詢時，先執行一個sleep 語句，給從庫預留一定的數據同步緩沖期。

　　因為是采用一刀切，當面對高并發業務場景時，性能會下降的非常厲害，一般不推薦這個方案。

　　三、判斷主從是否延遲？決定選主庫還是從庫

　　方案一：

　　比較 GTID 集合

　　Auto_Position=1 主從之間使用 GTID 協議

　　Retrieved_Gtid_Set 從庫收到的所有binlog日志的 GTID 集合

　　Executed_Gtid_Set 從庫已經執行完成的 GTID 集合

　　比較 Retrieved_Gtid_Set 和 Executed_Gtid_Set 的值是否相等

　　在執行業務SQL操作時，先判斷從庫是否已經同步最新數據。從而決定是操作主庫，還是操作從庫。

　　缺點：

　　無論采用上面哪一種方案，如果主庫的寫操作頻繁不斷，那么從庫的值永遠跟不上主庫的值，那么讀流量永遠是打在了主庫上。

　　針對這個問題，有什么解決方案？

　　這個問題跟 MQ消息隊列既要求高吞吐量又要保證順序是一樣的，從全局來看確實無解，但是縮小范圍就容易多了，我們可以保證一個分區內的消息有序。

　　回到主從庫之間的數據同步問題，從庫查詢哪條記錄，我們只要保證之前對應的寫binglog已經同步完數據即可，可以不用管主從庫的所有的事務binlog 是否同步。

　　問題是不是一下簡單多了

　　方案二：

　　在從庫執行命令 show slave status

　　查看 seconds_behind_master 的值，單位為秒，如果為 0，表示主備庫之間無延遲

　　方案三：

　　比較主從庫的文件點位

　　還是執行 show slave status，響應結果里有截個關鍵參數

　　Master_Log_File 讀到的主庫最新文件

　　Read_Master_Log_Pos 讀到的主庫最新文件的坐標位置

　　Relay_Master_Log_File 從庫執行到的最新文件

　　Exec_Master_Log_Pos 從庫執行到的最新文件的坐標位置

　　兩兩比較，上面的參數是否相等

　　四、從庫節點判斷主庫位點

　　在從庫執行下面命令，返回是一個正整數 M，表示從庫從參數節點開始執行了多少個事務

　　select master_pos_wait(file, pos[, timeout]);

　　file 和 pos 表示主庫上的文件名和位置

　　timeout 可選，表示這個函數最多等待 N 秒

　　缺點：

　　master_pos_wait 返回結果無法與具體操作的數據行做關聯，所以每次接收讀請求時，從庫還是無法確認是否已經同步數據，方案實用性不高。

　　5、比較 GTID

　　執行下面查詢命令

　　阻塞等待，直到從庫執行的事務中包含 gtid_set，返回 0

　　超時，返回 1

　　select wait_for_executed_gtid_set(gtid_set, 1);

　　MySQL 5.7.6 版本開始，允許在執行完更新類事務后，把這個事務的 GTID 返回給客戶端。具體操作，將參數session_track_gtids 設置為OWN_GTID，調用 API 接口mysql_session_track_get_first 返回結果解析出 GTID

　　處理流程：

　　發起寫 SQL 操作，在主庫成功執行后，返回這個事務的 GTID

　　發起讀 SQL 操作時，先在從庫執行 select wait_for_executed_gtid_set (gtid_set, 1)

　　如果返回 0，表示已經從庫已經同步了數據，可以在從庫執行查詢操作

　　否則，在主庫執行查詢操作

　　缺點：

　　跟上面的 master_pos_wait 類似，如果寫操作與讀操作沒有上下文關聯，那么 GTID 無法傳遞。方案實用性不高。

　　6、數據分片

　　MySQL主從延遲、讀寫分離問題如何解決

　　參考 Redis Cluster 模式，集群網絡拓撲通常是 3主 3從，主節點既負責寫，也負責讀。

　　通過水平分片，支持數據的橫向擴展。由于每個節點都是獨立的服務器，可以提高整體集群的吞吐量。

　　轉換到數據庫方面

　　常見的解決方式，是分庫分表，每次讀寫都是操作主庫的一個分表，從庫只用來做數據備份。當主庫發生故障時，主從切換，保證集群的高可用性。

　　讀到這里，這篇“MySQL主從延遲、讀寫分離問題如何解決”文章已經介紹完畢，想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領會。

（編輯：武林網）

上一篇：mysql里update會不會鎖表

下一篇：mysql設計概念多表查詢和事務制作實例分析