用過redis的應該都清楚，redis作為記憶體快取，只是他查詢快的一大優勢，關係型資料庫只能用作儲存重要資料，或者備份快取的資料，這個時候，不可避免，我們會遇到快取中的資料與關係型資料庫中的資料不一致的情況。
出現不一致的現象很常見，如果你是單個使用者肯定不會出現這種情況，如果在多執行緒併發的情況下，這種不一致的情況，就會變得異常普遍，舉個例子，a請求刪除快取成功，開始修改資料庫，這時候b請求讀取快取，發現快取中沒有資料，於是讀取db，這是a請求還沒有修改完db，這時候b請求開始回寫快取，a將新值寫入db，這就造成快取中的資料是舊資料，db中的資料是修改後的資料。
2。如果做了讀寫分離，也有可能會出現快取不一致，是因為主從資料庫不同步導致的。
我採用的方法是延時雙刪，就是a刪除快取之後，過1s鐘然後再次刪除快取，為什麼是1s呢？ 其實不一定準確的就是1s，這個是要看業務環境的，如果併發的時間很短就把時間調短一點，就是保證第二個執行緒操作的時間多一點點就行。
redis 快取更新一致性
當執行寫操作後，需要保證從快取讀取到的資料與資料庫中持久化的資料是一致的，因此需要對快取進行更新。因為涉及到資料庫和快取兩步操作，難以保證更新的原子性。在設計更新策略時，我們需要考慮多個方面的問題 更新快取有兩種方式 更新快取和更新資料庫有兩種順序 兩兩組合共有四種更新策略，現在我們逐一進行分析。併...
Redis 快取更新一致性
當執行寫操作後，需要保證從快取讀取到的資料與資料庫中持久化的資料是一致的，因此需要對快取進行更新。因為涉及到資料庫和快取兩步操作，難以保證更新的原子性。在設計更新策略時，我們需要考慮多個方面的問題 更新快取有兩種方式 更新快取和更新資料庫有兩種順序 兩兩組合共有四種更新策略，現在我們逐一進行分析。併...
快取一致性
一般應用而言，追求的都是快取的最終一致性。一般的快取系統，都是按照key去快取查詢，如果不存在對應的value，就應該去後端系統查詢 比如db 如果key對應的value是一定不存在的，並且對該key併發請求量很大，就會對後端系統造成很大的壓力。這就叫做快取穿透。引起這個問題的主要原因還是高併發的時...