今天，我們來分析一下，快取與資料庫被使用次數最多的一種使用方法
第一步先刪除快取，刪除之後再更新db，之後再非同步將資料刷回快取
第一步先讀快取，如果快取沒讀到，則去讀db，之後再非同步將資料刷回快取
what should i say ?為什麼說這也算優點呢？試想一下
如果把寫流程改一下：先更新快取，再更新db。 如果我們更新快取成功，而更新資料庫失敗，就會導致快取中的資料是錯誤的，而我們大部分的業務一般能忍受資料延遲，但是資料錯誤這是無法接受的，所以先淘汰快取是比較合理的。 如果把寫流程改一下：不刪快取，先更新db，再更新快取。 如果我們更新db成功，而更新快取失敗，則會導致快取中就會一直是舊的資料（也算是一種錯誤資料），所以先淘汰快取是比較合理的。
在很多業務場景中，快取只是輔助，所以在很多業務中，快取的讀寫失敗不會影響主流程，啥意思呢？就是說很多情況下，即使操作快取失敗（比如步驟1.1中的』del快取失敗』），程式還是會繼續往下走（繼續步驟1.2 更新資料庫)，所以這個時候非同步重新整理就能在一定程度上，對1.1的失敗進行錯誤資料的修補
說完優點，我們再來看看缺點
在分布式領域，「everything will fails」，任何可能出現問題的地方都會出現問題我們來分析一下寫流程，第一步，』del快取失敗』怎麼辦？流程是否還繼續走？如果繼續執行，那麼從』更新完db』到非同步』重新整理快取』快取期間，資料處於滯後狀態。而且如果快取處於不可寫狀態，那麼非同步重新整理那步也可能會失敗，那快取就會長期處於舊資料，問題就比較嚴重了
寫寫併發：試想一下，同時有多個伺服器的多個執行緒進行』步驟1.2更新db』，更新db完成之後，它們就要進行非同步刷快取，我們都知道多伺服器的非同步操作，是無法保證順序的，所以後面的重新整理操作存在相互覆蓋的併發問題，也就是說，存在先更新的db操作，反而很晚才去重新整理快取，那這個時候，資料也是錯的
讀寫併發：再試想一下，伺服器a在進行』讀操作』，，在a伺服器剛完成2.2時，伺服器b在進行』寫操作』，假設b伺服器1.3完成之後，伺服器a的1.3才被執行，這個時候就相當於更新前的老資料寫入快取，最終資料還是錯的
今天介紹的這個方案呢，適合大部分的業務場景，很多人都在用，香還是很香的，實現起來也簡單。適合使用的場景：併發量、一致性要求都不是很高的情況。
我覺得這個方案有乙個比較大的缺陷在於重新整理快取有可能會失敗，而失敗之後快取中資料就一直會處於錯誤狀態，所以它並不能保證資料的最終一致性，那怎麼解決這個問題呢，篇幅有限，我們後續文章再繼續分享
01：快取與資料庫一致性系列-序言
02：快取與資料庫一致性系列-01
03：快取與資料庫一致性系列-02
04：快取與資料庫一致性系列-03
05：快取與資料庫一致性系列-04
快取與資料庫一致性
此時系統的讀寫流量很小，這個時候所有的讀寫操作都在主庫 此時，從庫的角色只是作為災備。風險分析 從資料一致性的角度來看沒有任何問題，所有讀寫操作都在主庫 隨著業務的前進和流量的激增，會出現大表和資料庫寫入效能下降的問題。我們可以通過分庫的方式，提公升資料庫單機的qps壓下來 通過分表的方式，降低單錶...
快取與資料庫一致性保證
本文主要討論這麼幾個問題 1 啥時候資料庫和快取中的資料會不一致 2 不一致優化思路 3 如何保證資料庫與快取的一致性 當資料發生變化時，先淘汰快取，再修改資料庫 這個點是大家討論的最多的。上篇文章得出這個結論的依據是，由於操作快取與運算元據庫不是原子的，非常有可能出現執行失敗。假設先寫資料庫，再淘...
快取與資料庫一致性系列
一般來說，對於乙個新的業務，一般會經歷這幾個階段 讀寫流量都比較小，這個時候所有的讀寫操作都在主庫就ok了 這個時候，從庫可能只是用來災備 風險分析 從資料一致性角度來說沒有風險，全走主庫美滋滋 階段2.1 單庫扛不住了，這個時候就會考慮到分庫分表了，通過增加資料庫的方式，把單庫的qps降下來 風險...