首先，快取由於其高併發和高效能的特性，已經在專案中被廣泛使用。在讀取快取方面，大家沒啥疑問，都是按照下圖的流程來進行業務操作
但是在更新快取方面，對於更新完資料庫，是更新快取呢，還是刪除快取。又或者是先刪除快取，再更新資料庫，其實大家存在很大的爭議
本文由以下三個部分組成 1、講解快取更新策略 2、對每種策略進行缺點分析 3、針對缺點給出改進方案
回到目錄
先做乙個說明，從理論上來說，給快取設定過期時間，是保證最終一致性的解決方案。這種方案下，我們可以對存入快取的資料設定過期時間，所有的寫操作以資料庫為準，對快取操作只是盡最大努力即可。也就是說如果資料庫寫成功，快取更新失敗，那麼只要到達過期時間，則後面的讀請求自然會從資料庫中讀取新值然後回填快取。因此，接下來討論的思路不依賴於給快取設定過期時間這個方案。 在這裡，我們討論三種更新策略：
回到目錄
這套方案，大家是普遍反對的。為什麼呢？有如下兩點原因。
原因一（執行緒安全角度）同時有請求a和請求b進行更新操作，那麼會出現
這就出現請求a更新快取應該比請求b更新快取早才對，但是因為網路等原因，b卻比a更早更新了快取。這就導致了髒資料，因此不考慮。
原因二（業務場景角度）有如下兩點：
接下來討論的就是爭議最大的，先刪快取，再更新資料庫。還是先更新資料庫，再刪快取的問題。
回到目錄
該方案會導致不一致的原因是。同時有乙個請求a進行更新操作，另乙個請求b進行查詢操作。那麼會出現如下情形:
那麼，如何解決呢？採用延時雙刪策略偽**如下
public void write(string key,object data)
那麼，這個1秒怎麼確定的，具體該休眠多久呢？
針對上面的情形，讀者應該自行評估自己的專案的讀資料業務邏輯的耗時。然後寫資料的休眠時間則在讀資料業務邏輯的耗時基礎上，加幾百ms即可。這麼做的目的，就是確保讀請求結束，寫請求可以刪除讀請求造成的快取髒資料。
如果你用了mysql的讀寫分離架構怎麼辦？
ok，在這種情況下，造成資料不一致的原因如下，還是兩個請求，乙個請求a進行更新操作，另乙個請求b進行查詢操作。
採用這種同步淘汰策略，吞吐量降低怎麼辦？
ok，那就將第二次刪除作為非同步的。自己起乙個執行緒，非同步刪除。這樣，寫的請求就不用沉睡一段時間後了，再返回。這麼做，加大吞吐量。
第二次刪除,如果刪除失敗怎麼辦？
這是個非常好的問題，因為第二次刪除失敗，就會出現如下情形。還是有兩個請求，乙個請求a進行更新操作，另乙個請求b進行查詢操作，為了方便，假設是單庫：
回到目錄
首先，先說一下。老外提出了乙個快取更新套路，名為《cache-aside pattern》。其中就指出
失效：應用程式先從cache取資料，沒有得到，則從資料庫中取資料，成功後，放到快取中。
命中：應用程式從cache中取資料，取到後返回。
更新：先把資料存到資料庫中，成功後，再讓快取失效。
另外，知名社交**facebook也在**《scaling memcache at facebook》中提出，他們用的也是先更新資料庫，再刪快取的策略。
這種情況不存在併發問題麼？
不是的。假設這會有兩個請求，乙個請求a做查詢操作，乙個請求b做更新操作，那麼會有如下情形產生
（1）快取剛好失效
（2）請求a查詢資料庫，得乙個舊值
（3）請求b將新值寫入資料庫
（4）請求b刪除快取
（5）請求a將查到的舊值寫入快取 ok，如果發生上述情況，確實是會發生髒資料。
然而，發生這種情況的概率又有多少呢？
發生上述情況有乙個先天性條件，就是步驟（3）的寫資料庫操作比步驟（2）的讀資料庫操作耗時更短，才有可能使得步驟（4）先於步驟（5）。
可是，大家想想，資料庫的讀操作的速度遠快於寫操作的（不然做讀寫分離幹嘛，做讀寫分離的意義就是因為讀操作比較快，耗資源少），因此步驟（3）耗時比步驟（2）更短，這一情形很難出現。 假設，有人非要抬槓，有強迫症，一定要解決怎麼辦？
如何解決上述併發問題？
首先，給快取設有效時間是一種方案。其次，採用策略（2）裡給出的非同步延時刪除策略，保證讀請求完成以後，再進行刪除操作。
還有其他造成不一致的原因麼？
有的，這也是快取更新策略（2）和快取更新策略（3）都存在的乙個問題，如果刪快取失敗了怎麼辦，那不是會有不一致的情況出現麼。比如乙個寫資料請求，然後寫入資料庫了，刪快取失敗了，這會就出現不一致的情況了。這也是快取更新策略（2）裡留下的最後乙個疑問。
如何解決？提供乙個保障的重試機制即可，這裡給出兩套方案。
方案一： 如下圖所示
流程如下所示
方案二：
流程如下圖所示：
備註說明：上述的訂閱binlog程式在mysql中有現成的中介軟體叫canal，可以完成訂閱binlog日誌的功能。至於oracle中，博主目前不知道有沒有現成中介軟體可以使用。另外，重試機制，博主是採用的是訊息佇列的方式。如果對一致性要求不是很高，直接在程式中另起乙個執行緒，每隔一段時間去重試即可，這些大家可以靈活自由發揮，只是提供乙個思路。
強一致性 弱一致性 最終一致性
這種方式在es等分布式系統中也有體現，可以設定主shard提交即返回成功，或者需要replica shard提交成功再返回。提到分布式架構就一定繞不開 一致性 問題，而 一致性 其實又包含了資料一致性和事務一致性兩種情況，本文主要討論資料一致性 事務一致性指acid 複製是導致出現資料一致性問題的唯...
Redis快取一致性
用過redis的應該都清楚，redis作為記憶體快取，只是他查詢快的一大優勢，關係型資料庫只能用作儲存重要資料，或者備份快取的資料，這個時候，不可避免，我們會遇到快取中的資料與關係型資料庫中的資料不一致的情況。出現不一致的現象很常見，如果你是單個使用者肯定不會出現這種情況，如果在多執行緒併發的情況下...
Redis一致性方案
儘管到目前為止，我在專案中很少遇到快取不一致問題，僅有一次是因為 原因。就是那次讓我考慮快取不一致的解決方案，網上有很方案，例如加鎖，訊息佇列，或延遲刪除,還有監控binlog日誌，以及用lua實現樂觀鎖，但我以為這些方案都不是太理想，要麼增加了系統的複雜度，要麼不能做到實時一致性。一天我漫步在乙個...