這篇文章主要講解了“數(shù)據(jù)庫讀寫分離的坑有哪些”，文中的講解內(nèi)容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“數(shù)據(jù)庫讀寫分離的坑有哪些”吧！
曲周網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)公司！從網(wǎng)頁設計、網(wǎng)站建設、微信開發(fā)、APP開發(fā)、成都響應式網(wǎng)站建設公司等網(wǎng)站項目制作，到程序開發(fā)，運營維護。創(chuàng)新互聯(lián)公司于2013年開始到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進行。專注于網(wǎng)站建設就選創(chuàng)新互聯(lián)公司。
前言
事情是這樣的，剛入職的時候接到了這樣的一個業(yè)務需求：
每個支付通道支付失敗的時候都會返回特定的錯誤碼，業(yè)務內(nèi)部需要將通道特定的錯誤碼轉義成內(nèi)部的錯誤碼，這樣對外就可以統(tǒng)一返回我們自己的錯誤碼。
這個需求其實不難，當時設計的系統(tǒng)架構如下：
新增規(guī)則的流程簡單分為三步：
業(yè)務人員通過管理后臺新增映射規(guī)則
數(shù)據(jù)庫新增、修改這條映射規(guī)則
刪除緩存
這里之所以增加緩存，是因為這個場景每次支付都需要使用，使用緩存可以避免每次都去數(shù)據(jù)庫讀取，增加讀取速度。
后續(xù)支付請求業(yè)務流程如下：
數(shù)據(jù)庫讀寫分離-用戶操作
當緩存內(nèi)映射規(guī)則不存在的時候，將會查詢數(shù)據(jù)庫，然后加載到緩存中。如果緩存內(nèi)映射規(guī)則已存在，將會直接使用緩存內(nèi)映射規(guī)則。
這個業(yè)務流程其實比較簡單，當時在測試環(huán)境測試也沒問題，后續(xù)發(fā)布線上環(huán)境的卻碰到奇怪的問題。
「新增規(guī)則之后，一段時間內(nèi)，映射規(guī)則并沒有生效。查看日志發(fā)現(xiàn)，查詢數(shù)據(jù)庫的時候，沒有數(shù)據(jù)。」
這就很奇怪了，日志顯示新增是成功，但是查詢卻沒有數(shù)據(jù)。但是過了一段時間，再次查詢卻又有了數(shù)據(jù)。
走查了下代碼，發(fā)現(xiàn)并沒有什么問題，第二天上班的時候請教了一下同事，才知道問題的原因：
原來線上的數(shù)據(jù)庫采用主從架構，數(shù)據(jù)讀寫分離，數(shù)據(jù)查詢走的是從庫。數(shù)據(jù)寫入都是直接操作主庫，后續(xù)再同步到從庫。
「由于數(shù)據(jù)庫同步存在延時，這就導致數(shù)據(jù)同步的這段時間，主從數(shù)據(jù)將會不一致，從庫無法查詢到最新的數(shù)據(jù)?！?/p>
如果你之前的數(shù)據(jù)庫系統(tǒng)架構是單庫或者主備結構，當你第一次轉到數(shù)據(jù)讀寫分離架構，這個坑大概率也會踩到。
數(shù)據(jù)庫系統(tǒng)架構發(fā)展
下面我們首先了解一下數(shù)據(jù)庫系統(tǒng)架構，最后再來看下如何解決主從同步延時的導致數(shù)據(jù)不一致。
主備架構
業(yè)務發(fā)展的前期，數(shù)據(jù)訪問量小，這時我們可以直接采用單庫的架構。
不過我們一般不使用的上面的架構，因為存在單點的問題。若數(shù)據(jù)庫出現(xiàn)故障，這段期間業(yè)務將會不可用。我們除了等待重啟，其他沒什么解決辦法。
所以我們會增加一個備庫，實時同步主庫的數(shù)據(jù)。
主備架構
一旦「主庫」出了故障，通過人工的方式，手動的將「主機」踢下線，將「備機」改為「主機」來繼續(xù)提供服務。
這種架構，部署維護簡單，業(yè)務開發(fā)也無需任何改造。
不過缺點也很明顯，備庫只有在主庫有問題的時候才會被啟用，存在一定的資源浪費的情況。
主從架構
隨著業(yè)務發(fā)展，請求量不斷變大，數(shù)據(jù)量也不斷變大，業(yè)務變得更加復雜，很快數(shù)據(jù)將會到達瓶頸。
由于大多數(shù)業(yè)務都是讀多寫少，所以數(shù)據(jù)庫讀的最容易成為系統(tǒng)瓶頸。
這時候我們可以提高讀的性能，這時我們的可以采用的方案，增加從實例，主從同步，數(shù)據(jù)讀寫分離。
可以看到這個架構與主備沒什么區(qū)別，主要區(qū)別在于主從架構下，從庫與主庫一樣，時刻需要干活，主庫提供寫服務，從庫只提供讀服務。
如果后續(xù)讀的壓力還是太大，我們還可以增加從庫的數(shù)量，水平擴充讀的能力。
雖然主從架構幫我們解決讀的瓶頸，但是由于主從之間需要數(shù)據(jù)同步，這天然就存在一定延時。
在這延時窗口期內(nèi)，從庫的讀只能讀到一個舊數(shù)據(jù)，這也是上面案例問題的真正的原因。
接下來我們來看下有什么辦法可以優(yōu)化這種情況。
主從延時解決辦法
忍受大法
第一種解決辦法，很簡單，無他，不管他，沒有讀到也沒事。這時業(yè)務不需要任何改造，你好，我好，她也好~
如果業(yè)務對于數(shù)據(jù)一致性要求不高，我們就可以采用這種方案。
數(shù)據(jù)同步寫方案
主從數(shù)據(jù)同步方案，一般都是采用的異步方式同步給備庫。
我們可以將其修改為同步方案，主從同步完成，主庫上的寫才能返回。
業(yè)務系統(tǒng)發(fā)起寫操作，數(shù)據(jù)寫主庫
寫請求需要等待主從同步完成才能返回
數(shù)據(jù)讀從庫，主從同步完成就能讀到最新數(shù)據(jù)
這種方案，我們只需要修改數(shù)據(jù)庫之間同步配置即可，業(yè)務層無需修改，相對簡單。
「不過，由于主庫寫需要等待主從完成，寫請求的時延將會增加，吞吐量將會降低?！?/p>
這一點對于現(xiàn)在在線業(yè)務，可能無法接受。
選擇性強制讀主
對于需要強一致的場景，我們可以將其的讀請求都操作主庫，這樣「讀寫都在主庫」，就沒有不一致的情況。
這種方案業(yè)務層需要改造一下，將其強制性讀主，相對改造難度較低。
不過這種方案相對于浪費了另一個數(shù)據(jù)庫，增加主庫的壓力。
中間件選擇路由法
這種方案需要使用一個中間件，所有數(shù)據(jù)庫操作都先發(fā)到中間件，由中間件再分發(fā)到相應的數(shù)據(jù)庫。
這時流程如下：
寫請求，中間件將會發(fā)到主庫，同時記錄一下此時寫請求的 key（操作表加主鍵等）
讀請求，如果此時 key 存在，將會路由到主庫
一定時間后（經(jīng)驗值），中間件認為主從同步完成，刪除這個 key，后續(xù)讀將會讀從庫
這種方案，可以保持數(shù)據(jù)讀寫的一致。
但是系統(tǒng)架構增加了一個中間件，整體復雜度變高，業(yè)務開發(fā)也變得復雜，學習成本也比較高。
緩存路由大法
這種方案與中間件的方案流程比較類似，不過改造成本相對較低，不需要增加任何中間件。
這時流程如下:
寫請求發(fā)往主庫，同時緩存記錄操作的 key，緩存的失效時間設置為主從的延時
讀請求首先判斷緩存是否存在
若存在，代表剛發(fā)生過寫操作，讀請求操作主庫
若不存在，代表近期沒發(fā)生寫操作，讀請求操作從庫
這種方案相對中間件的方案成本較低，但是呢我們此時又引入一個緩存組件，所有讀寫之間就又多了一步緩存操作。
感謝各位的閱讀，以上就是“數(shù)據(jù)庫讀寫分離的坑有哪些”的內(nèi)容了，經(jīng)過本文的學習后，相信大家對數(shù)據(jù)庫讀寫分離的坑有哪些這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關知識點的文章，歡迎關注！
重慶分公司
重慶分公司
