在《究竟先操作緩存，還是數(shù)據(jù)庫?》，有同學(xué)在評論提出，相關(guān)方案違背了“Cache Aside Pattern”的原則，故今天聊一聊Cache Aside Pattern。

[[236538]]

另外，在討論技術(shù)方案時，盡量不說：

• “你是錯的，應(yīng)該怎么樣”
• “facebook不是這樣，所以你是錯的”

畫外音：憑什么facebook就是真理?它的方案只是適合它的業(yè)務(wù)而已。

說明適用場景，說明來龍去脈，說明前因后果，比具體使用什么方案更重要。

什么是“Cache Aside Pattern”?

答：旁路緩存方案的經(jīng)驗實踐，這個實踐又分讀實踐，寫實踐。

對于讀請求

• 先讀cache，再讀db
• 如果，cache hit，則直接返回數(shù)據(jù)
• 如果，cache miss，則訪問db，并將數(shù)據(jù)set回緩存

如上圖：

• 先從cache中嘗試get數(shù)據(jù)，結(jié)果miss了
• 再從db中讀取數(shù)據(jù)，從庫，讀寫分離
• ***把數(shù)據(jù)set回cache，方便下次讀***

畫外音：這一點上，與《究竟先操作緩存，還是數(shù)據(jù)庫?》說的是一致的。

對于寫請求

• 淘汰緩存，而不是更新緩存
• 先操作數(shù)據(jù)庫，再淘汰緩存

如上圖：

(1)***步要操作數(shù)據(jù)庫，第二步操作緩存

畫外音：這一點上，與《究竟先操作緩存，還是數(shù)據(jù)庫?》說的不一致，也是評論反駁比較激烈的地方。

(2)緩存，采用delete淘汰，而不是set更新

畫外音：這一點上，與《緩存，究竟是淘汰，還是修改?》說的是一致的。

Cache Aside Pattern為什么建議淘汰緩存，而不是更新緩存?

答：如果更新緩存，在并發(fā)寫時，可能出現(xiàn)數(shù)據(jù)不一致。

如上圖所示，如果采用set緩存。

在1和2兩個并發(fā)寫發(fā)生時，由于無法保證時序，此時不管先操作緩存還是先操作數(shù)據(jù)庫，都可能出現(xiàn)：

• 請求1先操作數(shù)據(jù)庫，請求2后操作數(shù)據(jù)庫
• 請求2先set了緩存，請求1后set了緩存

導(dǎo)致，數(shù)據(jù)庫與緩存之間的數(shù)據(jù)不一致。

所以，Cache Aside Pattern建議，delete緩存，而不是set緩存。

Cache Aside Pattern為什么建議先操作數(shù)據(jù)庫，再操作緩存?

答：如果先操作緩存，在讀寫并發(fā)時，可能出現(xiàn)數(shù)據(jù)不一致。

如上圖所示，如果先操作緩存。

在1和2并發(fā)讀寫發(fā)生時，由于無法保證時序，可能出現(xiàn)：

• 寫請求淘汰了緩存
• 寫請求操作了數(shù)據(jù)庫(主從同步?jīng)]有完成)
• 讀請求讀了緩存(cache miss)
• 讀請求讀了從庫(讀了一個舊數(shù)據(jù))
• 讀請求set回緩存(set了一個舊數(shù)據(jù))
• 數(shù)據(jù)庫主從同步完成

導(dǎo)致，數(shù)據(jù)庫與緩存的數(shù)據(jù)不一致。

所以，Cache Aside Pattern建議，先操作數(shù)據(jù)庫，再操作緩存。

Cache Aside Pattern方案存在什么問題?

答：如果先操作數(shù)據(jù)庫，再淘汰緩存，在原子性被破壞時：

• 修改數(shù)據(jù)庫成功了
• 淘汰緩存失敗了

導(dǎo)致，數(shù)據(jù)庫與緩存的數(shù)據(jù)不一致。

如何解決這類問題呢?

答：詳見《究竟先操作緩存，還是數(shù)據(jù)庫?》。

【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】

戳這里，看該作者更多好文