1. 數據不一致的原因

1.1 雙寫導致數據不一致

由于分布性系統(tǒng)，不能保證每個節(jié)點都可用，所有可能引起 Redis 在極限情況下數據沒有寫入成功，那么此時緩存中的數據和數據庫數據不一致。

數據的更新為什么會成功：因為事務保證數據不管是成功還是失敗，都不會有臟數據。

1.2 高并發(fā)導致數據不一致

數據在修改的過程中必定會存在網絡延時，因為分布式系統(tǒng)節(jié)點相互獨立部署，那么在并發(fā)讀的情況之下，還沒來得及修改完，那么對于讀操作，讀到的數據都是老的數據

如果是某些不嚴謹的情況，無所謂，如果是極致的嚴謹，那么就不能這么做了。比如我們的環(huán)境監(jiān)測，大氣的一些數據會每隔1-2分鐘更新，甚至有的是5分鐘更新，所以如果讀到的是一些老的數據，是沒有關系的，因為最終幾秒或者幾十秒以后會更新，這些數據的來去不會很大，而且我們能容忍一定的誤差，所以也就無所謂了。

2. 查詢數據的邏輯

先請求先到 Redis，如果命中則返回結果。如果 Redis 中沒有數據，則從數據庫查詢，再寫入到緩存中，再返回結果。

3. 更新數據的邏輯

3.1 先刪除緩存，再更新數據庫

3.1.1 方案一

在并發(fā)不高的情況下：先刪除 Redis 中的舊數據。更新數據庫中的數據。再將數據庫中的數據同步到 Redis 中。

3.1.2 方案二

在高并發(fā)的情況下，假設有請求 A 進行更新操作，另一個請求 B 進行查詢操作，那么有可能會出現：

1. A 進行更新操作前，先刪除了緩存
2. B 查詢發(fā)現緩存不存在
3. B 查詢數據庫的舊值
4. B 將舊值寫入到緩存
5. A 執(zhí)行更新，將新值寫入到數據庫
6. 后續(xù)的請求因為發(fā)現緩存中有數據，導致 A 更新的數據一直無法更新到緩存中，這樣便出現了數據庫與緩存不一致的情況。

3.2 先更新數據庫，再刪除緩存

3.2.1 方案一

該方案雖然存在并發(fā)問題，但是出現上述情況的概率是極低的，也有一些企業(yè)在使用這種方案。

在超高并發(fā)下，請求 A 執(zhí)行更新操作，請求 B 進行查詢操作：

1. B 將新值寫入到數據庫
2. A 查詢 Redis 得到舊數據
3. 線程 B 刪除緩存
4. 這樣就會導致 A 修改數據 —> A 刪除 Redis 之間出現臟數據。

3.2.2 方案二

在超高并發(fā)下，請求 A 執(zhí)行更新操作，請求 B 進行查詢操作：

1. 緩存剛好失效
2. B 查詢數據庫，得到一個舊值
3. A 將新值寫入到數據庫
4. 線程 A 刪除緩存
5. B 將舊值寫入到緩存
6. 這樣就會導致后續(xù)的請求之間出現臟數據。

3.3 緩存雙刪方案

它的流程為：

1. 先刪除緩存
2. 再寫數據庫
3. 休眠一段時間，再刪除緩存

回顧一下方案“先刪除緩存，再更新數據庫”可能造成數據庫與緩存不一致的情況。

假設有請求 A 進行更新操作，另一個請求 B 進行查詢操作，如果使用緩存雙刪策略：

1. A 進行更新操作前，先刪除了緩存
2. B 查詢發(fā)現緩存不存在
3. B 查詢數據庫的舊值
4. B 將舊值寫入到緩存
5. A 執(zhí)行更新，將新值寫入到數據庫，執(zhí)行休眠 Thread.sleep(t)
6. A 蘇醒，再次將緩存中的值刪除

緩存雙刪的優(yōu)點是大大降低了數據庫與緩存不一致的概率的發(fā)生，注意這里只是降低，并不是說完全的避免，途中紅框的地方就是緩存臟數據的時間，缺點為一定程度上降低了吞吐量，因為系統(tǒng)進行了休眠

這里為什么要采用休眠，對數據進行延遲緩存，原因是

1. 例如：如果在 A 刪除緩存之后，數據庫修改之間 C 再次請求數據庫，將老的信息存儲進緩存，那么后續(xù)所有的請求打在緩存中，還是獲取到老的數據
2. 在分庫分表的情況下，延遲一定的時間，也保證了，修改后的數據全部同步到所有的數據庫中。

4. 擴展：其它的解決雙寫一直問題

通過監(jiān)聽數據庫日志，來修改 Redis 的數據，使數據的修改達到準實時的級別，例如：canal。但是這種情況下會有一些時間的延遲，也會短暫的產生臟數據。這種情況適用于寫多讀少的場景

完全使用緩存作為數據庫，后面在定時任務修改數據庫數據。這種情況下，沒要求對 Redis 的三高要求非常高，可以采用云廠商的 Redis 服務。

讀取的時候只提供 Redis，也就是說，當更新操作一開始從 Redis 中刪除數據了，用戶去讀 Redis，如果沒有是不會從數據庫中讀的，因為只提供 Redis 的讀取，寫入的時候只在數據新增以及更新后才會放入到 Redis，那么如此一來，并發(fā)讀的時候就不會從數據庫讀取老的數據并且放入 Redis 中了。沒有讀到也沒關系，做一些空數據的處理，可能會有個幾百毫秒或者 1-2s 的延遲，但是可以忍受。但是要注意做好緩存穿透的校驗處理。

5. 緩存數據的思考

我們能放入緩存的數據本就不應該是實時性、一致性要求超高的，所以緩存數據的時候加上過期時間，保證每天拿到當前最新數據即可。

我們不應該過度設計，增加系統(tǒng)的復雜性，遇到實時性、一致性要求高的數據，就應該查數據庫，即使慢點。

超高并發(fā)場景的一致性，都是最終一致性，也就是弱一致性，所以要考慮每一個環(huán)節(jié)可能失敗的情況，補償 job 也是常有的。

總結

以上為個人經驗，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論