1.什么是一致性，數據一致性

一致性就是數據保持一致，在分布式系統中，可以理解為多個節點中數據的值是一致的。比如你用reids緩存某個用戶信息，同時，數據庫也有保存這個用戶的記錄。那就要保持數據庫和redis保存用戶數據的一致性。

圖片

一致性一般分：強一致性、弱一致性、最終一致性。

• 強一致性：這種一致性級別是最符合用戶直覺的，它要求系統寫入什么，讀出來的也會是什么，用戶體驗好，但實現起來往往對系統的性能影響大
• 弱一致性：這種一致性級別約束了系統在寫入成功后，不承諾立即可以讀到寫入的值，也不承諾多久之后數據能夠達到一致，但會盡可能地保證到某個時間級別（比如秒級別）后，數據能夠達到一致狀態
• 最終一致性：最終一致性是弱一致性的一個特例，系統會保證在一定時間內，能夠達到一個數據一致的狀態。這里之所以將最終一致性單獨提出來，是因為它是弱一致性中非常推崇的一種一致性模型，也是業界在大型分布式系統的數據一致性上比較推崇的模型。

2. 日常開發中，我們怎么用緩存的？哪種緩存模式？

2.1 Cache-Aside

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

圖片

1. 讀的時候，先讀緩存，緩存命中的話，直接返回數據
2. 緩存沒有命中的話，就去讀數據庫，從數據庫取出數據，放入緩存后，同時返回響應。

如果是寫的請求，就是這樣：

圖片

更新的時候，先更新數據庫，然后再刪除緩存。

其實這個就是Cache-Aside的讀流程和寫流程。Cache-Aside不就是一種經典的緩存模式，同時還有

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

還是簡單介紹下這兩個吧~~

2.2 Read/Write-Through

Read/Write-Through模式中，服務端把緩存作為主要數據存儲。應用程序跟數據庫緩存交互，都是通過抽象緩存層完成的。

Read-ThroughRead-Through的簡要流程如下：

圖片

Read-Through簡要流程

1. 從緩存讀取數據，讀到直接返回
2. 如果讀取不到的話，從數據庫加載，寫入緩存后，再返回響應。

這個簡要流程是不是跟Cache-Aside很像呢？其實Read-Through就是多了一層Cache-Provider而已，流程如下：

圖片

Read-Through實際只是在Cache-Aside之上進行了一層封裝，它會讓程序代碼變得更簡潔，同時也減少數據源上的負載。

Write-Through

Write-Through模式下，當發生寫請求時，也是由緩存抽象層完成數據源和緩存數據的更新,流程如下：

圖片

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

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

圖片

Write behind流程 這種方式下，緩存和數據庫的一致性不強，對一致性要求高的系統要謹慎使用。但是它適合頻繁寫的場景，MySQL的InnoDB Buffer Pool機制就使用到這種模式。

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

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

圖片

我們在操作緩存的時候，到底應該刪除緩存還是更新緩存呢？我們先來看個例子：

圖片

1. 線程A先發起一個寫操作，第一步先更新數據庫
2. 線程B再發起一個寫操作，第二步更新了數據庫
3. 由于網絡等原因，線程B先更新了緩存
4. 線程A更新緩存。這時候，緩存保存的是A的數據（老數據），數據庫保存的是B的數據（新數據），數據不一致了，臟數據出現啦。如果是刪除緩存取代更新緩存則不會出現這個臟數據問題。

更新緩存相對于刪除緩存，還有兩點劣勢：

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

4. 雙寫的情況下，先操作數據庫還是先操作緩存？

Cache-Aside緩存模式中，有些小伙伴還是會有疑問，在寫請求過來的時候，為什么是先操作數據庫呢？為什么不先操作緩存呢？

假設有A、B兩個請求，請求A做更新操作，請求B做查詢讀取操作：

圖片

1. 線程A發起一個寫操作，第一步del cache
2. 此時線程B發起一個讀操作，cache miss
3. 線程B繼續讀DB，讀出來一個老數據
4. 然后線程B把老數據設置入cache
5. 線程A寫入DB最新的數據

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

個別小伙伴可能會問，先操作數據庫再操作緩存，不一樣也會導致數據不一致嘛？它倆又不是原子性操作的。這個是會的，但是這種方式，一般因為刪除緩存失敗等原因，才會導致臟數據，這個概率就很低。小伙伴們可以畫下操作流程圖，自己先分析下哈。接下來我們再來分析這種刪除緩存失敗的情況，如何保證一致性。

5. 數據庫和緩存數據保持強一致，可以嘛？

實際上，沒辦法做到數據庫與緩存絕對的一致性。

• 加鎖可以嘛？并發寫期間加鎖，任何讀操作不寫入緩存？
• 緩存及數據庫封裝CAS樂觀鎖，更新緩存時通過lua腳本？
• 分布式事務，3PC？TCC？其實，這是由CAP理論決定的。緩存系統適用的場景就是非強一致性的場景，它屬于CAP中的AP。個人覺得，追求絕對一致性的業務場景，不適合引入緩存。

CAP理論:指的是在一個分布式系統中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性），三者不可得兼。” 但是，通過一些方案優化處理，是可以保證弱一致性，最終一致性的。

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

它是保證數據庫與緩存數據一致性的一種方案：

圖片

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

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

這個休眠時間 =  讀業務邏輯數據的耗時 + 幾百毫秒。它為了確保讀請求結束，寫請求可以刪除讀請求可能帶來的緩存臟數據。

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

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

7.1 刪除緩存重試機制

不管是延時雙刪還是Cache-Aside的先操作數據庫再刪除緩存，都可能會存在第二步的刪除緩存失敗，導致的數據不一致問題。

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

圖片

1. 寫請求更新數據庫
2. 緩存因為某些原因，刪除失敗
3. 把刪除失敗的key放到消息隊列
4. 消費消息隊列的消息，獲取要刪除的key
5. 重試刪除緩存操作

7.2 讀取biglog異步刪除緩存

重試刪除緩存機制還可以吧，就是會造成好多業務代碼入侵。其實，還可以這樣優化：通過數據庫的binlog來異步淘汰key。

圖片

以mysql為例吧

• 可以使用阿里的canal將binlog日志采集發送到MQ隊列里面
• 然后通過ACK機制確認處理這條更新消息，刪除緩存，保證數據緩存一致性