建站
咨詢
售后
建站咨詢
新聞中心
本文轉載自微信公眾號「moon聊技術」，作者 moon聊技術。轉載本文請聯(lián)系 moon聊技術公眾號。
成都創(chuàng)新互聯(lián)專業(yè)為企業(yè)提供泗縣網(wǎng)站建設、泗縣做網(wǎng)站、泗縣網(wǎng)站設計、泗縣網(wǎng)站制作等企業(yè)網(wǎng)站建設、網(wǎng)頁設計與制作、泗縣企業(yè)網(wǎng)站模板建站服務，十余年泗縣做網(wǎng)站經(jīng)驗，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡服務。
什么是雙寫?
我們開門見山，這個很好理解，雙寫就是說，一份數(shù)據(jù)在數(shù)據(jù)庫存一份，在緩存中也存一份，給緩存一個過期時間，當讀不到緩存時從數(shù)據(jù)庫讀出來然后寫入緩存。
為什么需要雙寫呢?
當請求量越來越大的時候，系統(tǒng)會慢慢出現(xiàn)瓶頸，由于數(shù)據(jù)庫的鏈接是有限的，無法支撐較高的QPS，所以我們要想一個辦法分擔數(shù)據(jù)庫的壓力，于是就有了雙寫，將數(shù)據(jù)寫入緩存，客戶端讀取數(shù)據(jù)直接從緩存中讀取，這樣就可以提高系統(tǒng)的性能。
但是如果要使用雙寫，那么不管是先更新緩存還是先更新mysql，總會有時間間隔，那么就要保證你的業(yè)務在一定程度上允許短暫的數(shù)據(jù)不一致的情況出現(xiàn)，否則，還是不建議使用的.
那么就有人問了?雙寫一定不能保證強一致性嗎?
答案是可以，只要把所有與其相關的讀寫請求用隊列串行化，這樣就可以保證雙寫的強一致性了，但是這樣會極大的降低系統(tǒng)的QPS，非常不推薦這種做法。
既然要雙寫，那么肯定會出現(xiàn)數(shù)據(jù)庫和緩存數(shù)據(jù)不一致的情況，要怎樣去避免呢?
雙寫不一致問題要怎么解決
一.先更新數(shù)據(jù)庫，再更新緩存
這種情況會有什么問題呢?我們看下圖:
首先a先更新數(shù)據(jù)庫，按照正常流程來走，緊接著要a線程刪除緩存，可是突然后面來了個b線程，并且a線程因為各種業(yè)務原因卡住了，導致b線程先完成了，之后a線程才更新緩存。這時突然有其他線程進來讀數(shù)據(jù)，就會讀到a的數(shù)據(jù)，但是按照業(yè)務流程來走，應該讀到b的數(shù)據(jù)，此時，就出現(xiàn)了數(shù)據(jù)錯亂的問題。
- 1.線程a更新數(shù)據(jù)庫
- 2.線程b更新數(shù)據(jù)庫
- 3.線程b更新緩存
- 4.線程a更新緩存
- 5.其他線程讀數(shù)據(jù)(讀錯了)
到這里我們會發(fā)現(xiàn)，直接更新緩存是有很大的問題的，而且很多時候，在復雜點的緩存場景，緩存不單單是數(shù)據(jù)庫中直接取出來的值，有可能是聯(lián)合其他的很多數(shù)據(jù)結合計算出來的一個值。
而且可能會有一種場景，我們經(jīng)常在更新數(shù)據(jù)庫后直接更新緩存，但是在此之間并沒有緩存被訪問的需求，這樣我們就做了很多無用功，付出了很多代價。
大家應該對單例模式有所了解，其中有一種懶加載的思想，就是說，在你需要的時候再去加載，用在雙寫的情況下非常合適，也就有了下面這種先更新數(shù)據(jù)庫，再刪除緩存的模式。
二.先更新數(shù)據(jù)庫，再刪除緩存
這種情況又會有什么問題呢?
當然，這還是一種有問題的方案，我們來跟著圖盤一盤。
1:線程a更新數(shù)據(jù)庫
2:程序掛了，沒來的及刪除緩存
3.其他線程來讀數(shù)據(jù)(全都是錯的)
這種方案的問題一目了然，只要程序掛了，就會出現(xiàn)數(shù)據(jù)讀錯的情況，真實的業(yè)務你是應該讀到a線程的值，卻一直在讀之前的值。
那這種方案有沒有優(yōu)化呢?
當然也有了，其實我們可以每次寫入都記錄日志，然后修改結束后也記錄日志，通過日志狀態(tài)來判斷是否寫入成功，
- 如果沒有寫入成功后續(xù)并且沒有新的寫入請求，就補寫，
- 否則不做處理。
但是這種情況也會出現(xiàn)不一致的問題，就是如果寫數(shù)據(jù)庫程序斷了，到下次恢復數(shù)據(jù)之前這段時間，還會出現(xiàn)數(shù)據(jù)不一致的情況。
并且如果是頻繁寫入的情況，很有可能日志機制沒有發(fā)揮作用，就有新數(shù)據(jù)寫入覆蓋，并且日志系統(tǒng)還要占用額外的資源。
我懂了!應該先刪除緩存再更新數(shù)據(jù)庫，這樣就可以了!
三.先刪除緩存 再更新數(shù)據(jù)庫
來來來，繼續(xù)貼圖，是不是很熟悉?
這種方案會有問題嗎??當然有，繼續(xù)盤道：
- 1:線程a刪除緩存
- 2:線程b刪除緩存
- 3:線程a卡了
- 4:線程b更新數(shù)據(jù)庫
- 5:線程a更新數(shù)據(jù)
- 6:其他線程讀數(shù)據(jù)，讀到了a的(又錯了)
完了，這種情況居然也有問題，線程a到底行不行，每次都是你出事。
這種情況中間會有一段數(shù)據(jù)亂掉，但是隨著下次的更新數(shù)據(jù)還是會恢復正確。
難道終極方案是先刪除緩存，再更新數(shù)據(jù)庫，再更新緩存??
四.先刪除緩存，再更新數(shù)據(jù)庫，再刪除緩存
繼續(xù)貼圖
- 1.線程a刪除緩存
- 2.其他線程讀取數(shù)據(jù)，讀到的是a之前的數(shù)據(jù)
- 3.線程a更新數(shù)據(jù)庫
- 4.線程a刪除緩存
- 5.其他線程設置緩存數(shù)據(jù)，是a之前的數(shù)據(jù)(此時應該是a的)
大家是不是又發(fā)現(xiàn)了，這種設計方案還是會有問題的，直到下次數(shù)據(jù)更新才有可能將數(shù)據(jù)恢復正確。
來吧，最后一種大家經(jīng)常討論的延時雙刪方案，我們一起盤一盤。
五.延時雙刪
go on
- 1.先刪除緩存
- 2.再寫數(shù)據(jù)庫
- 3.休眠一段時間(根據(jù)具體的業(yè)務時間來定)
- 4.再次刪除緩存
這里加了一個延時的操作，目的是確保 修改數(shù)據(jù)庫 -> 清空緩存前，其他事務的更改緩存操作已經(jīng)執(zhí)行完。
所有的寫操作以數(shù)據(jù)庫為準，只要到達緩存過期時間，則后面的讀請求自然會從數(shù)據(jù)庫中讀取新值然后回填緩存。
但這其中難免還是會大量的查詢到舊緩存數(shù)據(jù)的，因為延時時間是根據(jù)業(yè)務自己定義的，時間太長和太短在高并發(fā)情況下都會有查詢到臟數(shù)據(jù)的情況產生。
這樣最差的情況就是在超時時間內數(shù)據(jù)存在不一致。
結語
到這里大家應該會發(fā)現(xiàn)，除了串行化這種方式以外，其他無論哪種方式大大小小都會有數(shù)據(jù)不一致的現(xiàn)象發(fā)生，有時為了維護數(shù)據(jù)一致性問題還要做很多額外很重的操作，比如加一些日志來做狀態(tài)處理雙寫問題，具體的方案選擇還是要根據(jù)業(yè)務的敏感度來定的。
分享文章：雙寫兜兜轉轉，又回到了串行化的方式
標題網(wǎng)址：http://www.dlmjj.cn/article/dhooede.html
