建站
咨詢
售后
建站咨詢
新聞中心
如何解決Redis緩存和MySQL數(shù)據(jù)一致性的問題？
Redis緩存和MySQL數(shù)據(jù)一致性的問題，相信大家在大量使用redis緩存進行業(yè)務開發(fā)的場景下是一定要考慮的問題。
總有運營、產品、測試人員過來問你為什么我剛剛更新了一條數(shù)據(jù)，APP上還是原來的數(shù)據(jù)呢？你總是一句話：“加了緩存，等會兒就好”。有可能是1分鐘，有可能是半小時。問你的都屬于關系不錯，不問你直接給你提bug你也沒辦法。
下面就分享一下我個人在工作中對如何解決redis緩存和MySQL數(shù)據(jù)一致性的一些心得：
大家看了這個圖是不是就知道什么意思了？一個請求過來查詢數(shù)據(jù)，我先看看redis有沒有，有直接返回，沒有就去數(shù)據(jù)庫查出來，順便同步到redis，設置一下過期時間。下次同樣的數(shù)據(jù)查詢redis緩存就可以直接返回了。是不是很簡單很粗暴？在實時性要求不高的場景下，這種方式我估計是大家最常用的一種方式。但是他有幾個問題：
無法保證一致性：數(shù)據(jù)庫更改了數(shù)據(jù)，redis里的數(shù)據(jù)就和數(shù)據(jù)庫不一致了，產生臟讀；
緩存雪崩：這種方案要求redis里的緩存必須設置有效期，如果在同一時間大面積過期，所有請求壓力都指向數(shù)據(jù)庫，這個時候數(shù)據(jù)庫頂不住壓力就會宕機，然后整個世界都安靜了；
緩存穿透：查詢一個數(shù)據(jù)，緩存沒有，去查詢數(shù)據(jù)庫，數(shù)據(jù)庫也沒有，怎么辦？這樣的請求多了對數(shù)據(jù)庫也是壓力，沒有數(shù)據(jù)的時候也需要在redis緩存一個空值。
針對第一種方案的問題，那么大多數(shù)時候我們會繼續(xù)做一個job，去定時同步數(shù)據(jù)庫里的數(shù)據(jù)都redis緩存中，我們的業(yè)務請求直接查詢redis緩存，無論有或者沒有數(shù)據(jù)都直接返回結果。這樣可以避免緩存穿透、緩存雪崩等問題，也能緩解redis緩存和數(shù)據(jù)庫不一致的情況，但是還無法徹底解決一致性的問題。在job的間隔期內對數(shù)據(jù)的修改必須要等到下一次job的運行。
對軟件開發(fā)同學來說，這個場景太常見了?；镜乃悸肥牵簃ysql數(shù)據(jù)發(fā)生變更的時候，要及時清除redis緩存。那究竟要怎樣清除呢？
分兩種情況來說吧。
單集群。在redis集群和mysql集群都是單集群部署的情況下，需要確保如果redis查不到數(shù)據(jù)讀取mysql主庫來填充數(shù)據(jù)，此時只需要在mysql變更生效后，直接調用redis清緩存即可。
多集群。在redis集群和mysql集群都是多地多機房的部署情況下。采用單集群清緩存策略清除本機房redis集群緩存后，延遲消息通知其他機房redis集群（確保其他機房mysql集群已收到本機房mysql集群的binlog變更消息并將變更生效）。
希望能解答您的問題，喜歡的話可以關注下我哈
要看應用場景，數(shù)據(jù)變動頻繁的環(huán)境中，使用讀緩存是毫無意義的，反而加重系統(tǒng)負荷，因為要花費額外資源維護緩存和數(shù)據(jù)源的一致性。
其實redis可以當作數(shù)據(jù)庫的元數(shù)據(jù)使用，設計好數(shù)據(jù)結構就是一個簡單的關系型庫，業(yè)務數(shù)據(jù)完全放到redis中運行，MySQL當作后備庫使用。redis也有持久化機制而且很容易做鏡像，因此可以在很大時間粒度上進行數(shù)據(jù)同步，比如一天同步一次。而業(yè)務層只操作redis，與數(shù)據(jù)庫完全剝離，即使數(shù)據(jù)庫掛掉也不會導致業(yè)務中斷。
隨著技術發(fā)展，現(xiàn)在項目技術選型不像從前那樣單一的，特別是在高并發(fā)場景下的項目，都是多種技術配套著來使用。在以前，對于用戶數(shù)據(jù)無論是增刪改查，我們都是直接操作數(shù)據(jù)庫的，但在高并發(fā)場景下這樣做顯然是不合理的，于是乎我們在DB層之前加上Cache層，以此來緩解DB層的壓力。
在業(yè)界通常是將MySQL作為數(shù)據(jù)最終落地的存儲方案，而用Redis來緩存熱點數(shù)據(jù)。一般是讀數(shù)據(jù)是從Redis中讀取，增刪改則是操作MySQL。但是這樣會存在一個問題，即：讀操作和寫操作是并發(fā)的，執(zhí)行順序無法保證，這樣很容易出現(xiàn)緩存數(shù)據(jù)與數(shù)據(jù)庫中的數(shù)據(jù)不一致。
舉例說明一下：
假設我們更新了數(shù)據(jù)庫后，緩存一直沒有失效，那我們從緩存中讀取的就是臟數(shù)據(jù)。
假設緩存中的數(shù)據(jù)不存在，我們從數(shù)據(jù)庫中讀取數(shù)據(jù)然后存入緩存，此時數(shù)據(jù)庫剛好更新，那在緩存期間內，這個緩存數(shù)據(jù)就是臟數(shù)據(jù)。
如何避免Redis和MySQL中數(shù)據(jù)一致性問題呢？結合我的經(jīng)驗給出一些方案供大家參考：
1、首先確定你的業(yè)務是否要求緩存和數(shù)據(jù)庫之間是強一致性關系
如果你的業(yè)務要求數(shù)據(jù)庫和緩存之間是強一致性，那你要做的就是確保每次更新了MySQL后就同步更新Redis；
如果不需要強一致性，那我們合理控制好緩存的TTL即可。
2、借助MQ消息來更新緩存
到此，以上就是小編對于redis事務能保證一致性嗎為什么的問題就介紹到這了，希望這1點解答對大家有用。
當前題目：redis事務能保證一致性嗎
路徑分享：http://m.5511xx.com/article/cdsiieh.html
