寫請求來了，要更新數據庫和緩存，一前一後更新，就可能致使緩存和DB中的數據在一段時間內不一致。數據庫
你只要用緩存，就可能會涉及到緩存與數據庫雙存儲雙寫，你只要是雙寫，就必定會有數據一致性的問題，那麼你如何解決一致性問題？緩存
通常來講，就是若是你的系統不是嚴格要求緩存+數據庫必須一致性的話，緩存能夠稍微的跟數據庫偶爾有不一致的狀況，併發
若是是強一致性，讀請求和寫請求串行化，串到一個內存隊列裏去，這樣就能夠保證必定不會出現不一致的狀況（效率極低。）異步
串行化以後，就會致使系統的吞吐量會大幅度的下降，用比正常狀況下多幾倍的機器去支撐線上的一個請求。spa
還有一種方式就是可能會暫時產生不一致的狀況，可是發生的概率特別小，就是先更新數據庫，而後再刪除緩存。隊列
這種狀況不存在併發問題麼？內存
不是的。假設這會有兩個請求，一個請求A作查詢操做，一個請求B作更新操做，那麼會有以下情形產生資源
（1）緩存恰好失效
（2）請求A查詢數據庫，得一箇舊值
（3）請求B將新值寫入數據庫
（4）請求B刪除緩存
（5）請求A將查到的舊值寫入緩存class
ok，若是發生上述狀況，確實是會發生髒數據。效率
然而，發生這種狀況的機率又有多少呢？
發生上述狀況有一個先天性條件，就是步驟（3）的寫數據庫操做比步驟（2）的讀數據庫操做耗時更短，纔有可能使得步驟（4）先於步驟（5）。但是，你們想一想，數據庫的讀操做的速度遠快於寫操做的（否則作讀寫分離幹嗎，作讀寫分離的意義就是由於讀操做比較快，耗資源少），所以步驟（3）耗時比步驟（2）更短，這一情形很難出現。
如何解決上述併發問題？
首先，給緩存設有效時間是一種方案。其次，採用異步延時刪除策略，保證讀請求完成之後，再進行刪除操做。