前言:

  資料庫叢集,讀寫分離現在可以說是專案必備的了，但是我們如何保證其每個資料庫的資料一致性?

 1 半同步複製

  簡單的說就是: 主庫發生增刪改操作的時候,會等從庫及時複製了並且通知了主庫, 才會把這個操作叫做成功.

  優點：保證資料一致性

  缺點:就是會慢

專業的講：

  半同步複製，是等待其中一個從庫也接收到Binlog事務併成功寫入Relay Log之後，才返回Commit操作成功給客戶端；如此半同步就保證了事務成功提交後至少有兩份日誌記錄，一份在主庫Binlog上，另一份在從庫的Relay Log上，從而進一步保證資料完整性；半同步複製很大程度取決於主從網路RTT（往返時延），以外掛 semisync_master/semisync_slave 形式存在。 

2 資料庫中介軟體

如果有了資料庫中介軟體，所有的資料庫請求都走中介軟體，這個主從不一致的問題可以這麼解決：

所有的讀寫請求都走中介軟體，然後寫的請求路由到主庫，讀的請求路由到從庫

但是我們中介軟體會記錄寫庫的一個key,在設定一個允許同步時間,假設是1s

當有一個寫請求過來時候，生成一個key A ，馬上路由寫到主庫，然後立馬有一個讀請求過來。 從庫可能是舊資料，或者沒有來得及同步。 如果時間是在1s內的，就對應的key繼續路由到主庫。如果在1s以後的，就路由到從庫。

說白了，中介軟體就是給個同步時間，給你同步，在同步時間內，所有的請求都落在主庫

3 快取記錄寫key法

1 將某個庫上的某個key要發生寫操作，記錄在cache裡，並設定“經驗主從同步時間”的cache超時時間，例如1s

2 修改資料庫

（1）先到cache裡檢視，對應庫的對應key有沒有相關資料
（2）如果cache hit，有相關資料，說明這個key上剛發生過寫操作，此時需要將請求路由到主庫讀最新的資料
（3）如果cache miss，說明這個key上近期沒有發生過寫操作，此時將請求路由到從庫，繼續讀寫分離
方案優點：相對資料庫中介軟體，成本較低
方案缺點：為了保證“一致性”，引入了一個cache元件，並且讀寫資料庫時都多了一步cache操作

總結：

就是兩個思路

1  半同步複製 ， 等從庫複製成功才返回寫成功

2  設一個key記錄著一次寫的資料,然後設定一個同步時間，如果在這個時間內，有一個讀請求,看看對應的key有沒有相關資料,有的話,說明資料近期發生過寫事件，這樣key的資料就繼續讀主庫，否則就讀從庫