redis快取由於其高併發和高效能的特性，已經在專案中被廣泛使用，在讀取快取方面，目前大家都是按下圖的方案進行業務操作的
這時候問題就來了，在更新快取的時候，對於更新完資料庫，是更新快取呢？還是刪除快取呢，又或者是先刪除快取，再更新資料庫，其實是可以討論一番的。下面將從三個方面討論，分別是快取更新策略，每種策略的優缺點分析，針對優缺點的改進方案
從理論上來講，給快取設定過期時間，是保證最終一致性的解決方案，在這種方案下，可以對存入快取的資料設定過期時間，索引的寫操作以資料庫為準，對快取操作只是盡最大的努力。也就是說如果資料庫寫成功，快取更新失敗，那麼只要達到過期時間，則後面的讀請求自然會從資料庫中讀取新的值然後回填快取，因此，下面的討論思路不考慮給快取設定過期時間這個方案。只考慮以下三種更新策略：
1、先更新資料庫，再更新快取
2、先刪除快取，再更新資料庫
3、先更新資料庫，再刪除快取這套方案大多數人是反對的，原因是什麼呢？大概有以下兩點：
原因一：從執行緒安全的角度，同時有請求a和b進行更新操作，會出現什麼？
1.1 執行緒a更新了資料庫這本該請求a先更新快取，b後更新才對，但是因為網路等原因，b卻比a更早更新了快取，這就導致出現了髒資料，故不考慮1.2 執行緒b更新了資料庫
1.3 執行緒b更新了快取
1.4 執行緒a更新了快取
原因二：從業務角度，思考以下兩點
2.1 如果你是乙個寫資料場景比較多，而讀資料場景比較少的業務需求，採用這種方案就會導致，資料還沒讀到，快取就被頻繁的更新，浪費效能
2.2 如果你寫入資料庫的值，並不是直接寫入快取的，而是要經過一系列複雜的計算再寫入快取的，那麼，每次寫入資料庫，都再次計算寫入快取的值，無疑是浪費效能的，顯然，刪除快取更為合適。
該方案會導致不一致的原因是：同時有乙個請求a進行更新操作，另乙個請求b進行查詢操作，那麼會出現以下幾種情景：
1、請求a進行寫操作，刪除快取那，如何解決呢？2、請求b進行讀操作，發現快取不存在
3、請求b去資料庫查詢得到舊值
4、請求b將舊值寫入快取
5、請求a將新值寫入資料庫，這樣的情況就會導致不一致的情形出現，而且，如果不採用給快取設定過期時間，該資料永遠都是髒資料
採用延時雙刪策略
1、先淘汰快取那麼，這個1秒怎麼確定的，具體該休眠多久呢？針對上面的情形，應該自行評估自己的專案的讀資料業務邏輯的耗時。然後寫資料的休眠時間則在讀資料業務邏輯的耗時基礎上，加幾百ms即可。這麼做的目的，就是確保讀請求結束，寫請求可以刪除讀請求造成的快取髒資料。2、再寫資料庫
3、休眠1秒，再次淘汰快取，可以將1秒內所造成的快取髒資料再次刪除
如果你用了mysql的讀寫分離架構怎麼辦？
還是兩個請求，乙個請求a進行更新操作，另乙個請求b進行查詢操作。
（1）請求a進行寫操作，刪除快取採用這種同步淘汰策略，吞吐量會降低，那又該怎麼辦呢？（2）請求a將資料寫入資料庫了，
（3）請求b查詢快取發現，快取沒有值
（4）請求b去從庫查詢，這時，還沒有完成主從同步，因此查詢到的是舊值
（5）請求b將舊值寫入快取
（6）資料庫完成主從同步，從庫變為新值 上述情形，就是資料不一致的原因。還是使用雙刪延時策略。只是，睡眠時間修改為在主從同步的延時時間基礎上，加幾百ms。
那可以將第二次刪除作為非同步，自己起乙個執行緒，非同步刪除。這樣，寫的請求就不用沉睡一段時間後再返回，這樣做就可以加大吞吐量
第二次刪除,如果刪除失敗怎麼辦？
這會出現下面的請求，乙個a請求進行更新操作，另乙個請求b進行查詢操作，為了方便，假設是單庫：
1）請求a進行寫操作，刪除快取首先，先說一下。老外提出了乙個快取更新套路，名為《cache-aside pattern》。其中就指出（2）請求b查詢發現快取不存在
（3）請求b去資料庫查詢得到舊值
（4）請求b將舊值寫入快取
（5）請求a將新值寫入資料庫
（6）請求a試圖去刪除請求b寫入對快取值，結果失敗了。 ok,這也就是說。如果第二次刪除快取失敗，會再次出現快取和資料庫不一致的問題。 如何解決呢？ 具體解決方案，且看第(3)種更新策略的解析。
1、失效：應用程式先從cache取資料，沒有得到，則從資料庫中取資料，成功後，放到快取中。
2、命中：應用程式從cache中取資料，取到後返回。
3、更新：先把資料存到資料庫中，成功後，再讓快取失效。
另外，知名社交**facebook也在**《scaling memcache at facebook》中提出，他們用的也是先更新資料庫，再刪快取的策略。
這種情況不存在併發問題麼？
不是的。假設這會有兩個請求，乙個請求a做查詢操作，乙個請求b做更新操作，那麼會有如下情形產生
(1)快取剛好失效確實，如果發生上述情況，就一定會發生髒資料(2)請求a查詢資料庫，得到乙個舊值
(3)請求b將新值寫入資料庫
(4)請求b刪除快取
(5)請求a將查到的舊值寫入快取。
但是，實際發生這種情況的概率又有多少呢？
發生上述情況有乙個先天性條件，就是步驟（3）的寫操作比步驟（2）的讀操作耗時更短，才有可能使得步驟（4）先於步驟（5）。
可是，我們想想，資料庫的讀操作的速度遠快於寫操作的(讀寫分離的意義不就是因為讀操作比寫操作塊，消耗資源少)，因此步驟（3）耗時比步驟（2）還短，這一情景出現的概率真的很小，假設，非要解決這個隱患，一定要解決，怎麼辦？
首先，給快取設定有效時間是一種方案，其次，採用上面的非同步延時刪除策略，保證讀請求完成後，再進行刪除操作。
思考還有其他造成不一致的原因嗎？
有的，這也是上述兩種快取更新策略都存在的乙個問題，如果刪除快取失敗怎麼辦，那不是會有不一致的情況出現麼，比如乙個寫資料請求，然後寫入資料庫，刪快取失敗了，這會不會就出現不一致的情況了，這也是快取更新策略2裡留下的最後乙個疑問
如何解決？？
提供乙個保障的重試機制即可，下面有兩套方案
方案一：
流程如下所示：
更新資料路資料
快取因為種種問題刪除失敗
將需要刪除的key傳送至訊息佇列
自己消費訊息，獲得需要刪除的key
繼續充實刪除操作，直到成功，然而，該方案有乙個缺點對業務線**造成大量的侵入，於是有了方案二，在方案二中，啟動乙個訂閱程式去訂閱資料庫的binlog，獲得需要操作的資料，在應用程式中，另起一段程式，獲得這個訂閱程式傳來的資訊，進行刪除快取操作
方案二：
流程如下所示：
更新資料庫資料
資料庫會將操作資訊寫入binlog日誌中
訂閱程式提取所需要的資料以及key
另起一段非業務**，獲得該資訊
嘗試刪除快取操作，發現刪除失敗
將這些資訊傳送至訊息佇列
重新從訊息佇列中獲得該資料，重新操作
注意：上述的訂閱binlog程式在mysql中有現成的中介軟體canal，可以完成訂閱binlog日誌的功能。另外，重試機制，主要採用的是訊息佇列的方式。如果對一致性要求不是很高，直接在程式中另起乙個執行緒，每隔一段時間去重試即可。
redis 雙寫一致性
首先，快取由於其高併發和高效能的特性，已經在專案中被廣泛使用。在讀取快取方面，大家沒啥疑問，都是按照下圖的流程來進行業務操作。但是在更新快取方面，對於更新完資料庫，是更新快取呢，還是刪除快取。又或者是先刪除快取，再更新資料庫，其實大家存在很大的爭議。目前沒有一篇全面的部落格，對這幾種方案進行解析。於...
Redis 雙寫一致性
首先，快取由於其高併發和高效能的特性，已經在專案中被廣泛使用。在讀取快取方面，大家沒啥疑問，都是按照下圖的流程來進行業務操作。但是在更新快取方面，對於更新完資料庫，是更新快取呢，還是刪除快取。又或者是先刪除快取，再更新資料庫，其實大家存在很大的爭議。目前沒有一篇全面的部落格，對這幾種方案進行解析。於...
Redis與Mysql雙寫一致性方案解析
首先，快取由於其高併發和高效能的特性，已經在專案中被廣泛使用。在讀取快取方面，大家沒啥疑問，都是按照下圖的流程來進行業務操作。本文由以下三個部分組成 1 講解快取更新策略 2 對每種策略進行缺點分析 3 針對缺點給出改進方案 先做乙個說明，從理論上來說，給快取設定過期時間，是保證最終一致性的解決方案...