Cache-Aside
該模式是從數據倉庫中將數據加載到緩存中，從而提高訪問速度的一種模式。該模式可以有效的提高性能，同時也能一定程度上保證緩存中的數據和數據倉庫中的數據的一致性，和同步數據到數據倉庫中。
（1）讀請求常見流程(最佳實踐)
應用首先會判斷緩存是否有該數據，緩存命中直接返回數據，緩存未命中即緩存穿透到數據庫，從數據庫查詢數據然后回寫到緩存中，最后返回數據給客戶端。
（2）寫請求常見流程(最佳實踐)
首先更新數據庫，然后從緩存中刪除該數據。
為什么要刪除緩存，直接更新不就行了？這里涉及到幾個坑，一步步踩下去。
踩坑
Cache aside策略如果用錯就會遇到深坑，下面我們來逐個踩。
踩坑一：先更新數據庫，再更新緩存
如果同時有兩個寫請求需要更新數據，每個寫請求都先更新數據庫再更新緩存，在並發場景可能會出現數據不一致的情況。
如上圖的執行過程：
（1）寫請求1更新數據庫，將 age 字段更新為18；
（2）寫請求2更新數據庫，將 age 字段更新為20；
（3）寫請求2更新緩存，緩存 age 設置為20；
（4）寫請求1更新緩存，緩存 age 設置為18；
執行完預期結果是數據庫 age 為20，緩存 age 為20，結果緩存 age為18，這就造成了緩存數據不是最新的，出現了臟數據。
踩坑二：先刪緩存，再更新數據庫
如果寫請求的處理流程是先刪緩存再更新數據庫，在一個讀請求和一個寫請求並發場景下可能會出現數據不一致情況。
如上圖的執行過程：
（1）寫請求刪除緩存數據；
（2）讀請求查詢緩存未擊中(Hit Miss)，緊接着查詢數據庫，將返回的數據回寫到緩存中；
（3）寫請求更新數據庫。
整個流程下來發現數據庫中age為20，緩存中age為18，緩存和數據庫數據不一致，緩存出現了臟數據。
踩坑三：先更新數據庫，再刪除緩存
在實際的系統中針對寫請求還是推薦先更新數據庫再刪除緩存，但是在理論上還是存在問題，以下面這個例子說明。
如上圖的執行過程：
（1）讀請求先查詢緩存，緩存未擊中，查詢數據庫返回數據；
（2）寫請求更新數據庫，刪除緩存；
（3）讀請求回寫緩存；
整個流程操作下來發現數據庫age為20，緩存age為18，即數據庫與緩存不一致，導致應用程序從緩存中讀到的數據都為舊數據。
但我們仔細想一下，上述問題發生的概率其實非常低，因為通常數據庫更新操作比內存操作耗時多出幾個數量級，上圖中最后一步回寫緩存（set age 18）速度非常快，通常會在更新數據庫之前完成。
如果這種極端場景出現了怎么辦？我們得想一個兜底的辦法：緩存數據設置過期時間。通常在系統中是可以允許少量的數據短時間不一致的場景出現。