快取的讀取，比較常規
但是在更新快取方面比較有爭議，具體有以下幾種方式
先更新db，再更新cache
先更新db，再刪除cache
先刪除cache，再更新db
執行緒安全 (資料不一致)
同時請求a和請求b進行更新操作，那麼
a更新了資料庫
b更新了資料庫
b更新了快取
a更新了快取
這就出現請求a更新快取應該比請求b更新快取早才對，但是因為網路等原因，b卻比a更早更新了快取。這就導致了髒資料。
業務場景
資料型別
效能del cache ，只是經歷了一次cache miss
如果你是乙個寫資料庫場景比較多，而讀資料場景比較少的業務需求，採用這種方案就會導致，資料壓根還沒讀到，快取就被頻繁地更新，浪費效能；
如果你寫入資料庫的值，並不是直接寫入快取的，而是要經過一系列複雜的計算再寫入快取。那麼，每次寫入資料庫後，都再次計算寫入快取的值，無疑是浪費效能的。顯然，刪除快取更為適合。
國外提出了乙個快取更新套路，名為《cache-aside pattern》[1]，其中就指出：
失效：應用程式先從cache取資料，沒有得到，則從資料庫中取資料，成功後，放到快取中；這種情況不存在併發問題麼？不是的。假設這會有兩個請求，乙個請求a做查詢操作，乙個請求b做更新操作，那麼會有如下情形產生：命中：應用程式從cache中取資料，取到後返回；
更新：先把資料存到資料庫中，成功後，再讓快取失效。
另外， facebook也在**《scaling memcache at facebook》[2]中提出，他們用的也是先更新資料庫，再刪快取的策略。
快取剛好失效；
請求a查詢資料庫，得乙個舊值；
請求b將新值寫入資料庫；
請求b刪除快取；
請求a將查到的舊值寫入快取。
如果發生上述情況，確實是會發生髒資料。
然而，發生這種情況的概率又有多少？
發生上述情況有乙個先天性條件，就是步驟3的寫資料庫操作比步驟2的讀資料庫操作耗時更短，才有可能使得步驟4先於步驟5。可是，大家想想，資料庫的讀操作的速度遠快於寫操作的（不然做讀寫分離幹嘛，做讀寫分離的意義就是因為讀操作比較快，耗資源少），因此步驟3耗時比步驟2更短，這一情形很難出現。
假設，有人非要抬槓，有強迫症，一定要解決怎麼辦？
如何解決上述併發問題？
給快取設有效時間是一種方案。
非同步延時刪除策略，保證讀請求完成以後，再進行刪除操作。
延時雙刪策略
public void write(string key,object data)先淘汰快取；
再寫資料庫（這兩步和原來一樣）；
休眠1秒，再次淘汰快取。
這麼做，可以將1秒內所造成的快取髒資料，再次刪除。
那麼，這個1秒是怎麼確定的，具體該休眠多久呢？
針對上面的情形，應該自行評估自己的專案的讀資料業務邏輯的耗時。然後寫資料的休眠時間則在讀資料業務邏輯的耗時基礎上，加幾百ms即可。這麼做的目的，就是確保讀請求結束，寫請求可以刪除讀請求造成的快取髒資料。
還有其他造成不一致的原因麼？
有的，如果刪快取失敗了怎麼辦，那不是會有不一致的情況出現麼。比如乙個寫資料請求，然後寫入資料庫了，刪快取失敗了，這會就出現不一致的情況了。這也是快取更新策略二里留下的最後乙個疑問。
如何解決？
提供乙個保障的重試機制即可，這裡給出兩套方案。
方案一：
如下圖所示：
流程如下所示：
更新資料庫資料；
快取因為種種問題刪除失敗；
將需要刪除的key傳送至訊息佇列；
自己消費訊息，獲得需要刪除的key；
繼續重試刪除操作，直到成功。
然而，該方案有乙個缺點，對業務線**造成大量的侵入。於是有了方案二，在方案二中，啟動乙個訂閱程式去訂閱資料庫的binlog，獲得需要操作的資料。在應用程式中，另起一段程式，獲得這個訂閱程式傳來的資訊，進行刪除快取操作。
方案二：
流程如下圖所示：
資料庫會將操作資訊寫入binlog日誌當中；
訂閱程式提取出所需要的資料以及key；
另起一段非業務**，獲得該資訊；
嘗試刪除快取操作，發現刪除失敗；
將這些資訊傳送至訊息佇列；
重新從訊息佇列中獲得該資料，重試操作。
備註說明：資料不一致的原因：上述的訂閱binlog程式在mysql中有現成的中介軟體叫canal，可以完成訂閱binlog日誌的功能。至於oracle中，筆者目前不清楚有沒有現成中介軟體可以使用。另外，重試機制，筆者採用的是訊息佇列的方式。如果對一致性要求不是很高，直接在程式中另起乙個執行緒，每隔一段時間去重試即可，這些大家可以靈活自由發揮，只是提供乙個思路。
請求a進行更新操作，請求b進行查詢操作
1. a進行寫操作，先刪除快取
2. b查詢發現快取不存在
3. b查詢資料庫，得到舊值
4. b將舊值寫入快取
5. a將新值寫入資料庫
上述情況就會導致不一致的情形出現。而且，如果不採用給快取設定過期時間策略，該資料永遠都是髒資料。
那麼，如何解決呢？採用延時雙刪策略。
如果你用了mysql的讀寫分離架構怎麼辦？
在這種情況下，造成資料不一致的原因如下，還是兩個請求，乙個請求a進行更新操作，另乙個請求b進行查詢操作。
兩個請求，乙個請求a進行更新操作，另乙個請求b進行查詢操作。
請求a進行寫操作，刪除快取；
請求a將資料寫入資料庫；
請求b查詢快取發現，快取沒有值；
請求b去從庫查詢，這時，還沒有完成主從同步，因此查詢到的是舊值；
請求b將舊值寫入快取；
資料庫完成主從同步，從庫變為新值。
上述情形，就是資料不一致的原因。還是使用雙刪延時策略。只是，睡眠時間修改為在主從同步的延時時間基礎上，加幾百ms。
採用這種同步淘汰策略，吞吐量降低怎麼辦？
那就將第二次刪除作為非同步的。自己起乙個執行緒，非同步刪除。這樣，寫的請求就不用沉睡一段時間再返回。這麼做，加大吞吐量。
第二次刪除，如果刪除失敗怎麼辦？
這是個非常好的問題，因為第二次刪除失敗，就會出現如下情形。還是有兩個請求，乙個請求a進行更新操作，另乙個請求b進行查詢操作，為了方便，假設是單庫：
請求a進行寫操作，先刪除快取；
請求b查詢發現快取不存在；
請求b去資料庫查詢得到舊值；
請求b將舊值寫入快取；
請求a將新值寫入資料庫；
請求a試圖去刪除請求b寫入對快取值，結果失敗了。
這也就是說，如果第二次刪除快取失敗，會再次出現快取和資料庫不一致的問題。參考策略二
分布式資料庫與快取雙寫一致性方案解疑
在網際網路領域，快取由於其高併發和高效能的特性，已經在專案中被廣泛使用。在讀取快取方面，大家沒什麼疑問，都是按照下圖的流程來進行業務操作。本文將由以下三個部分組成 對每種策略進行缺點分析 針對缺點給出改進方案 先做乙個說明，從理論上來說，給快取設定過期時間，是保證最終一致性的解決方案。這種方案下，我...
分布式資料庫與快取雙寫一致性方案解疑
在網際網路領域，快取由於其高併發和高效能的特性，已經在專案中被廣泛使用。在讀取快取方面，大家沒什麼疑問，都是按照下圖的流程來進行業務操作。對每種策略進行缺點分析 針對缺點給出改進方案 先做乙個說明，從理論上來說，給快取設定過期時間，是保證最終一致性的解決方案。這種方案下，我們可以對存入快取的資料設定...
快取與資料庫一致性
此時系統的讀寫流量很小，這個時候所有的讀寫操作都在主庫 此時，從庫的角色只是作為災備。風險分析 從資料一致性的角度來看沒有任何問題，所有讀寫操作都在主庫 隨著業務的前進和流量的激增，會出現大表和資料庫寫入效能下降的問題。我們可以通過分庫的方式，提公升資料庫單機的qps壓下來 通過分表的方式，降低單錶...