DB主從一致性的幾種解決方法
起源
現在基本所有的程序中都會用到數據庫，而數據庫其實就是對所有業務邏輯處理結果的保存，所以不論在什么情況下數據的丟失都不被允許的，最壞的情況也要最小化數據的丟失程度，所以一般情況下，數據源都會至少配有兩個節點，一個業務處理使用的節點，一個甚至多個從節點，這些從節點就是我們常說的冷備，業務處理節點（主節點）和備份節點一定的時間間隔內進行數據同步，從而來保證當一個數據源壞掉之后，數據也不會丟失，或着丟失很少（主要看同步的時間間隔）。但是為了提高資源的使用效率，所以有人就提出了，可不可以讓冷備也被利用起來，替主節點分擔部分壓力，所以就提出了讀寫分離的方案。
讀寫分離
讀寫分離提高了資源的利用效率的同時也引出了一個問題，就是由於延時（網絡傳輸，操作）而引起的數據庫主從不一致的問題，對於這個問題，給一下集中解決方案。
1-半同步復制
主從不一致的原因是延時引起的,所以要消除這個延時的影響，可以從主庫進行CUD操作時進行規避，辦法就是等主從同步完成之后，主庫上的寫請求再返回，就是大家常說的“半同步復制”semi-sync。
請求請求主庫主庫從庫從庫CUD操作開始同步同步完成CUD操作完成
- 方案優點：利用數據庫原生功能，比較簡單
- 方案缺點：主庫的寫請求時延會增長，吞吐量會降低
2-數據庫中間件
CUD操作
請求請求中間件中間件主庫主庫從庫從庫CUD操作路由同步
R操作
請求請求中間件中間件主庫主庫從庫從庫R操作同步未完成同步完成
- 方案優點：能保證絕對一致
- 方案缺點：數據庫中間件的成本比較高
3-緩存記錄寫key法
CUD操作
（1）將某個庫上的某個key要發生寫操作，記錄在cache里，並設置“經驗主從同步時間”的cache超時時間，例如500ms
（2）修改數據庫
R操作
（1）先到cache里查看，對應庫的對應key有沒有相關數據
（2）如果cache hit，有相關數據，說明這個key上剛發生過寫操作，此時需要將請求路由到主庫讀最新的數據
（3）如果cache miss，說明這個key上近期沒有發生過寫操作，此時將請求路由到從庫，繼續讀寫分離
- 方案優點：相對數據庫中間件，成本較低
- 方案缺點：方案缺點：為了保證“一致性”，引入了一個cache組件，並且讀寫數據庫時都多了一步cache操作