數(shù)據(jù)庫(kù)跟緩存的雙寫一致性怎么理解

1 關(guān)于一致性

為加速系統(tǒng)性能一般都會(huì)引入緩存機(jī)制，比如 Redis。這種情況下當(dāng)用戶讀數(shù)據(jù)時(shí)一般會(huì)按照如下流程：

 

1. 先更新數(shù)據(jù)庫(kù)再更新緩存。

2. 先刪緩存再更新數(shù)據(jù)庫(kù)。

3. 先更新數(shù)據(jù)庫(kù)再刪緩存。

2 一致性解決方法

2.1 緩存TTL

簡(jiǎn)單直接又暴力的方法，如果有些數(shù)據(jù)不重要，我們讀完一次數(shù)據(jù)到緩存后設(shè)置個(gè)TTL即可，等待超時(shí)后緩存自動(dòng)從數(shù)據(jù)庫(kù)讀取下數(shù)據(jù)。

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

假如我們有A、B兩個(gè)請(qǐng)求，A請(qǐng)求將age = 14，B請(qǐng)求將age = 12。我們看下正常執(zhí)行跟非正常執(zhí)行情況：

 

1. 寫場(chǎng)景多而讀場(chǎng)景少的業(yè)務(wù)需求，此時(shí)緩存不是經(jīng)常性的讀，卻被頻繁的更新。

2. 如果緩存的數(shù)據(jù)是經(jīng)過各種復(fù)雜計(jì)算后寫入的，那每次寫入緩存都要運(yùn)算一次，此法不可取。

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

假如A先請(qǐng)求更改數(shù)據(jù)，B請(qǐng)求讀數(shù)據(jù)，如果因?yàn)榫W(wǎng)絡(luò)導(dǎo)致發(fā)生如下情況也會(huì)造成緩存臟數(shù)據(jù)，如果此時(shí)緩存沒有設(shè)置TTL那會(huì)一直是臟數(shù)據(jù)。

 

public  void write(String key,Object value){
    redis.delKey(key);
    db.updateValue(value);
    Thread.sleep(1000); // 再次刪除
    redis.delKey(key);
}

該思路落實(shí)到流程圖上如下所示：

 

當(dāng)然如果用的是主從寫讀架構(gòu)，那處理思路跟上面類似，無(wú)非就是休眠時(shí)間再加上主從同步的時(shí)間即可。

 

1. 二次刪除前面涉及到休眠，可能導(dǎo)致系統(tǒng)性能降低，可以采用異步的方式，再起一個(gè)線程來(lái)進(jìn)行異步刪除。

2. 如果二次刪除失敗了，還是會(huì)導(dǎo)致緩存臟數(shù)據(jù)存在的啊！

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

針對(duì)緩存更新問題，老外提出了一個(gè)名為《Cache-Aside pattern》的緩存更新套路，該策略在Facebook中也廣泛使用，該策略指出：

1. 失效：應(yīng)用程序先從緩存取數(shù)據(jù)，沒有得到，則從數(shù)據(jù)庫(kù)中取數(shù)據(jù)，成功后，放到緩存中。

2. 命中：應(yīng)用程序從緩存中取數(shù)據(jù)，取到后返回。

3. 更新：先把數(shù)據(jù)存到數(shù)據(jù)庫(kù)中，成功后，再讓緩存失效。

假如此時(shí)A、B兩個(gè)線程同時(shí)請(qǐng)求，正常來(lái)講不管你是讀寫分離還是單機(jī)版，讀一般比寫快。那刪除緩存一般是有效的。

 

 

2.5 消息隊(duì)列 確保消息刪除

通過消息隊(duì)列的確認(rèn)消費(fèi)機(jī)制來(lái)刪除緩存。

 

1. 對(duì)業(yè)務(wù)線代碼造成大量的侵入，引入了中間件。

2. 消息的延遲刪除也會(huì)造成短暫的不一致。

2.6 專門程序+消息隊(duì)列 確保消息刪除

該方案啟動(dòng)一個(gè)訂閱程序去訂閱數(shù)據(jù)庫(kù)的binlog，獲得需要操作的數(shù)據(jù)。在應(yīng)用程序中，另起一段程序，獲得這個(gè)訂閱程序傳來(lái)的信息，進(jìn)行刪除緩存操作。