站長資訊網(wǎng)Redis、MySQL緩存雙寫不一致怎么辦？本篇文章就來給大家分享解決緩存雙寫不一致問題的方法，希望能夠給大家提供幫助！
redis、mysql雙寫緩存不一致：
但是在更新緩存方面，對于更新完數(shù)據(jù)庫，是更新緩存呢，還是刪除緩存。又或者是先刪除緩存，再更新數(shù)據(jù)庫，其實大家存在很大的爭議。目前沒有一篇全面的博客，對這幾種方案進行解析。于是博主戰(zhàn)戰(zhàn)兢兢，頂著被大家噴的風(fēng)險，寫了這篇文章。
正文
給緩存數(shù)據(jù)設(shè)置過期時間
先做一個說明，從理論上來說，給緩存設(shè)置過期時間，是保證最終一致性的解決方案。這種方案下，我們可以對存入緩存的數(shù)據(jù)設(shè)置過期時間，所有的寫操作以數(shù)據(jù)庫為準(zhǔn)，對緩存操作只是盡最大努力即可。也就是說如果數(shù)據(jù)庫寫成功，緩存更新失敗，那么只要到達(dá)過期時間，則后面的讀請求自然會從數(shù)據(jù)庫中讀取新值然后回填緩存。因此，接下來討論的思路不依賴于給緩存設(shè)置過期時間這個方案。
在這里，我們先討論三種更新策略：
- 先更新數(shù)據(jù)庫，再更新緩存
- 先刪除緩存，再更新數(shù)據(jù)庫
- 先更新數(shù)據(jù)庫，再刪除緩存
先更新數(shù)據(jù)庫，再更新緩存
這套方案，大家普遍反對。為什么呢？有如下兩點：
- 原因一（線程安全角度）
（1）線程A更新了數(shù)據(jù)庫
（2）線程B更新了數(shù)據(jù)庫
（3）線程B更新了緩存
（4）線程A更新了緩存
這就出現(xiàn)請求A更新緩存應(yīng)該比請求B更新緩存早才對，但是因為網(wǎng)絡(luò)等原因，B卻比A更早更新了緩存。這就導(dǎo)致了臟數(shù)據(jù)，因此不考慮。
- 原因二（業(yè)務(wù)場景角度）
（1）如果你是一個寫數(shù)據(jù)庫場景比較多，而讀數(shù)據(jù)場景比較少的業(yè)務(wù)需求，采用這種方案就會導(dǎo)致，數(shù)據(jù)壓根還沒讀到，緩存就被頻繁的更新，浪費性能。
（2）如果你寫入數(shù)據(jù)庫的值，并不是直接寫入緩存的，而是要經(jīng)過一系列復(fù)雜的計算再寫入緩存。那么，每次寫入數(shù)據(jù)庫后，都再次計算寫入緩存的值，無疑是浪費性能的。顯然，刪除緩存更為適合。
先刪除緩存，再更新數(shù)據(jù)庫
該方案會導(dǎo)致不一致原因是。同時一個請求A進行更新操作，另一個請求B進行查詢操作。那么會出現(xiàn)如下情形：
（1）請求A進行寫操作，刪除緩存
（2）請求B查詢發(fā)現(xiàn)緩存不存在
（3）請求B去數(shù)據(jù)庫查詢得到舊值
（4）請求B將舊值寫入緩存
（5）請求A將新值寫入數(shù)據(jù)庫
上述情況就會導(dǎo)致不一致的情形出現(xiàn)。而且，如果不采用給緩存設(shè)置過期時間策略，該數(shù)據(jù)永遠(yuǎn)都是臟數(shù)據(jù)。
那么，如何解決呢？采用延時雙刪策略
緩存延時雙刪
public class CacheServiceImpl implements ICacheService { @Resource private RedisOperator redisOperator; @Autowired private IShopService shopService; //1. 采用延時雙刪，解決數(shù)據(jù)庫和緩存的一致性 @Override public void updateHotCount(String id) { try { //刪除緩存 redisOperator.del("redis_key_" + id); //更新數(shù)據(jù)庫 shopService.updataHotShop(); Thread.sleep(1000);//休眠1秒 //延時刪除 redisOperator.del("redis_key_" + id); } catch (InterruptedException e) { e.printStackTrace(); } } @Override public Integer getHotCount(String id) { return null; }}
解釋：
- 先淘汰緩存
- 再寫數(shù)據(jù)庫
- 休眠1秒，再淘汰緩存（這么做，可以將1秒內(nèi)所造成的緩存臟數(shù)據(jù)，再次刪除。）
針對上面的情形，讀者應(yīng)該自行評估自己的項目的讀數(shù)據(jù)業(yè)務(wù)邏輯的耗時。然后寫數(shù)據(jù)的休眠時間則在讀數(shù)據(jù)業(yè)務(wù)邏輯的耗時基礎(chǔ)上，加幾百ms即可。這么做的目的，就是確保讀請求結(jié)束，寫請求可以刪除讀請求造成的緩存臟數(shù)據(jù)。
如果數(shù)據(jù)庫采用了讀寫分離架構(gòu)，這么辦？（主庫負(fù)責(zé)寫操作，從庫負(fù)責(zé)讀操作）
ok，在這種情況下，造成數(shù)據(jù)不一致的原因如下，還是兩個請求，一個請求A進行更新操作，另一個請求B進行查詢操作。
（1）請求A進行寫操作，刪除緩存，請求A把數(shù)據(jù)寫入主庫，還沒開始同步從庫
（2）（1s內(nèi)）請求B查詢緩存，沒有發(fā)現(xiàn)緩存，請求B去從庫查詢，這時還沒有完成主從同步，查到是舊值，并且把舊值寫入緩存。
（3）主庫完成主從同步，從庫變?yōu)樾轮?/p>
上述流程，就是數(shù)據(jù)不一致問題，還使用雙刪延時策略。只是，睡眠時間修改為在主從同步的延時時間基礎(chǔ)之上，加幾百ms
采用這種同步淘汰策略，吞吐量降低怎么辦？
ok，那就將第二次刪除作為異步的。自己起一個線程，異步刪除。這樣，寫的請求就不用沉睡一段時間后了，再返回。這么做，加大吞吐量。
第二次刪除,如果刪除失敗怎么辦？
這是個非常好的問題，因為第二次刪除失敗，就會出現(xiàn)如下情形。還是有兩個請求，一個請求A進行更新操作，另一個請求B進行查詢操作，為了方便，假設(shè)是單庫：
（1）請求A進行寫操作，刪除緩存
（2）請求B查詢發(fā)現(xiàn)緩存不存在
（3）請求B去數(shù)據(jù)庫查詢得到舊值
（4）請求B將舊值寫入緩存
（5）請求A將新值寫入數(shù)據(jù)庫
（6）請求A試圖去刪除請求B寫入對緩存值，結(jié)果失敗了。
ok,這也就是說。如果第二次刪除緩存失敗，會再次出現(xiàn)緩存和數(shù)據(jù)庫不一致的問題。
如何解決呢？
具體解決方案，且看博主對第先更新數(shù)據(jù)庫，再刪緩存種更新策略的解析。
刪除緩存重試機制
不管是延時雙刪還是Cache-Aside的先操作數(shù)據(jù)庫再刪除緩存，都可能會存在第二步的刪除緩存失敗，導(dǎo)致的數(shù)據(jù)不一致問題。可以使用這個方案優(yōu)化：刪除失敗就多刪除幾次呀,保證刪除緩存成功就可以了呀~ 所以可以引入刪除緩存重試機制
- （1）更新數(shù)據(jù)庫數(shù)據(jù)；
（2）緩存因為種種問題刪除失敗
（3）將需要刪除的key發(fā)送至消息隊列
（4）自己消費消息，獲得需要刪除的key
（5）繼續(xù)重試刪除操作，直到成功
然而，該方案有一個缺點，對業(yè)務(wù)線代碼造成大量的侵入。于是有了方案二，在方案二中，啟動一個訂閱程序去訂閱數(shù)據(jù)庫的binlog，獲得需要操作的數(shù)據(jù)。在應(yīng)用程序中，另起一段程序，獲得這個訂閱程序傳來的信息，進行刪除緩存操作。
讀取biglog異步刪除緩存
流程如下圖所示：
（1）更新數(shù)據(jù)庫數(shù)據(jù)
（2）數(shù)據(jù)庫會將操作信息寫入binlog日志當(dāng)中
（3）訂閱程序提取出所需要的數(shù)據(jù)以及key
（4）另起一段非業(yè)務(wù)代碼，獲得該信息
（5）嘗試刪除緩存操作，發(fā)現(xiàn)刪除失敗
（6）將這些信息發(fā)送至消息隊列
（7）重新從消息隊列中獲得該數(shù)據(jù)，重試操作。
備注說明：上述的訂閱binlog程序在mysql中有現(xiàn)成的中間件**叫canal，**可以完成訂閱binlog日志的功能。至于oracle中，博主目前不知道有沒有現(xiàn)成中間件可以使用。另外，重試機制，博主是采用的是消息隊列的方式。如果對一致性要求不是很高，直接在程序中另起一個線程，每隔一段時間去重試即可，這些大家可以靈活自由發(fā)揮，只是提供一個思路。
本文其實是對目前互聯(lián)網(wǎng)中已有的一致性方案，進行了一個總結(jié)。對于先刪緩存，再更新數(shù)據(jù)庫的更新策略，還有方案提出維護一個內(nèi)存隊列的方式，博主看了一下，覺得實現(xiàn)異常復(fù)雜，沒有必要，因此沒有必要在文中給出。最后，希望大家有所收獲。
【
