1.忍受大法
第一種解決辦法，很簡單，無他，不管他，沒有讀到也沒事，這時業務不需要任何改造，你好，我好，她也好~
如果業務對于資料一致性要求不高，我們就可以采用這種方案，
2.資料同步寫方案
主從資料同步方案，一般都是采用的異步方式同步給備庫，
我們可以將其修改為同步方案，主從同步完成，主庫上的寫才能回傳，
- 業務系統發起寫操作，資料寫主庫
- 寫請求需要等待主從同步完成才能回傳
- 資料讀從庫，主從同步完成就能讀到最新資料
這種方案，我們只需要修改資料庫之間同步配置即可，業務層無需修改，相對簡單，
「不過，由于主庫寫需要等待主從完成，寫請求的時延將會增加，吞吐量將會降低，」
這一點對于現在在線業務，可能無法接受，
3.選擇性強制讀主
對于需要強一致的場景，我們可以將其的讀請求都操作主庫，這樣「讀寫都在主庫」，就沒有不一致的情況，
這種方案業務層需要改造一下，將其強制性讀主，相對改造難度較低，
不過這種方案相對于浪費了另一個資料庫，增加主庫的壓力，
4.中間件選擇路由法
這種方案需要使用一個中間件，所有資料庫操作都先發到中間件，由中間件再分發到相應的資料庫，
這時流程如下：
- 寫請求，中間件將會發到主庫，同時記錄一下此時寫請求的 key（操作表加主鍵等）
- 讀請求，如果此時 key 存在，將會路由到主庫
- 一定時間后（經驗值），中間件認為主從同步完成，洗掉這個 key，后續讀將會讀從庫
這種方案，可以保持資料讀寫的一致，
但是系統架構增加了一個中間件，整體復雜度變高，業務開發也變得復雜，學習成本也比較高，
5.快取路由大法
這種方案與中間件的方案流程比較類似，不過改造成本相對較低，不需要增加任何中間件，
這時流程如下:
- 寫請求發往主庫，同時快取記錄操作的 key，快取的失效時間設定為主從的延時
- 讀請求首先判斷快取是否存在
-
- 若存在，代表剛發生過寫操作，讀請求操作主庫
- 若不存在，代表近期沒發生寫操作，讀請求操作從庫
這種方案相對中間件的方案成本較低，但是呢我們此時又引入一個快取組件，所有讀寫之間就又多了一步快取操作，
總結
我們引入主從架構，資料讀寫分離，目的是為了解決業務快速發展,請求量變大，并發量變大，從而引發的資料庫的讀瓶頸，
不過當引入新一個架構解決問題時，勢必會帶來另外一個問題，資料庫讀寫分離之后，主從延遲從而導致資料不一致的情況，，
為了解決主從延遲，資料不一致的情況，我們可以采用以下這幾種方案：
- 忍受大法
- 資料庫同步寫方案
- 選擇性強制讀主
- 中間件選擇路由法
- 快取路由大法
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/398654.html
標籤：其他
上一篇：Nginx的啟動、停止與重啟命令（非yum方式安裝）圖解版
下一篇：傳輸層（概念）