2021年最新Java面試經歷，36歲老碼農現身說法
Cache aside
Cache aside也就是旁路快取，是比較常用的快取策略。
（1）讀請求常見流程
應用首先會判斷快取是否有該資料，快取命中直接返回資料，快取未命中即快取穿透到資料庫，從資料庫查詢資料然後回寫到快取中，最後返回資料給客戶端。
（2）寫請求常見流程
首先更新資料庫，然後從快取中刪除該資料。
看了寫請求的圖之後，有些同學可能要問了：為什麼要刪除快取，直接更新不就行了？這裡涉及到幾個坑，我們一步一步踩下去。
Cache aside踩坑
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）速度非常快，通常會在更新資料庫之前完成。
如果這種極端場景出現了怎麼辦？我們得想一個兜底的辦法：快取資料設定過期時間。通常在系統中是可以允許少量的資料短時間不一致的場景出現。
Read through
在 Cache Aside 更新模式中，應用程式碼需要維護兩個資料來源頭：一個是快取，一個是資料庫。而在?Read-Through?策略下，應用程式無需管理快取和資料庫，只需要將資料庫的同步委託給快取提供程式?Cache Provider?即可。所有資料互動都是通過抽象快取層完成的。
如上圖，應用程式只需要與Cache Provider互動，不用關心是從快取取還是資料庫。
在進行大量讀取時，Read-Through?可以減少資料來源上的負載，也對快取服務的故障具備一定的彈性。如果快取服務掛了，則快取提供程式仍然可以通過直接轉到資料來源來進行操作。
Read-Through 適用於多次請求相同資料的場景，這與 Cache-Aside 策略非常相似，但是二者還是存在一些差別，這裡再次強調一下：
- 在 Cache-Aside 中，應用程式負責從資料來源中獲取資料並更新到快取。
- 在 Read-Through 中，此邏輯通常是由獨立的快取提供程式（Cache Provider）支援。
Write through
Write-Through?策略下，當發生資料更新(Write)時，快取提供程式?Cache Provider?負責更新底層資料來源和快取。
快取與資料來源保持一致，並且寫入時始終通過抽象快取層到達資料來源。
Cache Provider類似一個代理的作用。
Write behind
Write behind在一些地方也被成為Write back， 簡單理解就是：應用程式更新資料時只更新快取，?Cache Provider每隔一段時間將資料重新整理到資料庫中。說白了就是延遲寫入。
如上圖，應用程式更新兩個資料，Cache Provider 會立即寫入快取中，但是隔一段時間才會批量寫入資料庫中。
這種方式有優點也有缺點：
-
優點是資料寫入速度非常快，適用於頻繁寫的場景。 -
缺點是快取和資料庫不是強一致性，對一致性要求高的系統慎用。
言盡於此，完結
無論是一個初級的 coder，高階的程式設計師，還是頂級的系統架構師，應該都有深刻的領會到設計模式的重要性。
- 第一，設計模式能讓專業人之間交流方便，如下：
程式設計師A：這裡我用了XXX設計模式
程式設計師B：那我大致瞭解你程式的設計思路了
- 第二，易維護
專案經理：今天客戶有這樣一個需求…
程式設計師：明白了，這裡我使用了XXX設計模式，所以改起來很快
- 第三，設計模式是程式設計經驗的總結
程式設計師A：B，你怎麼想到要這樣去構建你的程式碼
程式設計師B：在我學習了XXX設計模式之後，好像自然而然就感覺這樣寫能避免一些問題
- 第四，學習設計模式並不是必須的
程式設計師A：B，你這段程式碼使用的是XXX設計模式對嗎？
程式設計師B：不好意思，我沒有學習過設計模式，但是我的經驗告訴我是這樣寫的
從設計思想解讀開源框架，一步一步到Spring、Spring5、SpringMVC、MyBatis等原始碼解讀，我都已收集整理全套，篇幅有限，這塊只是詳細的解說了23種設計模式，整理的檔案如下圖一覽無餘！
蒐集費時費力，能看到此處的都是真愛！