該模式是從資料倉儲中將資料載入到快取中，從而提高訪問速度的一種模式。該模式可以有效的提高效能，同時也能一定程度上保證快取中的資料和資料倉儲中的資料的一致性，和同步資料到資料倉儲中。
（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）速度非常快，通常會在更新資料庫之前完成。
如果這種極端場景出現了怎麼辦？我們得想乙個兜底的辦法：快取資料設定過期時間。通常在系統中是可以允許少量的資料短時間不一致的場景出現。
快取引入的元件 先更新資料庫，還是快取？
這一篇來聊聊快取一致性的問題，這裡討論的範圍有限，僅僅是應用快取與後端儲存的一致性，當然也會適當做下延伸 如下 4 種組合，該如何決策？標準在 一致性問題出在哪？update cache update db update db update cache delete cache update db ...
高併發場景下，到底先更新快取還是先更新資料庫
在大型系統中，為了減少資料庫壓力通常會引入快取機制，一旦引入快取又很容易造成快取和資料庫資料不一致，導致使用者看到的是舊資料。為了減少資料不一致的情況，更新快取和資料庫的機制顯得尤為重要，接下來帶領大家踩踩坑。cache aside也就是旁路快取，是比較常用的快取策略。1 讀請求常見流程 cache...
快取 先資料庫還是先快取 2
到底是先運算元據庫還是先操作快取，取決於哪種方案可以避免資料不一致，或者資料不一致的概率更低。下面的分析會基於cache aside策略展開，為什麼基於cache aside策略，請檢視博文 快取更新策略 先快取再資料庫的方案，在併發讀寫情況下，會出現資料不一致的情況，如下圖所示。而且，這種不一致情...