Redis緩存維護方案-怎麼解決緩存與數據庫不一致

通常經常使用的緩存方案有兩種：

第一種

• 讀的時候，先讀緩存，緩存沒有的話，讀數據庫，取出數據後放入緩存，同時返回響應。
• 更新的時候，先刪除緩存，在更新數據庫。

第二種

• 讀的時候，先讀緩存，緩存沒有的話，讀數據庫，取出數據後放入緩存，同時返回響應。
• 更新的時候，先更新數據庫，再刪除緩存。

第二種是Cache Aside Pattern的本來思路，用的比較多，第一種也有在用。爲何會形成這兩種分歧勒？緣由在於：

• 第一種方案引入了緩存-數據庫雙寫不一致的問題，即讀數據（寫緩存）與修改數據（寫數據庫）併發的狀況下，若修改數據數據庫事務還沒提交，可是已經把緩存從redis中刪除，此時來了個讀請求，會把舊的數據刷到緩存裏面，這樣就致使了緩存中的數據直到下一次修改數據庫以前確定是與數據庫不一致的。
• 第二種方案引入了另一個問題，在提交事務以後，若更新緩存失敗，也會致使緩存數據庫不一致。

facebook公司用的是第二種方案，由於在高併發的狀況下，第一種方案帶來的影響確定比第二種方案要大。由於：

• 第一：致使更新緩存失敗的狀況機率是很小的，就算髮生了，那麼問題就大了，比起解決緩存和數據庫不一致，更應該增強Redis架構的可用性。
• 第二，高併發狀況下第一種狀況發生的機率是很高的。、

其實我的以爲在沒有讀寫分離的狀況下就用第二種方案就夠了，引入redis主從架構解決redis可用性就完了，另外，咱們能夠爲緩存設置過時時間，減少第二種方案極端狀況下數據庫緩存不一樣步形成的影響。

這是否是說第一種方案徹底不能夠用勒，也不是，在保證雙寫串行化的狀況下，咱們也可以使用第一種方案，但這種方式會犧牲必定的性能，如經過內存隊列的形式。好比：

讀請求沒讀到緩存就往內存隊列丟一個消息，去更新緩存，同時本身開始輪詢緩存。針對寫請求，也把數據庫更新的操做發送到隊列裏面去。而後後臺線程輪詢獲取內存隊列元素，消費信息。用內存隊列的方式將更新緩存和刪除緩存的操做給串行化起來。這裏能夠優化的是

• 第一: 後臺內存隊列能夠多個，經過業務IdHash分發到不一樣的內存隊列當中，只須要保證同一業務id的雙寫是串行化的就行。
• 第二：爲了不無心義的緩存更新消息連續，能夠維護一個map，鍵爲產品id，值爲一個Boolean值，boolean值標記的是否須要將更新緩存操做推到對隊列中（當消費刪緩存消息置爲ture，當消費寫緩存消息置爲false）。但這裏須要慎重，根據業務量來，若是有100萬條數據，這個map的大小會佔用到15MB。

另外也能夠粗暴的加鎖，對讀和寫加鎖串行化，方案實現起來較簡單一點。

若是引入了讀寫分離

可是若是引入了讀寫分離怎麼辦勒，因爲主從同步延遲，若是採起上面的兩種方案，在極端狀況下，有可能致使讀請求寫入緩存中的多是舊數據。這裏根據網上的資料紙上談兵分析一下，若是嚴格要求這種狀況下也要保住緩存數據庫一致性的話，只有經過引入阿里的canel組件，實現針對從庫binlog日誌的消費邏輯，等到從庫更新以後再去刪除緩存了。

總結

總結一下，在讀寫分離的狀況下，直接使用上面的方案二就可。但若是引入了讀寫分離，能夠採用上面所述的根據從庫的Binlog日誌來異步更新緩存，但沒有具體實操，可能代價有點大，若是沒有嚴格要求緩存數據庫一致性，我的以爲能夠不採用，實在不行直接放棄走緩存。