讀寫分離

當我們的數(shù)據(jù)庫壓力主鍵變大的時候，我們會嘗試增加一些從節(jié)點來分攤主節(jié)點的查詢壓力。而一般來說，我們是用一主多從的結構來作為讀寫分離的基本結構。

而一般來說我們有兩種常用的方法來實現(xiàn)讀且分離架構：

客戶端直接分離

這種方式是由客戶端，或者我們的微服務直接進行數(shù)據(jù)庫的讀寫選擇。將讀庫選擇路由到主庫上進行，將查詢路由到從主庫上進行。

這種方式的優(yōu)點在于因為是直連所以性能比較高，但是需要由業(yè)務團隊了解數(shù)據(jù)庫的實例細節(jié)，當數(shù)據(jù)庫做調整的時候就需要業(yè)務側同步改造。

使用數(shù)據(jù)中間件代理

這種方式是由一層代理層對數(shù)據(jù)的讀寫做分發(fā)，業(yè)務層將所有的請求都通過代理來實現(xiàn)。

這種方式的優(yōu)點在于對于業(yè)務層不需要感知到數(shù)據(jù)庫的存在，但問題在于數(shù)據(jù)中間件的性能要求較高，還需要專人來進行優(yōu)化和維護，整體架構較為復雜。

但是我們發(fā)現(xiàn)，盡管這兩種方式各有優(yōu)劣。但核心都是通過數(shù)據(jù)的寫入、查詢請求的路由而實現(xiàn)的，那么這就會引發(fā)標題的問題：

主備同步存在延遲，所以在延遲時間內對插入的內容進行查詢則無法查詢到最新提交的事務。

那么如何保證主從一致性的問題，其實就變成了如何處理主從延遲的問題。

低改造成本

根據(jù)項目的大小，團隊的規(guī)模以及主機的部署模式。我們處理問題的方法也有很多種。

強制讀主庫

最簡單強硬的就是強制讀主庫。

一般情況下我們在不同的查詢中會有不同程度的一致性要求。我們可以將需要保證數(shù)據(jù)一致性的請求配置強制查詢主庫，而對于無強依賴的查詢請求仍然查詢備庫。

盡管這個方案不是很優(yōu)雅，但是是最簡單實現(xiàn)的方法，并且在Spring等框架的支持下一般只需要加一個注解就能實現(xiàn)。但這個方法的問題也是顯而易見的，如果存在大量的強一致性要求的查詢語句，則相當于沒有進行讀寫分離與擴展。那么這種方法就會導致系統(tǒng)在數(shù)據(jù)庫層面沒有有效的擴展手段了。

等待時間

由于問題產(chǎn)生的來源是主從延遲，所以在下一次查詢的時候進行一段時間的等待以彌補這種延遲即可。

所以在進行主庫的數(shù)據(jù)插入之后，讓數(shù)據(jù)庫數(shù)據(jù)連接或者對應的執(zhí)行線程等待一段時間后返回。通過等待時間來消化掉主從備份的延遲時間。但是這個方法也有一些問題比如：這個等待時間一般是固定的，即便主從已經(jīng)無延遲了也會繼續(xù)等待到時間結束;如果在服務高峰時期，有可能數(shù)據(jù)在等待時間結束后仍然沒有完成同步則仍然會存在一致性問題。

但這種方法優(yōu)雅的地方是可以配合業(yè)務來進行實現(xiàn)，舉例來說當用戶下單之后，通過下單送卷或者下單抽獎的方式從前端拖住用戶，從而當用戶在一次連續(xù)操作中再次查詢自己訂單的時候中間必然會間隔一定時間，也就讓需要再次查詢數(shù)據(jù)的時候保證了數(shù)據(jù)的一致性。

一主一備情況

上述兩種方案看起來可能不那么“技術”，感覺有點投機取巧。那么下面咱們可以分兩種情況來討論用更高技術的方法如何實現(xiàn)一致性。

查詢延遲方案

對于主從復制來說，是當主庫完成一個事務后，通知給從庫，當從庫接受到后，則主庫完成返回客戶端。所以當主庫完成事務后，僅能確保從庫已經(jīng)接受到了，但是不能保證從庫執(zhí)行完成，也就是導致了主從備份延遲。

但是從庫執(zhí)行數(shù)據(jù)是有進度的，而這個進度是可以通過show slave status語句中的seconds_behind_master來進行描述，這個參數(shù)描述從庫落后了主庫數(shù)據(jù)多少秒，當這個參數(shù)為0時，我們可以認為從庫和主庫已經(jīng)基本上沒有延遲了，那么這時候就可以查詢請求。

但seconds_behind_master是秒級的，所以只能大概地判斷，由于精度較低，所以還是可能出現(xiàn)不一致的情況。

如果要求精準執(zhí)行的話，我們可以比較同步文件的執(zhí)行記錄，具體來說是：

• Master_Log_File和Read_Master_Log_Pos，表示的是讀到的主庫的最新位點;
• Relay_Master_Log_File和Exec_Master_Log_Pos，表示的是備庫執(zhí)行的最新位點。

所以當Relay_Master_Log_File和Exec_Master_Log_Pos和其一致的時候，就說明從庫的已執(zhí)行數(shù)據(jù)已經(jīng)追上主庫了，那么這時就可以說保證了主從一致性了

半同步復制方案

但是比較同步文件的執(zhí)行記錄方法的問題在于，如果當前的這個事務的binlog尚未傳入到從庫，即Master_Log_File和Read_Master_Log_Pos未更新，也就無法保證從庫已經(jīng)包含最新的主庫事務了。

而為了保證在一主一備的情況下，從庫里一定接受到數(shù)據(jù)了，也就是Master_Log_File和Read_Master_Log_Pos中的數(shù)據(jù)是和主庫一致的，我們可以開啟semi-sync replication半同步復制。

半同步復制的原理是在主庫提交事務前先將binlog發(fā)送給從庫，然后當從庫接受后返回一個應答，主庫只有在接受到這個應答之后才返回事務執(zhí)行完成。這樣就可以保證從庫的Master_Log_File和Read_Master_Log_Pos與主庫是一致的，從而解決了主從一致的問題。

一主多備情況

半同步復制可以解決一主一備的情況，但是當一主多備的時候，只要主庫接受到一個從庫的應答，就會返回事務執(zhí)行完成。而這時當請求打到未完成同步的從庫上時就會發(fā)生主從延遲。

等主庫記錄方案

所以針對一主多備的情況，我們可以將目光集中在執(zhí)行查詢的從庫上，即確保我們即將查詢的備庫已經(jīng)執(zhí)行了我們預期的事務。那么我們的問題就變成兩部分：1. 確認主庫事務，2. 查詢數(shù)據(jù)條件。

確認主庫事務

當我們提交完一個事務后，可以通過執(zhí)行show master status來得到主庫中的數(shù)據(jù)事務文件(File)和位置記錄(Position)。

查詢數(shù)據(jù)條件

當我們要查詢從庫數(shù)據(jù)的時候，我們可以通過語句select master_pos_wait(File, Position, 1);來查詢當前是否已經(jīng)執(zhí)行到了該記錄(當返回值>=0的時候說明已經(jīng)執(zhí)行過了)。其中最后的數(shù)字1表示阻塞時長。

通過先確認主庫事務記錄，再判確認備庫是否已經(jīng)執(zhí)行了了主庫對應的事務。

但是可以發(fā)現(xiàn)，這種方法要求查詢的時候知道主庫的事務信息，對場景有很大的限制。

最后

主從一致的問題源自主從延遲，所以我們就是從如何消除延遲來解決問題。簡單點的方案我們可以不走備庫、或者直接等待一段時間來忽略延遲的影響。在一主一備的情況下我們可以粗力度的用seconds_behind_master來判斷或者用Relay_Master_Log_File和Exec_Master_Log_Pos來判斷。而當一主多從的情況下我們則需要在查詢前傳入主庫執(zhí)行的事務記錄才能保證數(shù)據(jù)一致性。

可以看出，當數(shù)據(jù)規(guī)模和部署方式變更的時候，好的解決方案將會越來越多。我認為根據(jù)實際業(yè)務情況選擇最合適的方法才是最重要的。

本文題目：數(shù)據(jù)庫讀寫分離如何保證主從一致性
文章鏈接：http://uogjgqi.cn/article/cdjgjoc.html