一.問(wèn)題描述

redis、mysql雙寫(xiě)緩存不一致：

在更新緩存方面，對(duì)于更新完數(shù)據(jù)庫(kù)，是更新緩存呢，還是刪除緩存。又或者是先刪除緩存，再更新數(shù)據(jù)庫(kù)，其實(shí)大家存在很大的爭(zhēng)議。于是博主戰(zhàn)戰(zhàn)兢兢，寫(xiě)了這篇文章。

二.解決方案

1.給緩存數(shù)據(jù)設(shè)置過(guò)期時(shí)間

先做一個(gè)說(shuō)明，從理論上來(lái)說(shuō)，給緩存設(shè)置過(guò)期時(shí)間，是保證最終一致性的解決方案。這種方案下，我們可以對(duì)存入緩存的數(shù)據(jù)設(shè)置過(guò)期時(shí)間，所有的寫(xiě)操作以數(shù)據(jù)庫(kù)為準(zhǔn)，對(duì)緩存操作只是盡最大努力即可。也就是說(shuō)如果數(shù)據(jù)庫(kù)寫(xiě)成功，緩存更新失敗，那么只要到達(dá)過(guò)期時(shí)間，則后面的讀請(qǐng)求自然會(huì)從數(shù)據(jù)庫(kù)中讀取新值然后回填緩存。因此，接下來(lái)討論的思路不依賴(lài)于給緩存設(shè)置過(guò)期時(shí)間這個(gè)方案。

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

• 先更新數(shù)據(jù)庫(kù)，再更新緩存
• 先刪除緩存，再更新數(shù)據(jù)庫(kù)
• 先更新數(shù)據(jù)庫(kù)，再刪除緩存

先更新數(shù)據(jù)庫(kù)，再更新緩存

這套方案，大家普遍反對(duì)。為什么呢？有如下兩點(diǎn)：

• 原因一（線程安全角度）

（1）線程A更新了數(shù)據(jù)庫(kù)

（2）線程B更新了數(shù)據(jù)庫(kù)

（3）線程B更新了緩存

（4）線程A更新了緩存

這就出現(xiàn)請(qǐng)求A更新緩存應(yīng)該比請(qǐng)求B更新緩存早才對(duì)，但是因?yàn)榫W(wǎng)絡(luò)等原因，B卻比A更早更新了緩存。這就導(dǎo)致了臟數(shù)據(jù)，因此不考慮。

• 原因二（業(yè)務(wù)場(chǎng)景角度）

（1）如果你是一個(gè)寫(xiě)數(shù)據(jù)庫(kù)場(chǎng)景比較多，而讀數(shù)據(jù)場(chǎng)景比較少的業(yè)務(wù)需求，采用這種方案就會(huì)導(dǎo)致，數(shù)據(jù)壓根還沒(méi)讀到，緩存就被頻繁的更新，浪費(fèi)性能。

（2）如果你寫(xiě)入數(shù)據(jù)庫(kù)的值，并不是直接寫(xiě)入緩存的，而是要經(jīng)過(guò)一系列復(fù)雜的計(jì)算再寫(xiě)入緩存。那么，每次寫(xiě)入數(shù)據(jù)庫(kù)后，都再次計(jì)算寫(xiě)入緩存的值，無(wú)疑是浪費(fèi)性能的。顯然，刪除緩存更為適合。

先刪除緩存，再更新數(shù)據(jù)庫(kù)

該方案會(huì)導(dǎo)致不一致原因是。同時(shí)一個(gè)請(qǐng)求A進(jìn)行更新操作，另一個(gè)請(qǐng)求B進(jìn)行查詢(xún)操作。那么會(huì)出現(xiàn)如下情形：

（1）請(qǐng)求A進(jìn)行寫(xiě)操作，刪除緩存

（2）請(qǐng)求B查詢(xún)發(fā)現(xiàn)緩存不存在

（3）請(qǐng)求B去數(shù)據(jù)庫(kù)查詢(xún)得到舊值

（4）請(qǐng)求B將舊值寫(xiě)入緩存

（5）請(qǐng)求A將新值寫(xiě)入數(shù)據(jù)庫(kù)

上述情況就會(huì)導(dǎo)致不一致的情形出現(xiàn)。而且，如果不采用給緩存設(shè)置過(guò)期時(shí)間策略，該數(shù)據(jù)永遠(yuǎn)都是臟數(shù)據(jù)。

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

2.緩存延時(shí)雙刪

public class CacheServiceImpl implements ICacheService {
    @Resource
    private RedisOperator redisOperator;
    
    @Autowired
    private IShopService shopService;
 
    //1. 采用延時(shí)雙刪，解決數(shù)據(jù)庫(kù)和緩存的一致性
    @Override
    public void updateHotCount(String id) {
        try {
            //刪除緩存
            redisOperator.del("redis_key_" + id);
            //更新數(shù)據(jù)庫(kù)
            shopService.updataHotShop();
            Thread.sleep(1000);//休眠1秒
            //延時(shí)刪除
            redisOperator.del("redis_key_" + id);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
 
    @Override
    public Integer getHotCount(String id) {
        return null;
    }
}

解釋?zhuān)?/p>

先淘汰緩存再寫(xiě)數(shù)據(jù)庫(kù)休眠1秒，再淘汰緩存（這么做，可以將1秒內(nèi)所造成的緩存臟數(shù)據(jù)，再次刪除。）

針對(duì)上面的情形，讀者應(yīng)該自行評(píng)估自己的項(xiàng)目的讀數(shù)據(jù)業(yè)務(wù)邏輯的耗時(shí)。然后寫(xiě)數(shù)據(jù)的休眠時(shí)間則在讀數(shù)據(jù)業(yè)務(wù)邏輯的耗時(shí)基礎(chǔ)上，加幾百ms即可。這么做的目的，就是確保讀請(qǐng)求結(jié)束，寫(xiě)請(qǐng)求可以刪除讀請(qǐng)求造成的緩存臟數(shù)據(jù)。

如果數(shù)據(jù)庫(kù)采用了讀寫(xiě)分離架構(gòu)，這么辦？（主庫(kù)負(fù)責(zé)寫(xiě)操作，從庫(kù)負(fù)責(zé)讀操作）

ok，在這種情況下，造成數(shù)據(jù)不一致的原因如下，還是兩個(gè)請(qǐng)求，一個(gè)請(qǐng)求A進(jìn)行更新操作，另一個(gè)請(qǐng)求B進(jìn)行查詢(xún)操作。

（1）請(qǐng)求A進(jìn)行寫(xiě)操作，刪除緩存，請(qǐng)求A把數(shù)據(jù)寫(xiě)入主庫(kù)，還沒(méi)開(kāi)始同步從庫(kù)

（2）（1s內(nèi)）請(qǐng)求B查詢(xún)緩存，沒(méi)有發(fā)現(xiàn)緩存，請(qǐng)求B去從庫(kù)查詢(xún)，這時(shí)還沒(méi)有完成主從同步，查到是舊值，并且把舊值寫(xiě)入緩存。

（3）主庫(kù)完成主從同步，從庫(kù)變?yōu)樾轮?/p>

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

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

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

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

這是個(gè)非常好的問(wèn)題，因?yàn)榈诙蝿h除失敗，就會(huì)出現(xiàn)如下情形。還是有兩個(gè)請(qǐng)求，一個(gè)請(qǐng)求A進(jìn)行更新操作，另一個(gè)請(qǐng)求B進(jìn)行查詢(xún)操作，為了方便，假設(shè)是單庫(kù)：

（1）請(qǐng)求A進(jìn)行寫(xiě)操作，刪除緩存

（2）請(qǐng)求B查詢(xún)發(fā)現(xiàn)緩存不存在

（3）請(qǐng)求B去數(shù)據(jù)庫(kù)查詢(xún)得到舊值

（4）請(qǐng)求B將舊值寫(xiě)入緩存

（5）請(qǐng)求A將新值寫(xiě)入數(shù)據(jù)庫(kù)

（6）請(qǐng)求A試圖去刪除請(qǐng)求B寫(xiě)入對(duì)緩存值，結(jié)果失敗了。

ok,這也就是說(shuō)。如果第二次刪除緩存失敗，會(huì)再次出現(xiàn)緩存和數(shù)據(jù)庫(kù)不一致的問(wèn)題。

如何解決呢？

具體解決方案，且看博主對(duì)第先更新數(shù)據(jù)庫(kù)，再刪緩存種更新策略的解析。

3.刪除緩存重試機(jī)制

不管是延時(shí)雙刪還是Cache-Aside的先操作數(shù)據(jù)庫(kù)再刪除緩存，都可能會(huì)存在第二步的刪除緩存失敗，導(dǎo)致的數(shù)據(jù)不一致問(wèn)題?？梢允褂眠@個(gè)方案優(yōu)化：刪除失敗就多刪除幾次呀,保證刪除緩存成功就可以了呀~ 所以可以引入刪除緩存重試機(jī)制

（1）更新數(shù)據(jù)庫(kù)數(shù)據(jù)；

（2）緩存因?yàn)榉N種問(wèn)題刪除失敗

（3）將需要?jiǎng)h除的key發(fā)送至消息隊(duì)列

（4）自己消費(fèi)消息，獲得需要?jiǎng)h除的key

（5）繼續(xù)重試刪除操作，直到成功

然而，該方案有一個(gè)缺點(diǎn)，對(duì)業(yè)務(wù)線代碼造成大量的侵入。于是有了方案二，在方案二中，啟動(dòng)一個(gè)訂閱程序去訂閱數(shù)據(jù)庫(kù)的binlog，獲得需要操作的數(shù)據(jù)。在應(yīng)用程序中，另起一段程序，獲得這個(gè)訂閱程序傳來(lái)的信息，進(jìn)行刪除緩存操作。

4.讀取biglog異步刪除緩存

流程如下圖所示：

（1）更新數(shù)據(jù)庫(kù)數(shù)據(jù)

（2）數(shù)據(jù)庫(kù)會(huì)將操作信息寫(xiě)入binlog日志當(dāng)中

（3）訂閱程序提取出所需要的數(shù)據(jù)以及key

（4）另起一段非業(yè)務(wù)代碼，獲得該信息

（5）嘗試刪除緩存操作，發(fā)現(xiàn)刪除失敗

（6）將這些信息發(fā)送至消息隊(duì)列

（7）重新從消息隊(duì)列中獲得該數(shù)據(jù)，重試操作。

備注說(shuō)明：上述的訂閱binlog程序在mysql中有現(xiàn)成的中間件**叫canal，**可以完成訂閱binlog日志的功能。至于oracle中，博主目前不知道有沒(méi)有現(xiàn)成中間件可以使用。另外，重試機(jī)制，博主是采用的是消息隊(duì)列的方式。如果對(duì)一致性要求不是很高，直接在程序中另起一個(gè)線程，每隔一段時(shí)間去重試即可，這些大家可以靈活自由發(fā)揮，只是提供一個(gè)思路。

三.總結(jié)

本文其實(shí)是對(duì)目前互聯(lián)網(wǎng)中已有的一致性方案，進(jìn)行了一個(gè)總結(jié)。對(duì)于先刪緩存，再更新數(shù)據(jù)庫(kù)的更新策略，還有方案提出維護(hù)一個(gè)內(nèi)存隊(duì)列的方式，博主看了一下，覺(jué)得實(shí)現(xiàn)異常復(fù)雜，沒(méi)有必要，因此沒(méi)有必要在文中給出。最后，希望大家有所收獲。

到此這篇關(guān)于Mysql和redis緩存不一致問(wèn)題解決的文章就介紹到這了,更多相關(guān)Mysql和redis緩存不一致內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論