共計 1515 個字符，預計需要花費 4 分鐘才能閱讀完成。

這篇文章將為大家詳細講解有關數據庫緩存最終一致性的四種方案分別是什么，文章內容質量較高，因此丸趣 TV 小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

背景

緩存是軟件開發中一個非常有用的概念，數據庫緩存更是在項目中必然會遇到的場景。而緩存一致性的保證，更是在面試中被反復問到，這里進行一下總結，針對不同的要求，選擇恰到好處的一致性方案。

緩存是什么

存儲的速度是有區別的。緩存就是把低速存儲的結果，臨時保存在高速存儲的技術。

如圖所示，金字塔更上面的存儲，可以作為下面存儲的緩存。我們本次的討論，主要針對數據庫緩存場景，將以 redis 作為 mysql 的緩存為案例來進行。

為什么需要緩存

存儲如 mysql 通常支持完整的 ACID 特性，因為可靠性，持久性等因素，性能普遍不高，高并發的查詢會給 mysql 帶來壓力，造成數據庫系統的不穩定。同時也容易產生延遲。根據局部性原理，80% 請求會落到 20% 的熱點數據上，在讀多寫少場景，增加一層緩存非常有助提升系統吞吐量和健壯性。

存在問題

存儲的數據隨著時間可能會發生變化，而緩存中的數據就會不一致。具體能容忍的不一致時間，需要具體業務具體分析，但是通常的業務，都需要做到最終一致。

redis 作為 mysql 緩存

通常的開發模式中，都會使用 mysql 作為存儲，而 redis 作為緩存，加速和保護 mysql。但是，當 mysql 數據更新之后，redis 怎么保持同步呢。

強一致性同步成本太高，如果追求強一致，那么沒必要用緩存了，直接用 mysql 即可。通常考慮的，都是最終一致性。

解決方案

方案一

通過 key 的過期時間，mysql 更新時，redis 不更新。這種方式實現簡單，但不一致的時間會很長。如果讀請求非常頻繁，且過期時間比較長，則會產生很多長期的臟數據。

優點：

開發成本低，易于實現；

管理成本低，出問題的概率會比較小。

不足:

完全依賴過期時間，時間太短容易緩存頻繁失效，太長容易有長時間更新延遲

方案二

在方案一的基礎上擴展，通過 key 的過期時間兜底，并且，在更新 mysql 時，同時更新 redis。

優點:

相對方案一，更新延遲更小。

不足:

如果更新 mysql 成功，更新 redis 卻失敗，就退化到了方案一；

在高并發場景，業務 server 需要和 mysql,redis 同時進行連接。這樣是損耗雙倍的連接資源，容易造成連接數過多的問題。

方案三

針對方案二的同步寫 redis 進行優化，增加消息隊列，將 redis 更新操作交給 kafka，由消息隊列保證可靠性，再搭建一個消費服務，來異步更新 redis。

優點:

消息隊列可以用一個句柄，很多消息隊列客戶端還支持本地緩存發送，有效解決了方案二連接數過多的問題；

使用消息隊列，實現了邏輯上的解耦；

消息隊列本身具有可靠性，通過手動提交等手段，可以至少一次消費到 redis。

不足:

依舊解決不了時序性問題，如果多臺業務服務器分別處理針對同一行數據的兩條請求，舉個栗子，a = 1；a = 5;，如果 mysql 中是第一條先執行，而進入 kafka 的順序是第二條先執行，那么數據就會產生不一致。

引入了消息隊列，同時要增加服務消費消息，成本較高。

方案四

通過訂閱 binlog 來更新 redis，把我們搭建的消費服務，作為 mysql 的一個 slave，訂閱 binlog，解析出更新內容，再更新到 redis。

優點:

在 mysql 壓力不大情況下，延遲較低；

和業務完全解耦；

解決了時序性問題。

缺點:

要單獨搭建一個同步服務，并且引入 binlog 同步機制，成本較大。

關于數據庫緩存最終一致性的四種方案分別是什么就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。