今天小千要給大家分享一道關于數據庫緩存同步的面試題，希望通過這道面試題可以幫助大家搞定面試官。

　　一. 數據緩存

　　數據緩存在高并發的系統設計中很常見，因為Redis確實能有效地解決數據庫和磁盤的I/O瓶頸，當一個高并發接口要查詢低頻修改的數據時，我們都建議用Redis實現數據緩存。

　　一般的緩存實現思路如下：

　　其實緩存的實現思路很簡單，這個思路能保證只有第一次查詢的是數據庫，后續的訪問查詢的都是Redis，這樣不僅提高了接口的訪問效率，還在一定程度上實現了數據庫的讀寫分離。

　　那么現在問題來了，如果我們的數據庫數據發生了變化，Redis怎么保證和數據庫里的數據一致呢?這個問題就是我們今天要探討的緩存同步問題。

　　二. 緩存同步分析

　　緩存同步這個思路相信大家很快就能搞清楚，大概思路如下：

　　當我們對業務庫做了修改，我們可以通過同步更新的方式去同步，也可以通過暴力刪除Redis的方式去同步。因為刪除Redis，會再次查詢數據庫的最新數據，這樣就可以達成同步的目的。但不管你使用哪種方式，都會存在一些意想不到的問題，如下：

　　先寫數據庫，再更新Redis，上圖中演示了一種極端情況，按照時間軸的發展，數據庫里的最新值是8，但Redis中的最新值是9，并沒有一致。

　　如果我們先更新Redis，再寫數據庫，按照時間軸，Redis里的最新值是8 ，數據庫里的最新值是9，還是沒有保持一致。

　　先寫數據庫，再刪Redis，這也不行。

　　如上圖，當數據庫里的值為9，然后再刪Redis。假如這時有一個讀線程來了，發現Redis數據沒了，這個讀線程立即查詢數據庫，讀到的就是9。然而不巧的是另外一個寫線程將數據庫改為8 ，也就是說數據庫最新為8，結果緩存發生在更新數據庫之后，緩存最新的值就是9，還是不能一致。

　　如果我們先刪Redis再寫數據庫，寫線程上來把Redis刪了，讀線程立即讀數據庫，比如讀到的舊數據是8，然后寫線程再改數據庫為9，這時數據庫最新為9，但Redis中的值是8，結果還是不一致。

　　三. 緩存同步解決思路

　　上面分析了四種情況，它們在極端情況下都不能保證數據庫和Redis的雙寫一致性，那到底為什么不能呢?問題到底出在哪里了，其實原因很簡單，就是我們不能保證數據庫和redis操作的原子性!在我們進行這兩個操作時，總是有別的線程在破壞數據，所以才會出現各種問題，那怎么解決呢?我們先來看看下面的解決思路：

　　這個思路大致是這樣的，寫線程只負責改數據庫，不要去參與Redis同步的問題，Redis同步交給一個嚴格順序的pipeline解決。這個pipeline的流程是，當數據庫發生數據變化會立即產生binlog日志，我們可以借助阿里的canal組件去監聽binlog，同時解析binlog，將解析的結果以消息的方式發送給MQ。MQ要保證嚴格順序，再通過消費者去消費消息，將最新的數據覆蓋更新到Redis，到此就能解決緩存的同步。

　　現在你對數據庫和Redis緩存的同步問題還有疑惑嗎？如果還有別的問題，請關注我們吧，干貨不斷哦。