精品人妻伦一区二区三区久久,狼友av永久网站免费极品在线,欧美日韩黄色大片,香港三日本8a三级少妇三级99

信息薈萃
聯系方式

    固話:021-59786133

    電話:18117117761(微信同號)

    郵箱:yuchengzhineng@qq.com

    網站:http://

精品展示
你的位置:首頁 > 信息薈萃

智慧停車系統(tǒng)高并發(fā)場景下先更新緩存還是先更新數據庫?

2021/5/31 8:50:43??????點擊:
在大型智慧停車系統(tǒng)中,為了減少數據庫壓力通常會引入緩存機制,一旦引入緩存又很容易造成緩存和數據庫數據不一致,導致用戶看到的是舊數據。

為了減少數據不一致的情況,更新緩存和數據庫的機制顯得尤為重要,接下來帶領大家踩踩坑。

Cache aside

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

(1)讀請求常見流程

image.png

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

(2)寫請求常見流程

image.png


首先更新數據庫,然后從緩存中刪除該數據。

看了寫請求的圖之后,有些同學可能要問了:為什么要刪除緩存,直接更新不就行了?這里涉及到幾個坑,我們一步一步踩下去。

Cache aside踩坑

Cache aside策略如果用錯就會遇到深坑,下面我們來逐個踩。

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

如果同時有兩個寫請求需要更新數據,每個寫請求都先更新數據庫再更新緩存,在并發(fā)場景可能會出現數據不一致的情況。

image.png

如上圖的執(zhí)行過程:

(1)寫請求1更新數據庫,將 age 字段更新為18;

(2)寫請求2更新數據庫,將 age 字段更新為20;

(3)寫請求2更新緩存,緩存 age 設置為20;

(4)寫請求1更新緩存,緩存 age 設置為18;

執(zhí)行完預期結果是數據庫 age 為20,緩存 age 為20,結果緩存 age為18,這就造成了緩存數據不是最新的,出現了臟數據。

踩坑二:先刪緩存,再更新數據庫

如果寫請求的處理流程是先刪緩存再更新數據庫,在一個讀請求和一個寫請求并發(fā)場景下可能會出現數據不一致情況。

image.png

如上圖的執(zhí)行過程:

(1)寫請求刪除緩存數據;

(2)讀請求查詢緩存未擊中(Hit Miss),緊接著查詢數據庫,將返回的數據回寫到緩存中;

(3)寫請求更新數據庫。

整個流程下來發(fā)現數據庫中age為20,緩存中age為18,緩存和數據庫數據不一致,緩存出現了臟數據。

踩坑三:先更新數據庫,再刪除緩存

在實際的系統(tǒng)中針對寫請求還是推薦先更新數據庫再刪除緩存,但是在理論上還是存在問題,以下面這個例子說明。

image.png

如上圖的執(zhí)行過程:

(1)讀請求先查詢緩存,緩存未擊中,查詢數據庫返回數據;

(2)寫請求更新數據庫,刪除緩存;

(3)讀請求回寫緩存;

整個流程操作下來發(fā)現數據庫age為20,緩存age為18,即數據庫與緩存不一致,導致應用程序從緩存中讀到的數據都為舊數據。

但我們仔細想一下,上述問題發(fā)生的概率其實非常低,因為通常數據庫更新操作比內存操作耗時多出幾個數量級,上圖中最后一步回寫緩存(set age 18)速度非??欤ǔ诟聰祿熘巴瓿?。

如果這種極端場景出現了怎么辦?我們得想一個兜底的辦法:緩存數據設置過期時間。通常在系統(tǒng)中是可以允許少量的數據短時間不一致的場景出現。

Read through

在 Cache Aside 更新模式中,應用代碼需要維護兩個數據源頭:一個是緩存,一個是數據庫。而在 Read-Through 策略下,應用程序無需管理緩存和數據庫,只需要將數據庫的同步委托給緩存提供程序 Cache Provider 即可。所有數據交互都是通過抽象緩存層完成的。

image.png

如上圖,應用程序只需要與Cache Provider交互,不用關心是從緩存取還是數據庫。

在進行大量讀取時,Read-Through 可以減少數據源上的負載,也對緩存服務的故障具備一定的彈性。如果緩存服務掛了,則緩存提供程序仍然可以通過直接轉到數據源來進行操作。

Read-Through 適用于多次請求相同數據的場景,這與 Cache-Aside 策略非常相似,但是二者還是存在一些差別,這里再次強調一下:

  • 在 Cache-Aside 中,應用程序負責從數據源中獲取數據并更新到緩存。
  • 在 Read-Through 中,此邏輯通常是由獨立的緩存提供程序(Cache Provider)支持。

Write through

Write-Through 策略下,當發(fā)生數據更新(Write)時,緩存提供程序 Cache Provider 負責更新底層數據源和緩存。

緩存與數據源保持一致,并且寫入時始終通過抽象緩存層到達數據源。

Cache Provider類似一個代理的作用。

image.png

rite-Through流程

Write behind

Write behind在一些地方也被成為Write back, 簡單理解就是:應用程序更新數據時只更新緩存, Cache Provider每隔一段時間將數據刷新到數據庫中。說白了就是延遲寫入。

image.png


Write behind流程

如上圖,應用程序更新兩個數據,Cache Provider 會立即寫入緩存中,但是隔一段時間才會批量寫入數據庫中。

這種方式有優(yōu)點也有缺點:

· 

優(yōu)點是數據寫入速度非???,適用于頻繁寫的場景。

· 

· 

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

· 

總結一下

學了這么多,相信大家對緩存更新的策略都已經有了清晰的認識。最后稍稍總結一下。

緩存更新的策略主要分為三種:

· Cache aside

· Read/Write through

· Write behind

Cache aside 通常會先更新數據庫,然后再刪除緩存,為了兜底通常還會將數據設置緩存時間。

Read/Write through 一般是由一個 Cache Provider 對外提供讀寫操作,應用程序不用感知操作的是緩存還是數據庫。

Write behind簡單理解就是延遲寫入,Cache Provider 每隔一段時間會批量輸入數據庫,優(yōu)點是應用程序寫入速度非???。


關鍵詞: 軍車車牌識別 部隊門禁系統(tǒng) 智慧軍營 數字軍營 營區(qū)出入管理系統(tǒng) 部隊請銷假系統(tǒng) 部隊派車系統(tǒng) 數字營區(qū) 智慧營區(qū) 智慧軍營整體解決方案 智慧部隊 智慧軍隊 數字部隊 智能化營區(qū) 部隊人臉識別系統(tǒng) 涉密管理系統(tǒng) 營房管理系統(tǒng) 維修管理系統(tǒng) 營區(qū)訪客系統(tǒng) 離位報警系統(tǒng) 車輛維修系統(tǒng) 上海車牌識別系統(tǒng) 部隊停車場管理系統(tǒng)

電話: 18117117761(24小時)? ? 021-59786133? 郵箱:yuchengzhineng@qq.com ?QQ: 9223677 ? 9603426 ? 529131638

Copyright 2019 上海譽澄智能科技有限公司 版權所有 All Rights Reserved ? 網站移動版入口

滬公網安備 31011402002854號 滬ICP備10219392號-1