前言
快取一致性是指業務在引入分布式快取系統後，業務對資料的更新除了要更新儲存以外還需要同時更新快取，對兩個系統進行資料更新就要先解決分布式系統中的隔離性和原子性難題。目前大多數業務在引入分布式快取後都是通過犧牲小概率的一致性來保障業務效能，因為要在業務層嚴格保障資料的一致性，代價非常高，業務引入分布式快取主要是為了解決效能問題，所以在效能和一致性面前，通常選擇犧牲小概率的一致性來保障業務效能。為了減輕資料庫壓力，高效讀，引入快取。方便的同時也帶來資料庫和快取之間資料的一致性問題。
是先操作快取還是先運算元據庫。是通過刪除快取的方式然後讀取時更新還是更新快取的方式。如何保證原子性，一致性，隔離性。
這裡我們面臨的問題本質上是乙個資料庫的分布式事務的問題，需要處理資料可靠性的挑戰，併發更新帶來的隔離性挑戰，和資料更新原子性的挑戰。
資料可靠性
如果要保證資料的可靠性(保證資料庫內資料一定正確)，在業務邏輯成功之前，必須保障有乙份資料落地，我們有以下兩個選擇：
操作隔離性
一條資料的更新涉及到儲存和快取兩套系統，如果多個執行緒同時操作一條資料，並且沒有方案保證多個操作之間的有序執行，就可能會發生更新順序錯亂導致資料不一致的問題。
更新原子性
引入快取後，我們需要保證快取和儲存要麼同時更新成功，要麼同時更新失敗，否則部分更新成功就會導致快取和儲存資料不一致的問題。
方案如下進行比較：
1.2.1 更新快取 更新資料庫
1.2.2 刪除快取 更新資料庫
前面兩種都是先操作快取再運算元據庫的。不推薦先操作快取，因為先操作快取如果快取更新1.2.3 更新資料庫 更新快取
1.2.4 更新資料庫 刪除快取
更新資料庫 然後刪除快取 等待下次讀的時候miss進行更新快取，也是推薦方案。
為何通過刪除快取的方式而不是更新快取的方式？積極更新策略，快取資料實時性更高，但是在快取側帶來了更多的更新操作，這會提高更新衝突導致髒資料概率。
比如：總結
references
資料庫和快取一致性
今天程式過程中突然想到了乙個問題，怎麼保證redis快取和mysql資料庫中的資料相同 一致性 即在更新資料時怎樣保證資料庫和redis快取始終相同。從理論上講，給快取設定過期時間是保證最終一致性的解決方案。這種方案下，所有寫操作以資料庫為準，對快取做最大努力即可。下面介紹的是不依賴於給快取設定過期...
快取與資料庫一致性問題
業務場景 抓拍到的人臉需要推送到第三方系統，但不是所有的網點都需要推送資訊。也就是要做到不同的網點可以根據配置來決定是否推送，前端頁面需要有推送配置功能，手動配置後，把配置的推送資訊儲存到資料庫。抓拍到人臉 後，讀取配置的推送資訊，再判斷是否需要推送。由於網點多抓拍的人臉資料量較大，推送資訊配置後不...
資料庫和快取一致性方案
redis儲存快取，mysql儲存資料。快取進行有效期設定。但是更新mysql，不會更新快取。這樣導致快取和資料庫的一致性問題比較長 mysql更新後，進行更新redis快取。查詢的時候先查詢redis快取，如果沒有快取，只查詢資料庫進行更新快取 快取和資料庫不一致性的時間短 cache aside...