參考文章
快取適用於讀多寫少的場景，並且能極大地提公升效能和效率；但是讓快取的資料與資料庫保持一致是乙個難題
當資料更新時，先更新快取，如果快取更新成功，再更新資料庫
當資料更新時，先刪除快取，如果快取刪除成功，再更新資料庫
不考慮策略1，以下將深入**策略2
在高併發的情況下，假設請求1(更新操作)先刪除快取，再更新資料庫，如果請求2(讀操作)在快取刪除與資料庫更新之間進行了讀取資料，就會讀入舊資料到快取，待資料庫更新後，此時舊資料快取與資料庫發生不一致的現象
該問題的核心是，請求1的操作不能被其他請求打斷，並且請求1與其他請求之間要保持有序(序列執行)。遇到這種情況，可以採用佇列的方式去解決(為了保證序列執行，工作執行緒只能有1個)，當出現更新請求時，直接將其丟進佇列，等待非同步執行；當出現讀請求時，先讀快取，成功則返回，如果快取不存在，再去判斷佇列頭部是否是同一條記錄的更新請求，如果是，為了不打斷其操作，將讀請求也丟進佇列，然後同步等待快取更新完成；如果不是，說明該更新請求早已完成，直接讀資料庫並快取即可，不要入佇列。
佇列可以建立多個，運用hash法將不同記錄的請求雜湊到不同的佇列，可以負載均衡，並行執行，也可以避免堵塞
在分布式場景下，佇列最好共享
進入佇列的讀請求可以採用超時等待，一旦超時，直接讀資料庫並返回，避免長時間的不響應
最後強調：只有讀多寫少的場景才用快取！！！讀多寫少、讀多寫少，其他情況不要用
快取與資料庫一致性
此時系統的讀寫流量很小，這個時候所有的讀寫操作都在主庫 此時，從庫的角色只是作為災備。風險分析 從資料一致性的角度來看沒有任何問題，所有讀寫操作都在主庫 隨著業務的前進和流量的激增，會出現大表和資料庫寫入效能下降的問題。我們可以通過分庫的方式，提公升資料庫單機的qps壓下來 通過分表的方式，降低單錶...
快取與資料庫的一致性
快取就是資料交換的緩衝區，針對服務物件的不同 本質就是不同的硬體 都可以構建快取。目的是，把讀寫速度慢的介質的資料儲存在讀寫速度快的介質中，從而提高讀寫速度，減少時間消耗。例如 磁碟快取 磁碟快取其實就把常用的磁碟資料儲存在記憶體中，記憶體讀寫速度也是遠高於磁碟的。讀資料時，從記憶體讀取。寫資料時，...
快取與資料庫一致性保證
本文主要討論這麼幾個問題 1 啥時候資料庫和快取中的資料會不一致 2 不一致優化思路 3 如何保證資料庫與快取的一致性 當資料發生變化時，先淘汰快取，再修改資料庫 這個點是大家討論的最多的。上篇文章得出這個結論的依據是，由於操作快取與運算元據庫不是原子的，非常有可能出現執行失敗。假設先寫資料庫，再淘...