面試常問：如何保證Redis緩存和數(shù)據(jù)庫的數(shù)據(jù)一致性
首先，我們先來看看有哪幾種一致性的情況呢？
一、一致性
1、強一致性
如果你的項目對緩存的要求是強一致性的，那么請不要使用緩存。這種一致性級別是最符合用戶直覺的，它要求系統(tǒng)寫入什么，讀出來的也會是什么，用戶體驗好，但實現(xiàn)起來往往對系統(tǒng)的性能影響大。
2、弱一致性
這種一致性級別約束了系統(tǒng)在寫入成功后，不承諾立即可以讀到寫入的值，也不承諾多久之后數(shù)據(jù)能夠達到一致，但會盡可能地保證到某個時間級別（比如秒級別）后，數(shù)據(jù)能夠達到一致狀態(tài)。
3、最終一致性
最終一致性是弱一致性的一個特例，系統(tǒng)會保證在一定時間內(nèi)，能夠達到一個數(shù)據(jù)一致的狀態(tài)。這里之所以將最終一致性單獨提出來，是因為它是弱一致性中非常推崇的一種一致性模型，也是業(yè)界在大型分布式系統(tǒng)的數(shù)據(jù)一致性上比較推崇的模型。一般情況下，高可用只確保最終一致性，不確保強一致性。
強一致性，讀請求和寫請求會串行化，串到一個內(nèi)存隊列里去，這樣會大大增加系統(tǒng)的處理效率，吞吐量也會大大降低。
二、redis緩存和mysql數(shù)據(jù)庫數(shù)據(jù)一致性解決
這張圖，大多數(shù)人的很多業(yè)務(wù)操作都是根據(jù)這個圖來做緩存的。但是一旦設(shè)計到雙寫或者
數(shù)據(jù)庫和緩存更新等操作，就很容易出現(xiàn)數(shù)據(jù)一致性的問題。無論是先寫數(shù)據(jù)庫，在刪除緩存，還是先刪除緩存，在寫入數(shù)據(jù)庫，都會出現(xiàn)數(shù)據(jù)一致性的問題。列舉兩個小例子。
1、 先刪除了redis緩存，但是因為其他什么原因還沒來得及寫入數(shù)據(jù)庫，另外一個線程就來讀取，發(fā)現(xiàn)緩存為空，則去數(shù)據(jù)庫讀取到之前的數(shù)據(jù)并寫入緩存，此時緩存中為臟數(shù)據(jù)。
2、 如果先寫入了數(shù)據(jù)庫，但是在緩存被刪除前，寫入數(shù)據(jù)庫的線程因為其他原因被中斷了，沒有刪除掉緩存，就也會出現(xiàn)數(shù)據(jù)不一致的情況。
總的來說，寫和讀在多數(shù)情況下都是并發(fā)的，不能絕對保證先后順序，就會很容易出現(xiàn)緩存和數(shù)據(jù)庫數(shù)據(jù)不一致的情況，還怎么解決呢？
1、方案一：采用延時雙刪策略
基本思路： 在寫庫前后都進行刪除緩存操作，并且設(shè)置合理的超時時間
基本步驟： 先刪除緩存–再寫數(shù)據(jù)庫—休眠一段時間—再次刪除緩存
注：休眠的時間是根據(jù)自己的項目的讀數(shù)據(jù)業(yè)務(wù)邏輯的耗時來確定的。這樣做主要是為了保證在寫請求之前確保讀請求結(jié)束，寫請求可以刪除讀請求造成的緩存臟數(shù)據(jù)。
該方案的弊端： 集合雙刪策略+緩存超時策略設(shè)置，這樣最差的結(jié)果就是在超時時間內(nèi)數(shù)據(jù)存在不一致，又增加了寫請求的耗時。
2、方案二：一步更新緩存（基于訂閱Binlog的同步機制）
基本思路： mysql Binlog增強訂閱消費+消息隊列+增量數(shù)據(jù)更新到redis—讀redis：熱數(shù)據(jù)基本上都在redis—寫mysql：增刪改都是操作mysql—更新redis數(shù)據(jù)：mysql的數(shù)據(jù)操作Binlog，來更新redis
我們再來看看詳細(xì)的過程
1、Redis更新
1）、數(shù)據(jù)操作主要分為兩大塊：
一個是全量，將全部數(shù)據(jù)寫去redis；另一個就是增量（update、insert、delete），實時更新。
2）、讀取binlog后分析 ，利用消息隊列,推送更新各臺的redis緩存數(shù)據(jù)。
這樣一旦MySQL中產(chǎn)生了新的寫入、更新、刪除等操作，就可以把binlog相關(guān)的消息推送至Redis，Redis再根據(jù)binlog中的記錄，對Redis進行更新。
其實這種機制，很類似MySQL的主從備份機制，因為MySQL的主備也是通過binlog來實現(xiàn)的數(shù)據(jù)一致性。
這里可以結(jié)合使用canal(阿里的一款開源框架)，通過該框架可以對MySQL的binlog進行訂閱，而canal正是模仿了mysql的slave數(shù)據(jù)庫的備份請求，使得Redis的數(shù)據(jù)更新達到了相同的效果。
當(dāng)然，這里的消息推送工具你也可以采用別的第三方：kafka、rabbitMQ等來實現(xiàn)推送更新Redis。
歡迎小伙伴們留言討論！
以上就是面試官常問：如何保證Redis緩存和數(shù)據(jù)庫的數(shù)據(jù)一致性的詳細(xì)內(nèi)容，更多關(guān)于Redis緩存和數(shù)據(jù)庫數(shù)據(jù)一致的資料請關(guān)注腳本之家其它相關(guān)文章！
相關(guān)文章
在使用redis的過期時間時不由想到設(shè)置了過期時間,下面這篇文章主要給大家介紹了關(guān)于redis過期時間問題的相關(guān)資料,文中通過實例代碼介紹的非常詳細(xì),需要的朋友可以參考下2023-04-04
這篇文章主要介紹了redis keys與scan命令的區(qū)別說明，具有很好的參考價值，希望對大家有所幫助。一起跟隨小編過來看看吧2021-03-03
在 主從架構(gòu)Redis搭建主從集群 中,一個slave節(jié)點掛了無影響,但是master節(jié)點掛了,就無法進行寫操作了,影響高可用,Redis 提供了哨兵（Sentinel）機制來實現(xiàn)主從集群的自動故障恢復(fù),本文給大家介紹了Redis 搭建哨兵集群的操作步驟,需要的朋友可以參考下2023-08-08
Redis集群的三種部署方式及三種應(yīng)用問題的處理
這篇文章主要介紹了Redis集群的三種部署方式及三種應(yīng)用問題的處理,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2024-04-04
這篇文章主要介紹了Redis批量刪除KEY的方法,本文借助了Linux xargs命令實現(xiàn),需要的朋友可以參考下2014-11-11
淺析redis cluster介紹與gossip協(xié)議
這篇文章主要介紹了redis cluster介紹與gossip協(xié)議,本文給大家介紹的非常詳細(xì)，對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值，需要的朋友可以參考下2020-09-09
使用寶塔在服務(wù)器上配置Redis的詳細(xì)圖文教程
這篇文章主要給大家介紹了關(guān)于使用寶塔在服務(wù)器上配置Redis的相關(guān)資料,包括下載和安裝Redis,開放端口,修改配置文件以允許遠程訪問和設(shè)置密碼,該過程對于理解Redis在項目部署中的配置提供了實用指導(dǎo),需要的朋友可以參考下2024-11-11
Key的過期機制是Redis保持高可用性的重要策略,過期策略分為惰性過期和定期過期,惰性過期在每次訪問key時檢查是否過期,定期過期則由serverCron方法定時清理過期key,本文就來詳細(xì)的介紹一下,感興趣的可以了解一下2024-09-09
對于我們用戶來講,我們在登陸一個APP的時候,有很多種登陸方式,比如"微信掃碼"、"手機號登陸"、"支付寶掃碼"、"賬號密碼登錄",現(xiàn)在大多都會要求微信掃碼登錄或者是手機號驗證碼登錄,所以本文給大家介紹了基于Redis實現(xiàn)短信驗證碼登錄功能,需要的朋友可以參考下2025-01-01
這篇文章主要介紹了查看redis占用內(nèi)存的實現(xiàn)方法,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2024-01-01