前言

如果項(xiàng)目業(yè)務(wù)處于起步階段，流量非常小，那無論是讀請(qǐng)求還是寫請(qǐng)求，直接操作數(shù)據(jù)庫(kù)即可，這時(shí)架構(gòu)模型是這樣的：

但隨著業(yè)務(wù)量的增長(zhǎng)，項(xiàng)目業(yè)務(wù)請(qǐng)求量越來越大，這時(shí)如果每次都從數(shù)據(jù)庫(kù)中讀數(shù)據(jù)，那肯定會(huì)有性能問題。這個(gè)階段通常的做法是，引入緩存來提高讀性能，架構(gòu)模型就變成了這樣：

在實(shí)際開發(fā)過程中，緩存的使用頻率是非常高的，只要使用緩存和數(shù)據(jù)庫(kù)存儲(chǔ)，就難免會(huì)出現(xiàn)雙寫時(shí)數(shù)據(jù)一致性的問題，就是 Redis 緩存的數(shù)據(jù)和數(shù)據(jù)庫(kù)中保存的數(shù)據(jù)出現(xiàn)不相同的現(xiàn)象。

如上圖所示，大多數(shù)人的很多業(yè)務(wù)操作都是根據(jù)這個(gè)圖來做緩存的，這樣能有效減輕數(shù)據(jù)庫(kù)壓力。但是一旦設(shè)計(jì)到雙寫或者數(shù)據(jù)庫(kù)和緩存更新等操作，就很容易出現(xiàn)數(shù)據(jù)一致性的問題。無論是先寫數(shù)據(jù)庫(kù)，在刪除緩存，還是先刪除緩存，在寫入數(shù)據(jù)庫(kù)，都會(huì)出現(xiàn)數(shù)據(jù)一致性的問題。例如：

• 先刪除了redis緩存，但是因?yàn)槠渌裁丛蜻€沒來得及寫入數(shù)據(jù)庫(kù)，另外一個(gè)線程就來讀取，發(fā)現(xiàn)緩存為空，則去數(shù)據(jù)庫(kù)讀取到之前的數(shù)據(jù)并寫入緩存，此時(shí)緩存中為臟數(shù)據(jù)。
• 如果先寫入了數(shù)據(jù)庫(kù)，但是在緩存被刪除前，寫入數(shù)據(jù)庫(kù)的線程因?yàn)槠渌虮恢袛嗔?，沒有刪除掉緩存，就也會(huì)出現(xiàn)數(shù)據(jù)不一致的情況。

總的來說，寫和讀在多數(shù)情況下都是并發(fā)的，不能絕對(duì)保證先后順序，就會(huì)很容易出現(xiàn)緩存和數(shù)據(jù)庫(kù)數(shù)據(jù)不一致的情況，那我們又該如何解決呢？

一、談?wù)勔恢滦?/h2>

首先，我們先來看看有哪幾種一致性的情況呢？

• 強(qiáng)一致性：如果你的項(xiàng)目對(duì)緩存的要求是強(qiáng)一致性的，那么請(qǐng)不要使用緩存。這種一致性級(jí)別是最符合用戶直覺的，它要求系統(tǒng)寫入什么，讀出來的也會(huì)是什么，用戶體驗(yàn)好，但實(shí)現(xiàn)起來往往對(duì)系統(tǒng)的性能影響大。讀請(qǐng)求和寫請(qǐng)求會(huì)串行化，串到一個(gè)內(nèi)存隊(duì)列里去，這樣會(huì)大大增加系統(tǒng)的處理效率，吞吐量也會(huì)大大降低。
• 弱一致性：這種一致性級(jí)別約束了系統(tǒng)在寫入成功后，不承諾立即可以讀到寫入的值，也不承諾多久之后數(shù)據(jù)能夠達(dá)到一致，但會(huì)盡可能地保證到某個(gè)時(shí)間級(jí)別（比如秒級(jí)別）后，數(shù)據(jù)能夠達(dá)到一致狀態(tài)。
• 最終一致性：最終一致性是弱一致性的一個(gè)特例，系統(tǒng)會(huì)保證在一定時(shí)間內(nèi)，能夠達(dá)到一個(gè)數(shù)據(jù)一致的狀態(tài)。這里之所以將最終一致性單獨(dú)提出來，是因?yàn)樗侨跻恢滦灾蟹浅Ｍ瞥绲囊环N一致性模型，也是業(yè)界在大型分布式系統(tǒng)的數(shù)據(jù)一致性上比較推崇的模型。一般情況下，高可用只確保最終一致性，不確保強(qiáng)一致性。

二、 情景分析

2.1 針對(duì)讀場(chǎng)景

A請(qǐng)求查詢數(shù)據(jù)，如果命中緩存，那么直接取緩存數(shù)據(jù)返回即可。如果請(qǐng)求中不存在，數(shù)據(jù)庫(kù)中存在，那么直接取數(shù)據(jù)庫(kù)數(shù)據(jù)返回，然后將數(shù)據(jù)同步到Redis中。不會(huì)存在數(shù)據(jù)不一致的情況。

在高并發(fā)的情況下，A請(qǐng)求和B請(qǐng)求一起訪問某條數(shù)據(jù)，如果緩存中數(shù)據(jù)存在，直接返回即可，如果不存在，直接取數(shù)據(jù)庫(kù)數(shù)據(jù)返回即可。無論A請(qǐng)求B請(qǐng)求誰(shuí)先誰(shuí)后，本質(zhì)上沒有對(duì)數(shù)據(jù)進(jìn)行修改，數(shù)據(jù)本身沒變，只是從緩存中取還是從數(shù)據(jù)庫(kù)中取的問題，因此不會(huì)存在數(shù)據(jù)不一致的情況。

因此，單獨(dú)的讀場(chǎng)景是不會(huì)造成Redis與數(shù)據(jù)庫(kù)緩存不一致的情況，因此我們不用關(guān)心這種情況。

2.2 針對(duì)寫場(chǎng)景

如果該數(shù)據(jù)在緩存中不存在，那么直接修改數(shù)據(jù)庫(kù)中的數(shù)據(jù)即可，不會(huì)存在數(shù)據(jù)不一致的情況。

如果該數(shù)據(jù)在緩存中和數(shù)據(jù)庫(kù)中都存在，那么就需要既修改緩存中的數(shù)據(jù)又修改數(shù)據(jù)庫(kù)中的數(shù)據(jù)。如果寫數(shù)據(jù)庫(kù)的值與更新到緩存值是一樣的，可以馬上更新緩存；如果寫數(shù)據(jù)庫(kù)的值與更新緩存的值不一致，在高并發(fā)的場(chǎng)景下，還存在先后關(guān)系，這就會(huì)導(dǎo)致數(shù)據(jù)不一致的問題。例如：

• 當(dāng)更新數(shù)據(jù)時(shí)，如更新某商品的庫(kù)存，當(dāng)前商品的庫(kù)存是100，現(xiàn)在要更新為99，先更新數(shù)據(jù)庫(kù)更改成99，然后刪除緩存，發(fā)現(xiàn)刪除緩存失敗了，這意味著數(shù)據(jù)庫(kù)存的是99，而緩存是100，這導(dǎo)致數(shù)據(jù)庫(kù)和緩存不一致。
• 在高并發(fā)的情況下，如果當(dāng)刪除完緩存的時(shí)候，這時(shí)去更新數(shù)據(jù)庫(kù)，但還沒有更新完，另外一個(gè)請(qǐng)求來查詢數(shù)據(jù)，發(fā)現(xiàn)緩存里沒有，就去數(shù)據(jù)庫(kù)里查，還是以上面商品庫(kù)存為例，如果數(shù)據(jù)庫(kù)中產(chǎn)品的庫(kù)存是100，那么查詢到的庫(kù)存是100，然后插入緩存，插入完緩存后，原來那個(gè)更新數(shù)據(jù)庫(kù)的線程把數(shù)據(jù)庫(kù)更新為了99，導(dǎo)致數(shù)據(jù)庫(kù)與緩存不一致的情況。

三、同步策略

想要保證緩存與數(shù)據(jù)庫(kù)的雙寫一致，一共有4種方式，即4種同步策略：

從這4種同步策略中，我們需要作出比較的是：更新緩存與刪除緩存哪種方式更合適？應(yīng)該先操作數(shù)據(jù)庫(kù)還是先操作緩存？

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

這個(gè)方案我們一般不考慮。原因是當(dāng)數(shù)據(jù)同步時(shí)，更新 Redis 緩存成功，但更新數(shù)據(jù)庫(kù)出現(xiàn)異常時(shí)，會(huì)導(dǎo)致 Redis 緩存數(shù)據(jù)與數(shù)據(jù)庫(kù)數(shù)據(jù)完全不一致，而且這很難察覺，因?yàn)?Redis 緩存中的數(shù)據(jù)一直都存在。

只要緩存進(jìn)行了更新，后續(xù)的讀請(qǐng)求基本上就不會(huì)出現(xiàn)緩存未命中的情況。但在某些業(yè)務(wù)場(chǎng)景下，更新數(shù)據(jù)的成本較大，并不是單純將數(shù)據(jù)的數(shù)據(jù)查詢出來丟到緩存中即可，而是需要連接很多張表組裝對(duì)應(yīng)數(shù)據(jù)存入緩存中，并且可能存在更新后，該數(shù)據(jù)并不會(huì)被使用到的情況。

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

這個(gè)方案我們一般也是不考慮。原因是當(dāng)數(shù)據(jù)同步時(shí)，數(shù)據(jù)庫(kù)更新成功，但 Redis 緩存更新失敗，那么此時(shí)數(shù)據(jù)庫(kù)中是最新值，Redis 緩存中是舊值。之后的應(yīng)用系統(tǒng)的讀請(qǐng)求讀到的都是 Redis 緩存中舊數(shù)據(jù)。只有當(dāng) Redis 緩存數(shù)據(jù)失效后，才能從數(shù)據(jù)庫(kù)中重新獲得正確的值。

該方案還存在并發(fā)引發(fā)的一致性問題，假設(shè)同時(shí)有兩個(gè)線程進(jìn)行數(shù)據(jù)更新操作，如下圖所示：

從上圖可以看到，線程1雖然先于線程2發(fā)生，但線程2操作數(shù)據(jù)庫(kù)和緩存的時(shí)間，卻要比線程1的時(shí)間短，執(zhí)行時(shí)序發(fā)生錯(cuò)亂，最終這條數(shù)據(jù)結(jié)果是不符合預(yù)期的。如果是寫多讀少的場(chǎng)景，采用這種方案就會(huì)導(dǎo)致，數(shù)據(jù)壓根還沒讀到，緩存就被頻繁的更新，浪費(fèi)性能。

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

這種方案只是盡可能保證一致性而已，極端情況下，還是有可能發(fā)生數(shù)據(jù)不一致問題，原因是當(dāng)數(shù)據(jù)同步時(shí)，如果刪除 Redis 緩存失敗，更新數(shù)據(jù)庫(kù)成功，那么此時(shí)數(shù)據(jù)庫(kù)中是最新值，Redis 緩存中是舊值。之后的應(yīng)用系統(tǒng)的讀請(qǐng)求讀到的都是 Redis 緩存中舊數(shù)據(jù)。只有當(dāng) Redis 緩存數(shù)據(jù)失效后，才能從數(shù)據(jù)庫(kù)中重新獲得正確的值。由于緩存被刪除，下次查詢無法命中緩存，需要在查詢后將數(shù)據(jù)寫入緩存，增加查詢邏輯。同時(shí)在高并發(fā)的情況下，同一時(shí)間大量請(qǐng)求訪問該條數(shù)據(jù)，第一條查詢請(qǐng)求還未完成寫入緩存操作時(shí)，這種情況，大量查詢請(qǐng)求都會(huì)打到數(shù)據(jù)庫(kù)，加大數(shù)據(jù)庫(kù)壓力。

該方案還存在并發(fā)引發(fā)的一致性問題，假設(shè)同時(shí)有兩個(gè)線程進(jìn)行數(shù)據(jù)更新操作，如下圖所示。當(dāng)緩存被線程一刪除后，如果此時(shí)有新的讀請(qǐng)求（線程二）發(fā)生，由于緩存已經(jīng)被刪除，這個(gè)讀請(qǐng)求（線程二）將會(huì)去從數(shù)據(jù)庫(kù)查詢。如果此時(shí)線程一還沒有修改完數(shù)據(jù)庫(kù)，線程二從數(shù)據(jù)庫(kù)讀的數(shù)據(jù)仍然是舊值，同時(shí)線程二將讀的舊值寫入到緩存。線程一完成后，數(shù)據(jù)庫(kù)變?yōu)樾轮担彺孢€是舊值。

從上圖可見，先刪除 Redis 緩存，后更新數(shù)據(jù)庫(kù)，當(dāng)發(fā)生讀/寫并發(fā)時(shí)，還是存在數(shù)據(jù)不一致的情況。如何解決呢？最簡(jiǎn)單的解決辦法就是延時(shí)雙刪策略：先淘汰緩存、再寫數(shù)據(jù)庫(kù)、休眠后再次淘汰緩存。這樣做的目的，就是確保讀請(qǐng)求結(jié)束，寫請(qǐng)求可以刪除讀請(qǐng)求造成的緩存臟數(shù)據(jù)。

public void deleteRedisData(UserInfo userInfo){
    // 刪除Redis中的緩存數(shù)據(jù)
    jedis.del(userInfo);
    // 更新MySQL數(shù)據(jù)庫(kù)數(shù)據(jù)
    userInfoDao.update(userInfo);
    try {
        TimeUnit.SECONDS.sleep(2);
    } catch(Exception exp){
        exp.printStackTrace();
    }
    // 刪除Redis中的緩存數(shù)據(jù)
    jedis.del(userInfo);
}

延時(shí)雙刪就能徹底解決不一致嗎？當(dāng)然不一定來。首先，我們?cè)u(píng)估的延時(shí)時(shí)間并不能完全代表實(shí)際運(yùn)行過程中的耗時(shí)，運(yùn)行過程如果因?yàn)橄到y(tǒng)壓力過大，我們?cè)u(píng)估的耗時(shí)就是不準(zhǔn)確，仍然會(huì)導(dǎo)致數(shù)據(jù)不一致的出現(xiàn)。其次，延時(shí)雙刪雖然在保證事務(wù)提交完以后再進(jìn)行刪除緩存，但是如果使用的是MySQL的讀寫分離的機(jī)構(gòu)，主從同步之間其實(shí)也會(huì)有時(shí)間差。

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

實(shí)際使用中，建議采用這種方案。當(dāng)然，這種方案其實(shí)一樣也可能有失敗的情況。

當(dāng)數(shù)據(jù)同步時(shí)，如果更新數(shù)據(jù)庫(kù)成功，而刪除 Redis 緩存失敗，那么此時(shí)數(shù)據(jù)庫(kù)中是最新值，Redis 緩存中是舊值。之后的應(yīng)用系統(tǒng)的讀請(qǐng)求讀到的都是 Redis 緩存中舊數(shù)據(jù)。只有當(dāng) Redis 緩存數(shù)據(jù)失效后，才能從數(shù)據(jù)庫(kù)中重新獲得正確的值。讀的時(shí)候，先讀緩存，緩存沒有的話，就讀數(shù)據(jù)庫(kù)，然后取出數(shù)據(jù)后放入緩存，同時(shí)返回響應(yīng)。更新的時(shí)候，先更新數(shù)據(jù)庫(kù)，然后再刪除緩存。

該方案還存在并發(fā)引發(fā)的一致性問題，假設(shè)同時(shí)有兩個(gè)線程進(jìn)行數(shù)據(jù)更新操作，如下圖所示。當(dāng)數(shù)據(jù)庫(kù)的數(shù)據(jù)被更新后，如果此時(shí)緩存還沒有被刪除，那么緩存中的數(shù)據(jù)仍然是舊值。如果此時(shí)有新的讀請(qǐng)求（查詢數(shù)據(jù)）發(fā)生，由于緩存中的數(shù)據(jù)是舊值，這個(gè)讀請(qǐng)求將會(huì)獲取到舊值。當(dāng)緩存剛好失效，這時(shí)有請(qǐng)求來讀緩存（線程一），未命中緩存，然后到數(shù)據(jù)庫(kù)中讀取，在要寫入緩存時(shí)，線程二來修改了數(shù)據(jù)庫(kù)，而線程一寫入緩存的是舊的數(shù)據(jù)，導(dǎo)致了數(shù)據(jù)的不一致。

四、解決辦法

當(dāng)我們?cè)趹?yīng)用中同時(shí)使用MySQL和Redis時(shí)，如何保證兩者的數(shù)據(jù)一致性呢？下面就來分享幾種實(shí)用的解決方案。

4.1 雙寫一致性

最直接的辦法就是在業(yè)務(wù)代碼中同時(shí)對(duì)MySQL和Redis進(jìn)行更新。通常我們會(huì)先更新MySQL，然后再更新Redis。

// 更新MySQL
userMapper.update(user);
// 更新Redis
redisTemplate.opsForValue().set("user_" + user.getId(), user);

這種方式最大的問題就是在于網(wǎng)絡(luò)故障或者程序異常的情況下，可能會(huì)導(dǎo)致MySQL和Redis中的數(shù)據(jù)不一致。因此，我們需要額外的手段來檢測(cè)和修復(fù)數(shù)據(jù)不一致的情況。

4.2 異步更新(異步通知)

在更新數(shù)據(jù)庫(kù)數(shù)據(jù)時(shí)，同時(shí)發(fā)送一個(gè)異步通知給Redis，讓Redis知道數(shù)據(jù)庫(kù)數(shù)據(jù)已經(jīng)更新，需要更新緩存中的數(shù)據(jù)。這個(gè)過程是異步的，不會(huì)阻塞數(shù)據(jù)庫(kù)的更新操作。當(dāng)Redis收到異步通知后，會(huì)立即刪除緩存中對(duì)應(yīng)的數(shù)據(jù)，確保緩存中沒有舊數(shù)據(jù)。這樣，即使在這個(gè)過程中有新的讀請(qǐng)求發(fā)生，也不會(huì)讀取到舊數(shù)據(jù)。等到數(shù)據(jù)庫(kù)更新完成后，Redis再次從數(shù)據(jù)庫(kù)中讀取最新的數(shù)據(jù)并緩存起來。

// 更新MySQL
userMapper.update(user);
// 發(fā)送消息
rabbitTemplate.convertAndSend("updateUser", user.getId());

/**
 * 然后在消息消費(fèi)者中更新Redis。
 */
@RabbitListener(queues = "updateUser")
public void updateUser(String userId) {
    User user = userMapper.selectById(userId);
    redisTemplate.opsForValue().set(redisTemplate.opsForValue().set("user_" + user.getId(), user);
}

這種異步通知的方式，可以確保Redis中的數(shù)據(jù)與數(shù)據(jù)庫(kù)中的數(shù)據(jù)保持一致，避免出現(xiàn)數(shù)據(jù)不一致的情況。這種方案可以降低數(shù)據(jù)不一致的風(fēng)險(xiǎn)，但仍然無法完全避免。因?yàn)橄㈥?duì)列本身也可能因?yàn)楦鞣N原因丟失消息。

4.3 使用Redis的事務(wù)支持

Redis提供了事務(wù)（Transaction）支持，可以將一系列的操作作為一個(gè)原子操作執(zhí)行。我們可以利用Redis的事務(wù)來實(shí)現(xiàn)MySQL和Redis的原子更新。

redisTemplate.execute(new Sessioncallback<Object>(){
    @0verridepublic Object execute(RedisOperations operations) throws DataAccessException {
        // 開啟事務(wù)
        operations.multi();
        // 更新MySQL
        userMapper.update(user);
        // 更新Redis
        operations.opsForValue().set("user_" + user.getId(),user);
        // 執(zhí)行事務(wù)
        operations.exec();
        return null;
    }
});

使用Redis事務(wù)可以確保MySQL和Redis的更新在同一事務(wù)中執(zhí)行，避免了中間出現(xiàn)不一致的情況。但需要注意的是，Redis的事務(wù)并非嚴(yán)格的ACID事務(wù)，可能存在部分成功的情況。

4.4 用 Redisson 實(shí)現(xiàn)讀鎖和寫鎖

Redisson 是一個(gè)基于 Redis 的分布式 Java 對(duì)象存儲(chǔ)和緩存框架，它提供了豐富的功能和 API 來操作 Redis 數(shù)據(jù)庫(kù)，其中包括了讀寫鎖的支持。讀寫鎖是一種常用的并發(fā)控制機(jī)制，它允許多個(gè)線程同時(shí)讀取共享資源，但在寫操作時(shí)互斥，只允許一個(gè)線程進(jìn)行寫操作。使用 Redisson 的讀寫鎖方法：

• 獲取讀鎖：通過 Redisson 的 RReadWriteLock 對(duì)象的 readLock() 方法獲取讀鎖。在獲取讀鎖后，可以并發(fā)讀取共享資源，不會(huì)阻塞其他獲取讀鎖的線程。
• 獲取寫鎖：通過 Redisson 的 RReadWriteLock 對(duì)象的 writeLock() 方法獲取寫鎖。在獲取寫鎖后，其他獲取讀鎖和寫鎖的線程將被阻塞，只有當(dāng)前線程能夠進(jìn)行寫操作。
• 釋放鎖：使用完讀鎖或?qū)戞i后，應(yīng)該及時(shí)調(diào)用 unlock() 方法釋放鎖，以便其他線程可以獲取鎖并進(jìn)行操作。在 Redisson 中，讀鎖和寫鎖都繼承自鎖對(duì)象 RLock，因此可以使用 RLock 的 unlock() 方法來釋放鎖。

下面是一個(gè)使用 Redisson 讀寫鎖的示例，通過 Redisson 的 RReadWriteLock 對(duì)象獲取讀鎖和寫鎖，并在需要的代碼段中進(jìn)行相應(yīng)的操作。執(zhí)行完操作后，使用 unlock() 方法釋放鎖，最后關(guān)閉 Redisson 客戶端。

import org.redisson.Redisson;
import org.redisson.api.RLock;
import org.redisson.api.RedissonClient;
import org.redisson.config.Config;

public class RedissonReadWriteLockExample {
    public static void main(String[] args) {
        // 創(chuàng)建 Redisson 客戶端
        Config config = new Config();
        config.useSingleServer().setAddress("redis://127.0.0.1:6379");
        RedissonClient redisson = Redisson.create(config);
        
        // 獲取讀寫鎖
        RReadWriteLock rwLock = redisson.getReadWriteLock("myLock");
        RLock readLock = rwLock.readLock();
        RLock writeLock = rwLock.writeLock();
        
        try {
            // 獲取讀鎖并進(jìn)行讀操作
            readLock.lock();
            // 讀取共享資源
            
            // 獲取寫鎖并進(jìn)行寫操作
            writeLock.lock();
            // 寫入共享資源
        } finally {
            // 釋放鎖
            writeLock.unlock();
            readLock.unlock();
        }
        
        // 關(guān)閉 Redisson 客戶端
        redisson.shutdown();
    }
}

五、結(jié)語(yǔ)

綜上所述，我們提供了更全面的MySQL與Redis數(shù)據(jù)一致性解決方案。根據(jù)具體的業(yè)務(wù)需求和系統(tǒng)環(huán)境，選擇合適的方案可以提高數(shù)據(jù)一致性的可靠性。然而，每種方案都有其優(yōu)缺點(diǎn)和適用場(chǎng)景，需要綜合考慮權(quán)衡。

對(duì)于并發(fā)幾率很小的數(shù)據(jù)(如個(gè)人維度的訂單數(shù)據(jù)、用戶數(shù)據(jù)等)，這種幾乎不用考慮這個(gè)問題，很少會(huì)發(fā)生緩存不一致，可以給緩存數(shù)據(jù)加上過期時(shí)間，每隔一段時(shí)間觸發(fā)讀的主動(dòng)更新即可。就算并發(fā)很高，如果業(yè)務(wù)上能容忍短時(shí)間的緩存數(shù)據(jù)不一致(如商品名稱，商品分類菜單等)，緩存加上過期時(shí)間依然可以解決大部分業(yè)務(wù)對(duì)于緩存的要求。

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