這篇文章主要介紹了Mysql讀寫分離過期常用解決方案,文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值,需要的朋友可以參考下
mysql讀寫分離的坑
讀寫分離的主要目標是分攤主庫的壓力，由客戶端選擇后端數(shù)據(jù)庫進行查詢。還有種架構就是在MYSQL和客戶端之間有一個中間代理層proxy，客戶端之連接proxy，由proxy根據(jù)請求類型和上下文決定請求的分發(fā)路由。
客戶端直連方案：因為少了一層proxy轉發(fā)，所以查詢性能稍微好一點兒，并且整體架構簡單，排查問題更方便。但是這種方案，由于要了解后端部署細節(jié)，所以在出現(xiàn)主備切換、庫遷移等操作的時候，客戶端都會感知到，并且需要調整數(shù)據(jù)庫連接信息。
帶proxy架構：對客戶端比較友好?？蛻舳瞬恍枰P注后端細節(jié)，連接維護、后端信息維護等工作，都是由proxy完成的。但這樣的話，對后端維護團隊的要求會更高。
無論使用哪種架構，由于主從可能存在延遲，客戶端執(zhí)行完一個更新事務后馬上發(fā)起查詢，如果查詢選擇的是從庫的話，就有可能讀到剛剛的事務更新之前的狀態(tài)。這種“在從庫上會讀到系統(tǒng)的一個過期狀態(tài)”的現(xiàn)象，我們暫且稱之為“過期讀”。
方案一：強制走主庫方案
將查詢請求分為兩類：
對于必須要拿到最新結果的請求，強制將其發(fā)到主庫上。比如，在一個交易平臺上，賣家發(fā)布商品以后，馬上要返回主頁面，看商品是否發(fā)布成功。那么，這個請求需要拿到最新的結果，就必須走主庫。
對于可以讀到舊數(shù)據(jù)的請求，才將其發(fā)到從庫上。在這個交易平臺上，買家來逛商鋪頁面，就算晚幾秒看到最新發(fā)布的商品，也是可以接受的。那么，這類請求就可以走從庫。這個方案的最大問題在于會碰到所有查詢都不是“過期讀”的需求，比如金融類業(yè)務，這樣就要放棄讀寫分離，所有的壓力都在主庫。采用以下方案。
方案二：Sleep方案
主庫更新后，讀從庫之前先sleep一下，類似執(zhí)行了select sleep（1）命令，這個方案的假設是，大多數(shù)情況下主備延遲在1秒之內，做一個sleep可以有很大概率拿到最新的數(shù)據(jù)。
以賣家發(fā)布商品為例，商品發(fā)布后，用Ajax直接把客戶端輸入的內容作為“新的商品”顯示在頁面上，而不是真正地去數(shù)據(jù)庫做查詢。這樣，賣家就可以通過這個顯示，來確認產品已經發(fā)布成功了。等到賣家再刷新頁面，去查看商品的時候，其實已經過了一段時間，也就達到了sleep的目的，進而也就解決了過期讀的問題。
方案三：判斷主備無延遲方案：
第一種方法：先用show slave status結果里的seconds_behind_master參數(shù)的值，可以用來衡量主備延遲時間的長短。先判斷這個參數(shù)值是否為0，如果不為0，必須等到這個參數(shù)變?yōu)?才能執(zhí)行請求。
第二種方法：對比位點確保主備無延遲。
Master_Log_File和Read_Master_Log_Pos，表示的是讀到的主庫的最新位點；
Relay_Master_Log_File和Exec_Master_Log_Pos，表示的是備庫執(zhí)行的最新位點。
如果Master_Log_File和Relay_Master_Log_File、Read_Master_Log_Pos和Exec_Master_Log_Pos這兩組值完全相同，就表示接收到的日志已經同步完成。
第三種方法：對比GTID（全局事物ID）確保主備無延遲
Auto_Position=1 ，表示這對主備關系使用了GTID協(xié)議。
Retrieved_Gtid_Set，是備庫收到的所有日志的GTID集合；
Executed_Gtid_Set，是備庫所有已經執(zhí)行完成的GTID集合。
如果這兩個集合相同，表示備庫接收到的日志都已經同步完成。
方案四：等主庫位點方案
select master_pos_wait(file, pos[, timeout]);
這條命令是在從庫執(zhí)行的 ，參數(shù)file和pos指的是主庫上的文件名和位置，timeout表示這個函數(shù)最多等待N秒。
這個命令正常返回的結果是一個正整數(shù)M，表示從命令開始執(zhí)行，到應用完file和pos表示的binlog位置，執(zhí)行了多少事務。
如果備庫同步線程發(fā)生異常，則返回null
如果等待超過N秒，就返回-1
如果剛開始執(zhí)行就發(fā)現(xiàn)已經執(zhí)行過了，則返回0
如圖：先執(zhí)行trx1，再執(zhí)行一個查詢請求的邏輯，要保證能夠查到正確的數(shù)據(jù)，我們可以使用
這個邏輯
1. trx1事物更新完成后，馬上執(zhí)行show master status得到當前主庫執(zhí)行到的File和Position；
2. 選定一個從庫執(zhí)行查詢語句；
3. 在從庫上執(zhí)行select master_pos_wait(File, Position, 1)；
4. 如果返回值是>=0的正整數(shù)，則在這個從庫執(zhí)行查詢語句；
5. 否則，到主庫執(zhí)行查詢語句。
這里我們假設，這條select查詢最多在從庫上等待1秒。那么，如果1秒內master_pos_wait返回
一個大于等于0的整數(shù)，就確保了從庫上執(zhí)行的這個查詢結果一定包含了trx1的數(shù)據(jù)。
5到主庫執(zhí)行查詢語句，是這類方案常用的退化機制。因為從庫的延遲時間不可控，不能無
限等待，所以如果等待超時，就應該放棄，然后到主庫去查。按照我們設定不允許過期讀的要求，就只有兩種選擇，一種是超時放棄，一種是轉到主庫查詢。
并發(fā)連接和并發(fā)查詢
innodb_thread_concurrency參數(shù)是控制innodb的并發(fā)線程上限。一旦超過這個數(shù)值，新請求就會進入等待。
show processlist看到的幾千個連接，是值并發(fā)連接，而當前正在執(zhí)行的語句，才是并發(fā)查詢。并發(fā)連接影響不大，只是會多占內存，而并發(fā)查詢才是CPU殺手。
在線程進入鎖等待以后，并發(fā)線程的計數(shù)會建議，也就是等行鎖的線程是不算在并發(fā)查詢里的。因為所等待已經不吃CPU了
以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持腳本之家。
來源：腳本之家
鏈接：https://www.jb51.net/article/195367.htm
申請創(chuàng)業(yè)報道，分享創(chuàng)業(yè)好點子。點擊此處，共同探討創(chuàng)業(yè)新機遇！
