1.什么是一致性，數(shù)據(jù)一致性

一致性就是數(shù)據(jù)保持一致，在分布式系統(tǒng)中，可以理解為多個(gè)節(jié)點(diǎn)中數(shù)據(jù)的值是一致的。比如你用reids緩存某個(gè)用戶信息，同時(shí)，數(shù)據(jù)庫(kù)也有保存這個(gè)用戶的記錄。那就要保持?jǐn)?shù)據(jù)庫(kù)和redis保存用戶數(shù)據(jù)的一致性。

圖片

一致性一般分：強(qiáng)一致性、弱一致性、最終一致性。

• 強(qiáng)一致性：這種一致性級(jí)別是最符合用戶直覺的，它要求系統(tǒng)寫入什么，讀出來的也會(huì)是什么，用戶體驗(yàn)好，但實(shí)現(xiàn)起來往往對(duì)系統(tǒng)的性能影響大
• 弱一致性：這種一致性級(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ù)一致性上比較推崇的模型。

2. 日常開發(fā)中，我們?cè)趺从镁彺娴模磕姆N緩存模式？

2.1 Cache-Aside

日常開發(fā)中，我們是如何使用緩存的呢？如果是讀請(qǐng)求，一般都是這樣吧：

圖片

1. 讀的時(shí)候，先讀緩存，緩存命中的話，直接返回?cái)?shù)據(jù)
2. 緩存沒有命中的話，就去讀數(shù)據(jù)庫(kù)，從數(shù)據(jù)庫(kù)取出數(shù)據(jù)，放入緩存后，同時(shí)返回響應(yīng)。

如果是寫的請(qǐng)求，就是這樣：

圖片

更新的時(shí)候，先更新數(shù)據(jù)庫(kù)，然后再刪除緩存。

其實(shí)這個(gè)就是Cache-Aside的讀流程和寫流程。Cache-Aside不就是一種經(jīng)典的緩存模式，同時(shí)還有

• Read-Through/Write-through
• Write-behind

還是簡(jiǎn)單介紹下這兩個(gè)吧~~

2.2 Read/Write-Through

Read/Write-Through模式中，服務(wù)端把緩存作為主要數(shù)據(jù)存儲(chǔ)。應(yīng)用程序跟數(shù)據(jù)庫(kù)緩存交互，都是通過抽象緩存層完成的。

Read-ThroughRead-Through的簡(jiǎn)要流程如下：

圖片

Read-Through簡(jiǎn)要流程

1. 從緩存讀取數(shù)據(jù)，讀到直接返回
2. 如果讀取不到的話，從數(shù)據(jù)庫(kù)加載，寫入緩存后，再返回響應(yīng)。

這個(gè)簡(jiǎn)要流程是不是跟Cache-Aside很像呢？其實(shí)Read-Through就是多了一層Cache-Provider而已，流程如下：

圖片

Read-Through實(shí)際只是在Cache-Aside之上進(jìn)行了一層封裝，它會(huì)讓程序代碼變得更簡(jiǎn)潔，同時(shí)也減少數(shù)據(jù)源上的負(fù)載。

Write-Through

Write-Through模式下，當(dāng)發(fā)生寫請(qǐng)求時(shí)，也是由緩存抽象層完成數(shù)據(jù)源和緩存數(shù)據(jù)的更新,流程如下：

圖片

2.3 Write-behind （異步緩存寫入）

Write-behind 跟Read-Through/Write-Through有相似的地方，都是由Cache Provider來負(fù)責(zé)緩存和數(shù)據(jù)庫(kù)的讀寫。它們又有個(gè)很大的不同：Read/Write-Through是同步更新緩存和數(shù)據(jù)的，Write-Behind則是只更新緩存，不直接更新數(shù)據(jù)庫(kù)，通過批量異步的方式來更新數(shù)據(jù)庫(kù)。

圖片

Write behind流程 這種方式下，緩存和數(shù)據(jù)庫(kù)的一致性不強(qiáng)，對(duì)一致性要求高的系統(tǒng)要謹(jǐn)慎使用。但是它適合頻繁寫的場(chǎng)景，MySQL的InnoDB Buffer Pool機(jī)制就使用到這種模式。

3. 操作緩存的時(shí)候，到底是刪除緩存呢，還是更新緩存？

我們回歸主題，延遲雙刪的時(shí)候，就跟刪除緩存有關(guān)聯(lián)，為什么是刪除緩存呢？更新緩存不可以嗎？這是Cache-Aside寫入流程：

圖片

我們?cè)诓僮骶彺娴臅r(shí)候，到底應(yīng)該刪除緩存還是更新緩存呢？我們先來看個(gè)例子：

圖片

1. 線程A先發(fā)起一個(gè)寫操作，第一步先更新數(shù)據(jù)庫(kù)
2. 線程B再發(fā)起一個(gè)寫操作，第二步更新了數(shù)據(jù)庫(kù)
3. 由于網(wǎng)絡(luò)等原因，線程B先更新了緩存
4. 線程A更新緩存。這時(shí)候，緩存保存的是A的數(shù)據(jù)（老數(shù)據(jù)），數(shù)據(jù)庫(kù)保存的是B的數(shù)據(jù)（新數(shù)據(jù)），數(shù)據(jù)不一致了，臟數(shù)據(jù)出現(xiàn)啦。如果是刪除緩存取代更新緩存則不會(huì)出現(xiàn)這個(gè)臟數(shù)據(jù)問題。

更新緩存相對(duì)于刪除緩存，還有兩點(diǎn)劣勢(shì)：

• 如果你寫入的緩存值，是經(jīng)過復(fù)雜計(jì)算才得到的話。更新緩存頻率高的話，就浪費(fèi)性能啦。
• 在寫數(shù)據(jù)庫(kù)場(chǎng)景多，讀數(shù)據(jù)場(chǎng)景少的情況下，數(shù)據(jù)很多時(shí)候還沒被讀取到，又被更新了，這也浪費(fèi)了性能呢(實(shí)際上，寫多的場(chǎng)景，用緩存也不是很劃算的,哈哈)

4. 雙寫的情況下，先操作數(shù)據(jù)庫(kù)還是先操作緩存？

Cache-Aside緩存模式中，有些小伙伴還是會(huì)有疑問，在寫請(qǐng)求過來的時(shí)候，為什么是先操作數(shù)據(jù)庫(kù)呢？為什么不先操作緩存呢？

假設(shè)有A、B兩個(gè)請(qǐng)求，請(qǐng)求A做更新操作，請(qǐng)求B做查詢讀取操作：

圖片

1. 線程A發(fā)起一個(gè)寫操作，第一步del cache
2. 此時(shí)線程B發(fā)起一個(gè)讀操作，cache miss
3. 線程B繼續(xù)讀DB，讀出來一個(gè)老數(shù)據(jù)
4. 然后線程B把老數(shù)據(jù)設(shè)置入cache
5. 線程A寫入DB最新的數(shù)據(jù)

醬紫就有問題啦，緩存和數(shù)據(jù)庫(kù)的數(shù)據(jù)不一致了。緩存保存的是老數(shù)據(jù)，數(shù)據(jù)庫(kù)保存的是新數(shù)據(jù)。因此，Cache-Aside緩存模式，選擇了先操作數(shù)據(jù)庫(kù)而不是先操作緩存。

個(gè)別小伙伴可能會(huì)問，先操作數(shù)據(jù)庫(kù)再操作緩存，不一樣也會(huì)導(dǎo)致數(shù)據(jù)不一致嘛？它倆又不是原子性操作的。這個(gè)是會(huì)的，但是這種方式，一般因?yàn)閯h除緩存失敗等原因，才會(huì)導(dǎo)致臟數(shù)據(jù)，這個(gè)概率就很低。小伙伴們可以畫下操作流程圖，自己先分析下哈。接下來我們?cè)賮矸治鲞@種刪除緩存失敗的情況，如何保證一致性。

5. 數(shù)據(jù)庫(kù)和緩存數(shù)據(jù)保持強(qiáng)一致，可以嘛？

實(shí)際上，沒辦法做到數(shù)據(jù)庫(kù)與緩存絕對(duì)的一致性。

• 加鎖可以嘛？并發(fā)寫期間加鎖，任何讀操作不寫入緩存？
• 緩存及數(shù)據(jù)庫(kù)封裝CAS樂觀鎖，更新緩存時(shí)通過lua腳本？
• 分布式事務(wù)，3PC？TCC？其實(shí)，這是由CAP理論決定的。緩存系統(tǒng)適用的場(chǎng)景就是非強(qiáng)一致性的場(chǎng)景，它屬于CAP中的AP。個(gè)人覺得，追求絕對(duì)一致性的業(yè)務(wù)場(chǎng)景，不適合引入緩存。

CAP理論:指的是在一個(gè)分布式系統(tǒng)中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區(qū)容錯(cuò)性），三者不可得兼。” 但是，通過一些方案優(yōu)化處理，是可以保證弱一致性，最終一致性的。

6. 什么是延遲雙刪呢？這個(gè)延遲到底是多久呢？

它是保證數(shù)據(jù)庫(kù)與緩存數(shù)據(jù)一致性的一種方案：

圖片

• 先刪除緩存：在更新數(shù)據(jù)庫(kù)之前，首先刪除緩存中的數(shù)據(jù)，以避免在更新過程中讀取到舊數(shù)據(jù)。
• 更新數(shù)據(jù)庫(kù)：執(zhí)行數(shù)據(jù)庫(kù)的更新操作。
• 休眠一段時(shí)間：根據(jù)業(yè)務(wù)讀取數(shù)據(jù)的平均耗時(shí)，設(shè)置一個(gè)休眠時(shí)間（如1秒），以確保在此期間內(nèi)所有可能的讀請(qǐng)求都已經(jīng)結(jié)束，并且可能因讀取舊數(shù)據(jù)而寫入的臟數(shù)據(jù)已經(jīng)被緩存。
• 再次刪除緩存：休眠結(jié)束后，再次刪除緩存中的數(shù)據(jù)，以清除可能因讀請(qǐng)求而寫入的臟數(shù)據(jù)。

這個(gè)延遲到底是多久呢？ 這個(gè)休眠一會(huì)，一般多久呢？十幾毫秒？幾百毫秒？還是1秒？

這個(gè)休眠時(shí)間 =  讀業(yè)務(wù)邏輯數(shù)據(jù)的耗時(shí) + 幾百毫秒。它為了確保讀請(qǐng)求結(jié)束，寫請(qǐng)求可以刪除讀請(qǐng)求可能帶來的緩存臟數(shù)據(jù)。

這種方案還算可以，只有休眠那一會(huì)（比如就那1秒），可能有臟數(shù)據(jù)，一般業(yè)務(wù)也會(huì)接受的。但是如果第二次刪除緩存失敗呢？緩存和數(shù)據(jù)庫(kù)的數(shù)據(jù)還是可能不一致，對(duì)吧？給Key設(shè)置一個(gè)自然的expire過期時(shí)間，讓它自動(dòng)過期怎樣？那業(yè)務(wù)要接受過期時(shí)間內(nèi)，數(shù)據(jù)的不一致咯？還是有其他更佳方案呢？

7. 其他方案如：刪除緩存重試機(jī)制和讀取biglog異步刪除緩存

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

不管是延時(shí)雙刪還是Cache-Aside的先操作數(shù)據(jù)庫(kù)再刪除緩存，都可能會(huì)存在第二步的刪除緩存失敗，導(dǎo)致的數(shù)據(jù)不一致問題。

可以使用這個(gè)方案優(yōu)化：刪除失敗就多刪除幾次呀,保證刪除緩存成功就可以了呀~ 所以可以引入刪除緩存重試機(jī)制。

圖片

1. 寫請(qǐng)求更新數(shù)據(jù)庫(kù)
2. 緩存因?yàn)槟承┰颍瑒h除失敗
3. 把刪除失敗的key放到消息隊(duì)列
4. 消費(fèi)消息隊(duì)列的消息，獲取要?jiǎng)h除的key
5. 重試刪除緩存操作

7.2 讀取biglog異步刪除緩存

重試刪除緩存機(jī)制還可以吧，就是會(huì)造成好多業(yè)務(wù)代碼入侵。其實(shí)，還可以這樣優(yōu)化：通過數(shù)據(jù)庫(kù)的binlog來異步淘汰key。

圖片

以mysql為例吧

• 可以使用阿里的canal將binlog日志采集發(fā)送到MQ隊(duì)列里面
• 然后通過ACK機(jī)制確認(rèn)處理這條更新消息，刪除緩存，保證數(shù)據(jù)緩存一致性