主從延時解決辦法
總結資料庫採用主從架構，資料讀寫分離，資料查詢走的是從庫。資料寫入都是直接操作主庫，後續再同步到從庫。
由於資料庫同步存在延時，這就導致資料同步的這段時間，主從資料將會不一致，從庫無法查詢到最新的資料。
如果你之前的資料庫系統架構是單庫或者主備結構，當你第一次轉到資料讀寫分離架構，這個坑大概率也會踩到。
為了方便理解，下面首先了解一下資料庫系統架構，最後再來看下如何解決主從同步延時的導致資料不一致。
業務發展的前期，資料訪問量小，這時我們可以直接採用單庫的架構
不過我們一般不使用的上面的架構，因為存在單點的問題。若資料庫出現故障，這段期間業務將會不可用。我們除了等待重啟，其他沒什麼解決辦法。
所以我們會增加乙個備庫，實時同步主庫的資料。
一旦主庫出了故障，通過人工的方式，手動的將主機踢下線，將備機改為主機來繼續提供服務。
這種架構，部署維護簡單，業務開發也無需任何改造。
不過缺點也很明顯，備庫只有在主庫有問題的時候才會被啟用，存在一定的資源浪費的情況。
隨著業務發展，請求量不斷變大，資料量也不斷變大，業務變得更加複雜，很快資料將會到達瓶頸。
由於大多數業務都是讀多寫少，所以資料庫讀的效能最容易成為系統瓶頸。
這時候我們可以提高讀的效能，這時我們的可以採用的方案，增加從例項，主從同步，資料讀寫分離。
可以看到這個架構與主備沒什麼區別，主要區別在於主從架構下，從庫與主庫一樣，時刻需要幹活，主庫提供寫服務，從庫只提供讀服務。
如果後續讀的壓力還是太大，我們還可以增加從庫的數量，水平擴充讀的能力。
雖然主從架構幫我們解決讀的瓶頸，但是由於主從之間需要資料同步，天然就存在一定延時。在這延時視窗期內，從庫的讀只能讀到乙個舊資料，這也是上面案例問題的真正的原因。
如果業務對於資料一致性要求不高,可以不做處理，如果業務對於資料一致性有要求，接下來**有什麼辦法可以優化。
主從資料同步方案，一般預設都是採用的非同步方式同步給備庫。我們可以將其修改為同步方案，主從同步完成，主庫上的寫才能返回。
流程
業務系統發起寫操作，資料寫主庫
寫請求需要等待主從同步完成才能返回
資料讀從庫，主從同步完成就能讀到最新資料
對於需要強一致的場景，我們可以將其的讀請求都操作主庫，這樣讀寫都在主庫，就沒有不一致的情況。
這種方案業務層需要改造一下，將其強制性讀主，相對改造難度較低。不過這種方案相對於浪費了另乙個資料庫，增加主庫的壓力。
這種方案需要使用乙個中介軟體，所有資料庫操作都先發到中介軟體，由中介軟體再分發到相應的資料庫。
流程如下：
寫請求，中介軟體將會發到主庫，同時記錄一下此時寫請求的 key（操作表加主鍵等）
讀請求，如果此時 key 存在，將會路由到主庫
一定時間後（經驗值），中介軟體認為主從同步完成，刪除這個 key，後續讀將會讀從庫
這種方案，可以保持資料讀寫的一致。但是系統架構增加了乙個中介軟體，整體複雜度變高，業務開發也變得複雜，學習成本也比較高。
這種方案與中介軟體的方案流程比較類似，不過改造成本相對較低，不需要增加任何中介軟體。
流程如下:
寫請求發往主庫，同時快取記錄操作的 key，快取的失效時間至少設定為主從的延時的時間；
讀請求首先判斷快取是否存在
若存在，代表剛發生過寫操作，讀請求操作主庫
若不存在，代表近期沒發生寫操作，讀請求操作從庫
這種方案相對中介軟體的方案成本較低，但是此時又引入乙個快取元件，所有讀寫之間就又多了一步快取操作。
引入主從架構，資料讀寫分離，目的是為了解決業務快速發展,請求量變大，併發量變大，從而引發的資料庫的讀瓶頸。
不過當引入新乙個架構解決問題時，勢必會帶來另外乙個問題，資料庫讀寫分離之後，主從延遲從而導致資料不一致的情況。，
為了解決主從延遲，資料不一致的情況，我們可以採用以下這幾種方案：
資料庫同步寫方案
選擇性強制讀主
中介軟體選擇路由法
快取路由**
上面的方案都有各自的優缺點，我們需要根據自己的業務情況，選擇相應的解決方案。
資料庫「讀寫分離」,解決問題
有一些技術同學可能對於 讀寫分離 了解不多，認為資料庫的負載問題都可以使用 讀寫分離 來解決。這其實是乙個非常大的誤區，我們要用 讀寫分離 首先應該明白 讀寫分離 是用來解決什麼樣的問題的，而不是僅僅會用這個技術。什麼是讀寫分離？其實就是將資料庫分為了主從庫，乙個主庫用於寫資料，多個從庫完成讀資料的...
資料庫讀寫分離
隨著乙個 的業務不斷擴充套件，資料不斷增加，資料庫的壓力也會越來越大，對資料庫或者sql的基本優化可能達不到最終的效果，我們可以採用讀寫分離的策略來改變現狀。讀寫分離現在被大量應用於很多大型 這個技術也不足為奇了。ebay就做得非常好。ebay用的是oracle，聽說是用 quest share p...
資料庫讀寫分離
隨著乙個 的業務不斷擴充套件，資料不斷增加，資料庫的壓力也會越來越大，對資料庫或者sql的基本優化可能達不到最終的效果，我們可以採用讀寫分離的策略來改變現狀。讀寫分離現在被大量應用於很多大型 這個技術也不足為奇了。ebay就做得非常好。ebay用的是oracle，聽說是用 quest share p...