在大併發下，多執行緒運算元據庫與快取會存在兩者資料不一致的問題。
首先重要的是先更新資料庫，在失效快取。
執行緒1先更新資料庫，將字段t改為6，然後將快取失效，執行緒結束。執行緒2過來讀資料庫，讀取到了t為6的資訊，在準備插入快取之前發生了執行緒排程，執行緒3過來更新資料庫，並且將快取失效後執行緒3結束，然後執行緒2繼續插入資料，此時快取中的資料是6，而資料庫的資料是7，出現了不一致的情況。時序圖如下圖所示：
對於併發機率很小的資料（個人維度的購物車資料等），這種幾乎不用考慮這種問題。
對於業務能夠容忍短時間快取不一致的（商品名稱、商品分類選單），也不需要考慮
延時雙更（無法徹底解決）
讀寫鎖（redis等方式實現，讀寫按順序，讀讀約等於無鎖）
通過類似於canal中介軟體讀binlog，但是增加系統複雜度。
整個過程序列化，會極大的降低效能。
要根據不同場景使用不同的方式，一般加快取的場景都是讀多寫少的場景，如果寫多讀少，又不能容忍不一致，則不建議使用快取。
redis快取 資料庫雙寫不一致
讀的時候 先讀快取，快取沒有的話，再讀取資料庫，然後取出資料後放入快取，同時返回響應 更新的時候 先刪除快取，然後再更新資料庫 之所以刪除快取而不是更新，其實是乙個懶載入的思想，避免頻繁更新，降低開銷，同時也可以避免更新快取成功後在更新資料庫時異常帶來的問題 場景1 先修改資料庫，再修改 刪除快取，...
高併發快取 資料庫雙寫不一致
情景一 先修改資料庫，再刪除快取，如果刪除快取失敗了，那麼會導致資料庫中是新資料，快取中是舊資料，資料出現不一致 解決方案 先刪除快取，再修改資料庫，如果刪除快取成功了，如果修改資料庫失敗了，那麼資料庫中是舊資料，快取中是空的，那麼資料不會不一致 因為讀的時候快取沒有，則讀資料庫中舊資料，然後更新到...
redis快取 資料庫雙寫不一致問題分析與解決方案
在高併發場景下，肯定會發生這個問題，這裡簡單談談解決思路 1.常規簡單的解決方案 先刪除快取，在更新資料庫,如果刪除快取成功，修改資料庫失敗了，那麼資料庫中依然是舊資料，如果去讀取資料的時候，發現快取沒有，則去讀資料庫，資料庫會把舊資料載入到快取裡，這樣快取和資料庫則保持了一致。2.如果在高併發的情...