RedisMySQL緩存雙寫不一致如何處理

2024-07-24 12:33:17

字體：大中小

來源：轉載

供稿：網友

　　本篇內容主要講解“Redis、MySQL緩存雙寫不一致如何解決”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Redis、MySQL緩存雙寫不一致如何解決”吧!

　　給緩存數據設置過期時間

　　先做一個說明，從理論上來說，給緩存設置過期時間，是保證最終一致性的解決方案。這種方案下，我們可以對存入緩存的數據設置過期時間，所有的寫操作以數據庫為準，對緩存操作只是盡最大努力即可。也就是說如果數據庫寫成功，緩存更新失敗，那么只要到達過期時間，則后面的讀請求自然會從數據庫中讀取新值然后回填緩存。因此，接下來討論的思路不依賴于給緩存設置過期時間這個方案。

　　在這里，我們先討論三種更新策略：

　　先更新數據庫，再刪除緩存
　　
先更新數據庫，再更新緩存

　　先刪除緩存，再更新數據庫

　　這套方案，大家普遍反對。為什么呢？有如下兩點：

　　原因一（業務場景角度）

　　（1）如果你是一個寫數據庫場景比較多，而讀數據場景比較少的業務需求，采用這種方案就會導致，數據壓根還沒讀到，緩存就被頻繁的更新，浪費性能。

　　（2）如果你寫入數據庫的值，并不是直接寫入緩存的，而是要經過一系列復雜的計算再寫入緩存。那么，每次寫入數據庫后，都再次計算寫入緩存的值，無疑是浪費性能的。顯然，刪除緩存更為適合。

　　先刪除緩存，再更新數據庫

　　該方案會導致不一致原因是。同時一個請求A進行更新操作，另一個請求B進行查詢操作。那么會出現如下情形：

　　（1）請求A進行寫操作，刪除緩存

　　（2）請求B查詢發現緩存不存在

　　（3）請求B去數據庫查詢得到舊值

　　（4）請求B將舊值寫入緩存

　　（5）請求A將新值寫入數據庫

　　上述情況就會導致不一致的情形出現。而且，如果不采用給緩存設置過期時間策略，該數據永遠都是臟數據。

　　原因二（線程安全角度）

　　（1）線程A更新了數據庫

　　（2）線程B更新了數據庫

　　（3）線程B更新了緩存

　　（4）線程A更新了緩存

　　這就出現請求A更新緩存應該比請求B更新緩存早才對，但是因為網絡等原因，B卻比A更早更新了緩存。這就導致了臟數據，因此不考慮。

　　那么，如何解決呢？采用延時雙刪策略

　　緩存延時雙刪

　　public class CacheServiceImpl implements ICacheService {

　　    @Resource

　　    private RedisOperator redisOperator;

　　    @Autowired

　　    private IShopService shopService;

　　    //1. 采用延時雙刪，解決數據庫和緩存的一致性

　　    @Override

　　    public void updateHotCount(String id) {

　　        try {

　　            //刪除緩存

　　            redisOperator.del("redis_key_" + id);

　　            //更新數據庫

　　            shopService.updataHotShop();

　　            Thread.sleep(1000);//休眠1秒

　　            //延時刪除

　　解釋：

　　先淘汰緩存

　　再寫數據庫

　　休眠1秒，再淘汰緩存（這么做，可以將1秒內所造成的緩存臟數據，再次刪除。）

　　針對上面的情形，讀者應該自行評估自己的項目的讀數據業務邏輯的耗時。然后寫數據的休眠時間則在讀數據業務邏輯的耗時基礎上，加幾百ms即可。這么做的目的，就是確保讀請求結束，寫請求可以刪除讀請求造成的緩存臟數據。

　　如果數據庫采用了讀寫分離架構，這么辦？（主庫負責寫操作，從庫負責讀操作）

　　ok，在這種情況下，造成數據不一致的原因如下，還是兩個請求，一個請求A進行更新操作，另一個請求B進行查詢操作。

　　（1）請求A進行寫操作，刪除緩存，請求A把數據寫入主庫，還沒開始同步從庫

　　（2）（1s內）請求B查詢緩存，沒有發現緩存，請求B去從庫查詢，這時還沒有完成主從同步，查到是舊值，并且把舊值寫入緩存。

　　（3）主庫完成主從同步，從庫變為新值

　　上述流程，就是數據不一致問題，還使用雙刪延時策略。只是，睡眠時間修改為在主從同步的延時時間基礎之上，加幾百ms

　　采用這種同步淘汰策略，吞吐量降低怎么辦？

　　ok，那就將第二次刪除作為異步的。自己起一個線程，異步刪除。這樣，寫的請求就不用沉睡一段時間后了，再返回。這么做，加大吞吐量。

　　第二次刪除,如果刪除失敗怎么辦？

　　這是個非常好的問題，因為第二次刪除失敗，就會出現如下情形。還是有兩個請求，一個請求A進行更新操作，另一個請求B進行查詢操作，為了方便，假設是單庫：

　　（1）請求A進行寫操作，刪除緩存

　　（2）請求B查詢發現緩存不存在

　　（3）請求B去數據庫查詢得到舊值

　　（4）請求B將舊值寫入緩存

　　（5）請求A將新值寫入數據庫

　　（6）請求A試圖去刪除請求B寫入對緩存值，結果失敗了。

　　ok,這也就是說。如果第二次刪除緩存失敗，會再次出現緩存和數據庫不一致的問題。

　　如何解決呢？

　　具體解決方案，且看博主對第先更新數據庫，再刪緩存種更新策略的解析。

　　刪除緩存重試機制

　　不管是延時雙刪還是Cache-Aside的先操作數據庫再刪除緩存，都可能會存在第二步的刪除緩存失敗，導致的數據不一致問題。可以使用這個方案優化：刪除失敗就多刪除幾次呀,保證刪除緩存成功就可以了呀~ 所以可以引入刪除緩存重試機制

　　到此，相信大家對“Redis、MySQL緩存雙寫不一致如何解決”有了更深的了解，不妨來實際操作一番吧！

（編輯：武林網）

上一篇：MySQL邏輯體系架構的案例分析

下一篇：MySQL如何快速組建主從復制架構