2021Java大廠高頻面試題:java高級開發面試

Cache aside

Cache aside也就是旁路緩存,是比較經常使用的緩存策略。面試

(1)讀請求常見流程數據庫

應用首先會判斷緩存是否有該數據,緩存命中直接返回數據,緩存未命中即緩存穿透到數據庫,從數據庫查詢數據而後回寫到緩存中,最後返回數據給客戶端。編程

(2)寫請求常見流程緩存

首先更新數據庫,而後從緩存中刪除該數據。markdown

看了寫請求的圖以後,有些同窗可能要問了:爲何要刪除緩存,直接更新不就好了?這裏涉及到幾個坑,咱們一步一步踩下去。併發

Cache aside踩坑

Cache aside策略若是用錯就會遇到深坑,下面咱們來逐個踩。ide

踩坑一:先更新數據庫,再更新緩存atom

若是同時有兩個寫請求須要更新數據,每一個寫請求都先更新數據庫再更新緩存,在併發場景可能會出現數據不一致的狀況。3d

如上圖的執行過程:代理

(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 會當即寫入緩存中,可是隔一段時間纔會批量寫入數據庫中。

這種方式有優勢也有缺點:

  • 優勢是數據寫入速度很是快,適用於頻繁寫的場景。

  • 缺點是緩存和數據庫不是強一致性,對一致性要求高的系統慎用。

一線互聯網大廠Java核心面試題庫

image

頻繁寫的場景。

  • 缺點是緩存和數據庫不是強一致性,對一致性要求高的系統慎用。

一線互聯網大廠Java核心面試題庫

[外鏈圖片轉存中…(img-YZQHgqHd-1625554961306)]

正逢面試跳槽季,給你們整理了大廠問到的一些面試真題,因爲文章長度限制,只給你們展現了部分題目,更多Java基礎、異常、集合、併發編程、JVM、Spring全家桶、MyBatis、Redis、數據庫、中間件MQ、Dubbo、Linux、Tomcat、ZooKeeper、Netty等等…已整理上傳在個人騰訊文檔【一線互聯網大廠Java核心面試題庫】點擊便可領取,並會持續更新…感興趣的朋友能夠看看支持一波!

相關文章
相關標籤/搜索