首先，快取由於其高併發和高效能的特性，已經在專案中被廣泛使用。在讀取快取方面，大家沒啥疑問，都是按照下圖的流程來進行業務操作。
但是在更新快取方面，對於更新完資料庫，是更新快取呢，還是刪除快取呢？又或者是先刪除快取，再更新資料庫呢？其實大家存在很大的爭議。目前沒有一篇全面的部落格，對這幾種方案進行解析。
1、講解快取更新策略
2、對每種策略進行缺點分析
3、針對缺點給出改進方案
先做乙個說明，從理論上來說，給快取設定過期時間，是保證最終一致性的解決方案。這種方案下，我們可以對存入快取的資料設定過期時間，所有的寫操作以資料庫為準，對快取操作只是盡最大努力即可。也就是說如果資料庫寫成功，快取更新失敗，那麼只要到達過期時間，則後面的讀請求自然會從資料庫中讀取新值然後回填快取。
因此，接下來討論的思路不依賴於給快取設定過期時間這個方案。
在這裡，我們討論三種更新策略：
先更新資料庫，再更新快取
先刪除快取，再更新資料庫
先更新資料庫，再刪除快取
應該沒人問我，為什麼沒有先更新快取，再更新資料庫這種策略。
1、原因一：
從執行緒安全角度看，同時有請求a和請求b進行更新操作，那麼會出現：
（1）執行緒a更新了資料庫這就出現請求a更新快取應該比請求b更新快取早才對，但是因為網路等原因，b卻比a更早更新了快取。這就導致了髒資料，因此不考慮（2）執行緒b更新了資料庫
（3）執行緒b更新了快取
（4）執行緒a更新了快取
2、原因二：
從業務場景角度看，存在以下兩個問題：
（1）如果是乙個資料庫寫多讀少的業務場景求，採用這種方案就會導致，資料壓根還沒讀到，快取就被頻繁的更新，浪費效能。接下來討論的就是爭議最大的，先刪快取，再更新資料庫。還是先更新資料庫，再刪快取的問題。（2）如果你寫入資料庫的值，並不是直接寫入快取的，而是要經過一系列複雜的計算再寫入快取。那麼，每次寫入資料庫後，都再次計算寫入快取的值，無疑是浪費效能的。顯然，刪除快取更為適合。
1、存在問題：
該方案會導致不一致的原因是：同時有乙個請求a進行更新操作，另乙個請求b進行查詢操作。那麼會出現如下情形：
（1）請求a進行寫操作，刪除快取上述情況就會導致不一致的情形出現。而且，如果不採用給快取設定過期時間策略，該資料永遠都是髒資料。（2）請求b查詢發現快取不存在
（3）請求b去資料庫查詢得到舊值
（4）請求b將舊值寫入快取
（5）請求a將新值寫入資料庫
2、解決方案：
採用延時雙刪策略：偽**如下
public void write(string key,object data){轉化為中文描述就是：redis.delkey(key);
db.updatedata(data);
thread.sleep(1000);
redis.delkey(key);
（1）先淘汰快取這麼做，可以將1秒內所造成的快取髒資料，再次刪除。那麼這個1秒怎麼確定的，具體該休眠多久呢？針對上面的情形，讀者應該自行評估自己的專案的讀資料業務邏輯的耗時。然後寫資料的休眠時間則在讀資料業務邏輯的耗時基礎上，加幾百ms即可。這麼做的目的，就是確保讀請求結束，寫請求可以刪除讀請求造成的快取髒資料。（2）再寫資料庫（這兩步和原來一樣）
（3）休眠1秒，再次淘汰快取
3、如果是mysql的讀寫分離架構怎麼辦？
在這種情況下，造成資料不一致的原因如下，還是兩個請求，乙個請求a進行更新操作，另乙個請求b進行查詢操作。
（1）請求a進行寫操作，刪除快取上述情形，就是資料不一致的原因。還是使用雙刪延時策略。只是，睡眠時間修改為在主從同步的延時時間基礎上，加幾百ms。（2）請求a將資料寫入資料庫了，
（3）請求b查詢快取發現，快取沒有值
（4）請求b去從庫查詢，這時，還沒有完成主從同步，因此查詢到的是舊值
（5）請求b將舊值寫入快取
（6）資料庫完成主從同步，從庫變為新值
4、採用延時雙刪除策略，吞吐量降低怎麼辦？
可以將另起乙個執行緒，非同步執行第二次刪除操作，這樣寫的請求就不用沉睡一段時間後再返回了，從而加大吞吐量。但是如果第二次刪除的時候，刪除失敗怎麼辦呢？
如果第二次刪除失敗，就會出現如下情形。還是有兩個請求，乙個請求a進行更新操作，另乙個請求b進行查詢操作，為了方便，假設是單庫：
（1）請求a進行寫操作，刪除快取也就是說，如果第二次刪除快取失敗，會再次出現快取和資料庫不一致的問題。如何解決呢？具體解決方案，且看對第(3)種更新策略的解析。（2）請求b查詢發現快取不存在
（3）請求b去資料庫查詢得到舊值
（4）請求b將舊值寫入快取
（5）請求a將新值寫入資料庫
（6）請求a試圖去刪除請求b寫入對快取值，結果失敗了。
首先，先說一下。老外提出了乙個快取更新套路，名為《cache-aside pattern》。其中就指出：
另外，知名社交**facebook也在**《scaling memcache at facebook》中提出，他們用的也是先更新資料庫，再刪快取的策略。這種情況不存在併發問題麼？並不是的。假設這會有兩個請求，乙個請求a做查詢操作，乙個請求b做更新操作，那麼會有如下情形產生：
（1）快取剛好失效如果發生上述情況，確實是會發生髒資料。然而，發生這種情況的概率又有多少呢？發生上述情況有乙個先天性條件，就是步驟（3）的寫資料庫操作比步驟（2）的讀資料庫操作耗時更短，才有可能使得步驟（4）先於步驟（5）。但是資料庫的讀操作的速度一般是遠快於寫操作的，因此步驟（3）耗時比步驟（2）更短，這一情形很難出現。（2）請求a查詢資料庫，得乙個舊值
（3）請求b將新值寫入資料庫
（4）請求b刪除快取
（5）請求a將查到的舊值寫入快取
假設，有人非要抬槓，有強迫症，一定要解決怎麼辦？如何解決上述併發問題？首先，給快取設有效時間是一種方案。其次，採用策略（2）裡給出的非同步延時刪除策略，保證讀請求完成以後，再進行刪除操作。
還有其他造成不一致的原因麼？有的，這也是快取更新策略（2）和快取更新策略（3）都存在的乙個問題，如果刪快取失敗了怎麼辦，那不是會有不一致的情況出現麼。比如乙個寫資料請求，然後寫入資料庫了，刪快取失敗了，這會就出現不一致的情況了。這也是快取更新策略（2）裡留下的最後乙個疑問。如何解決？提供乙個保障的重試機制即可，這裡給出兩套方案。
方案一：
流程如下所示：
（1）更新資料庫資料；然而，該方案有乙個缺點，對業務線**造成大量的侵入。於是有了方案二，在方案二中，啟動乙個訂閱程式去訂閱資料庫的binlog，獲得需要操作的資料。在應用程式中，另起一段程式，獲得這個訂閱程式傳來的資訊，進行刪除快取操作。（2）快取因為種種問題刪除失敗
（3）將需要刪除的key傳送至訊息佇列
（4）自己消費訊息，獲得需要刪除的key
（5）繼續重試刪除操作，直到成功
方案二：
流程如下圖所示：
（1）更新資料庫資料備註說明：上述的訂閱binlog程式在mysql中有現成的中介軟體叫canal，可以完成訂閱binlog日誌的功能。另外，重試機制，博主是採用的是訊息佇列的方式。如果對一致性要求不是很高，直接在程式中另起乙個執行緒，每隔一段時間去重試即可，這些大家可以靈活自由發揮，只是提供乙個思路。（2）資料庫會將操作資訊寫入binlog日誌當中
（3）訂閱程式提取出所需要的資料以及key
（4）另起一段非業務**，獲得該資訊
（5）嘗試刪除快取操作，發現刪除失敗
（6）將這些資訊傳送至訊息佇列
（7）重新從訊息佇列中獲得該資料，重試操作。
本文其實是對目前網際網路中已有的一致性方案，進行了乙個總結。對於先刪快取，再更新資料庫的更新策略，還有方案提出維護乙個記憶體佇列的方式，博主看了一下，覺得實現異常複雜，沒有必要，因此沒有必要在文中給出。最後，希望大家有所收穫。
redis快取 資料庫雙寫不一致
讀的時候 先讀快取，快取沒有的話，再讀取資料庫，然後取出資料後放入快取，同時返回響應 更新的時候 先刪除快取，然後再更新資料庫 之所以刪除快取而不是更新，其實是乙個懶載入的思想，避免頻繁更新，降低開銷，同時也可以避免更新快取成功後在更新資料庫時異常帶來的問題 場景1 先修改資料庫，再修改 刪除快取，...
Redis如何保證快取與資料庫的雙寫一致性？
原創 只要用快取，就可能會涉及到快取與資料庫雙儲存雙寫，你只要是雙寫，就一定會有資料一致性的問題 那麼，如何解決一致性問題？一般來說，如果允許快取可以稍微的跟資料庫偶爾有不一致的情況，也就是說如果你的系統不是嚴格要求快取 資料庫必須保持一致性的話，最好不要做這個方案。即 讀請求和寫請求序列化，串到乙...
快取與資料庫雙寫不一致
在大併發下，多執行緒運算元據庫與快取會存在兩者資料不一致的問題。首先重要的是先更新資料庫，在失效快取。執行緒1先更新資料庫，將字段t改為6，然後將快取失效，執行緒結束。執行緒2過來讀資料庫，讀取到了t為6的資訊，在準備插入快取之前發生了執行緒排程，執行緒3過來更新資料庫，並且將快取失效後執行緒3結束...