寫入資料庫成功，即讓快取失效，下一次讀取時再快取。這是快取的實時策略。當然，並不適用於所有的場景。

快取一般是直接將資料放到離計算最近的地方（目前大部分放在記憶體中），解決 CPU 和 I/O 的速度不匹配的問題，用來加快計算處理速度，通常會對熱點資料進行快取，保證較高的命中率。在網際網路的架構設計中，資料庫及快取一般相互配合使用來滿足不同的場景需求，比如在大流量的請求中會使用快取來加速。

Redis 在網際網路行業中使用最為廣泛。Redis 在很多時候也被稱為“記憶體資料庫”，它集合了快取和資料庫的優勢，但並非開啟持久化和主備同步機制就可以高枕無憂。從架構設計的角度思考：快取就是快取，快取資料會隨時丟失，快取存在的目的是攔截到資料庫的請求，相比資料的可靠性、一致性，還是吞吐量、穩定性優先。

快取有三大矛盾：

快取實時性和一致性問題：當有了寫入後咋辦？快取的穿透問題：當沒有讀到咋辦？快取對資料庫高併發訪問：都來訪問資料庫咋辦？

第一個也就是本問題。而解決這三大矛盾的重新整理策略包括：

實時策略——使用者體驗好，是預設應該使用的策略；非同步策略——適用於併發量大，但是資料沒有那麼關鍵的情況，好處是實時性好；定時策略——併發量實在太大，資料量也大的情況，非同步都難以滿足的場景；

實時策略是最常用的策略，也是保持實時性最好的策略：

讀取的過程，應用程式先從 cache 取資料，沒有得到，則從資料庫中取資料，成功後，放到快取中。如果命中，應用程式從 cache 中取資料，取到後返回。寫入的過程，把資料存到資料庫中，成功後，再讓快取失效，失效後下次讀取的時候，會被寫入快取。

從使用者體驗的角度，應該資料庫有了寫入，就馬上廢棄快取，觸發一次資料庫的讀取，從而更新快取。

然而，這和第三個問題（高併發）就矛盾了——如果所有的都實時從資料庫裡面讀取，高併發場景下，資料庫往往受不了。