首先，先說一下。老外提出了乙個快取更新套路，名為《cache-aside pattern》。其中就指出
不是的。假設這會有兩個請求，乙個請求a做查詢操作，乙個請求b做更新操作，那麼會有如下情形產生
快取剛好失效
請求a查詢資料庫，得乙個舊值
請求b將新值寫入資料庫
請求b刪除快取
請求a將查到的舊值寫入快取
ok，如果發生上述情況，確實是會發生髒資料。
然而，發生這種情況的概率又有多少呢？
發生上述情況有乙個先天性條件，就是步驟（3）的寫資料庫操作比步驟（2）的讀資料庫操作耗時更短，才有可能使得步驟（4）先於步驟（5）。可是，大家想想，資料庫的讀操作的速度遠快於寫操作的（不然做讀寫分離幹嘛，做讀寫分離的意義就是因為讀操作比較快，耗資源少），因此步驟（3）耗時比步驟（2）更短，這一情形很難出現。
假設，有人非要抬槓，有強迫症，一定要解決怎麼辦？
首先，給快取設有效時間是一種方案。其次，採用非同步延時刪除策略，保證讀請求完成以後，再進行刪除操作。
有的，如果刪快取失敗了怎麼辦，那不是會有不一致的情況出現麼。比如乙個寫資料請求，然後寫入資料庫了，刪快取失敗了，這會就出現不一致的情況了。
提供乙個保障的重試機制即可
流程如上圖所示：
更新資料庫資料
資料庫會將操作資訊寫入binlog日誌當中
訂閱程式提取出所需要的資料以及key
另起一段非業務**，獲得該資訊
嘗試刪除快取操作，發現刪除失敗
將這些資訊傳送至訊息佇列
重新從訊息佇列中獲得該資料，重試操作。
備註說明：上述的訂閱binlog程式在mysql中有現成的中介軟體叫canal，可以完成訂閱binlog日誌的功能。另外，重試機制，博主採用的是訊息佇列的方式。如果對一致性要求不是很高，直接在程式中另起乙個執行緒，每隔一段時間去重試即可，這些大家可以靈活自由發揮，只是提供乙個思路。
分布式一致性方案
首先，先說一下。老外提出了乙個快取更新套路，名為 cache aside pattern 其中就指出 失效 應用程式先從cache取資料，沒有得到，則從資料庫中取資料，成功後，放到快取中。命中 應用程式從cache中取資料，取到後返回。更新 先把資料存到資料庫中，成功後，再讓快取失效。不是的。假設這...
分布式一致性
分布式一致性是指在分布式環境中對某個副本資料進行更新操作時，必須確保其他副本也會更新，避免不同副本資料不一致。分布式系統乙個重要的問題時解決資料複製,一是為了增加系統的可用性防止單點故障，二是提高系統可用性，通過負載聚恆，使分布在不同位置的資料副本能夠提供服務。理想狀態下，當然希望分布式系統能夠實現...
分布式一致性
分布式系統的乙個重要問題是資料的複製。對資料的複製一般有兩個原因 資料複製的主要難題是保持各個副本的一致性。即在更新乙個副本時，必須確保同時更新其他的副本，否則資料的各個副本將不再相同。一致性模型實質上是程序和資料儲存之間的乙個約定。正常情況下，乙個資料項上執行讀操作時，它期待該操作返回的是該資料在...