JB的測試之旅-緩存

前言

最近工做上遇到個問題,從用戶A切換到用戶B,結果用戶B顯示的仍是用戶A的數據前端

問題的緣由很簡單,用戶B使用的仍是用戶A的緩存數據,解決方案也很簡單,獨立保存一份緩存便可;redis

可是,不禁的想問,緩存測試這塊,須要注意什麼?數據庫

那先慢慢了解,到底什麼是緩存?後端

什麼是緩存

緩存是咱們在生活中常常聽到一個詞,如怎麼清理瀏覽器的緩存手機空間不夠了,得刪除緩存硬盤的緩存是否是越大越好等等的問題;瀏覽器

其實這些緩存能夠分紅3種:緩存

  • 一種指硬件上的,像硬盤緩存和CPU緩存;
  • 一種客戶端緩存;
  • 一種是指服務端緩存;

後兩種更像是一種技術或者是服務;bash

  • 硬件緩存:指的是一塊芯片,能夠被集成到硬盤或者是CPU上。它的做用就是充當硬盤(CPU)與外界接口(一般是內存)之間的暫存器,利用緩存能夠減輕系統的負荷,同時提升數據的傳輸速率;
  • 客戶端緩存:某些應用,如瀏覽器,X寶,X信等,爲了實現可以快速響應用戶的請求,會把用戶以前瀏覽的東西(如圖片等)存在本地;在下次訪問時,若是本地的緩存裏有請求的內容,那麼就直接展現出來,不用再次向服務器請求;
  • 服務端緩存:它與客戶端緩存目的相同,只不過是站在服務器這邊考慮的;若是每次接到客戶端請求都要鏈接一次數據庫,當用戶請求多的時候,負載過大;這時能夠把一些常常被請求的數據存放在內存中,當有請求時直接返回,不用通過數據庫,這樣就能夠減輕數據庫的負擔;

小結

緩存是臨時存放數據(使用頻繁的數據)的地方,介於外部請求和真實數據之間;服務器

爲何要用緩存

從一個用戶的角度來看,體驗最好的確定是無論什麼狀況下,都能成功訪問這個頁面,而且打開的速度很快,也就是保證正常工做的前提下時間儘量短;網絡

若是沒有緩存,咱們的體驗多是這樣的:併發

用戶請求一個數據,這個數據得從數據庫中去取,隨着用戶愈來愈多和數據量愈來愈大,每次用戶請求的時間就會愈來愈長,並且數據庫無時不刻都在工做;
這樣用戶和數據庫都很痛苦,時間一長,就有可能發生下面兩件事情:
1)用戶很煩,抱怨頁面加載太慢或者打不開,最後放棄了這個應用;
2)數據庫滿負荷工做,偶爾崩潰(致使頁面錯誤);

分析緣由,是因爲數據庫的鏈接數和鏈接時長是有限制的,但請求過多,超出了數據庫能承受的範圍,致使數據庫崩潰;
那爲何不把一部分數據放在別的地方,這樣有用戶請求這些數據時,就不用從數據庫中取了?

複製代碼

服務器緩存

工做原理

當客戶端向服務器請求一個資源時,服務器首先在緩存中找,若是在緩存中,那麼直接返回,不須要鏈接數據庫;
若是請求的資源不在緩存中,這時再去數據庫中找,找到後返回給客戶端,並將這個資源加入緩存中;
這樣下次請求相同資源時,就不須要鏈接數據庫了。並且若是把緩存放在內存中,由於對內存的操做要比對數據庫操做快得多,這樣請求時間也會縮短;

複製代碼

因此,經過使用緩存,就能夠保證知足用戶的需求,在正常工做的前提下響應時間儘量短;

特別須要注意緩存失效的場景,如:

  • 數據庫的數據已經更新了,那對應的緩存數據也要更新;
  • 緩存超過失效時間,須要從新發起請求來更新緩存;
  • 緩存滿了,好比緩存滿了,從新發起請求,新的資源從新加入緩存,通常作法是把緩存裏最舊的資源剔除,加入新的資源;

前端緩存

類型

緩存分爲兩類:強制緩存和協商緩存,定義以下:

  • 強制緩存:客戶端直接從緩存中讀取數據,不與服務器做交互;
  • 協商緩存:客戶端發送特定的報文到服務器,服務器根據接收到的報文判斷資源是否有更新,有則返回200和最新的資源文件,無則返回304使客戶端從緩存中讀取數據;

緩存由什麼決定?

緩存由http報文的內容決定,關係以下:

image.png-96.7kB

max-age或者expires都決定了緩存的過時時間,會使客戶端再次請求數據時先判斷緩存是否過時,未過時則直接從緩存中讀取數據(強制緩存);

二者的區別是前者是個相對值,相對於客戶端的時間,後者直接定義了截止時間,且相對於服務端的時間

協商緩存由Last-ModifiedIf-Modified-SinceETagIf-None-Match兩組報文決定;

字段的意思分別以下:

  • Last-Modified:表示服務器上某文件最近的修改時間,存在於響應報文;
  • If-Modified-Since:值等於Last-Modified,存在於請求報文,用於將Last-Modified值返回給服務端做比較;

緩存的整體過程

首次請求資源:

image.png-128.4kB

非首次請求資源:

image.png-411.5kB

在第一次請求資源後,瀏覽器會將資源連同響應報文一塊兒緩存到本地,其中響應報文可能包含了關於緩存的頭信息;

於是後續請求的時候,瀏覽器能夠根據本地緩存的頭信息知道資源的緩存決策,判斷是否強制緩存,或者移交服務器判斷是否協商緩存;

緩存穿透、緩存擊穿、緩存雪崩

在服務器緩存裏面,有3個特殊的名詞:緩存穿透、緩存擊穿、緩存雪崩

這3個究竟是什麼?

緩存穿透

正常狀況下,查詢的數據都存在,若是請求一個不存在的數據,也就是緩存和數據庫都查不到這個數據,每次都會去數據庫查詢,這種查詢不存在數據的現象稱爲緩存穿透

穿透帶來的問題

若是每次都拿一個不存在的id去查詢數據庫,可能會致使你的數據庫壓力增大;

如何發現緩存穿透

  • 業務的響應時間:能夠藉助ELK或其餘監控系統,對業務的接口進行檢測,本來緩存就是響應時間比較快的,若是常常超過閾值就必定會有所體現;
  • 總調用數、cache層命中數、storage層命中數

解決辦法--緩存空值

之因此發生穿透,是由於緩存中沒有存儲這些數據的key,從而每次都查詢數據庫;
能夠爲這些key在緩存中設置對應的值爲null,後面查詢這個key的時候就不用查詢數據庫了;
固然爲了健壯性,咱們要對這些key設置過時時間,以防止真的有數據;

複製代碼

緩存擊穿

在高併發的狀況下,大量的請求同時查詢同一個key時,此時這個key正好失效了或者不存在,就會致使同一時間,這些請求都會去查詢數據庫,這樣的現象稱爲緩存擊穿

好比請求一些特殊字符,就會出現該狀況;

引發的緣由

  • 代碼問題,好比保存到緩存時用的是固定值;
  • 惡意攻擊,好比爬蟲,在請求時傳一些不正常的值;

帶來的問題

會形成某一時刻數據庫請求量過大;

解決辦法

採用分佈式鎖,只有拿到鎖的第一個線程去請求數據庫,而後插入緩存,若其它線程獲取鎖失敗,則等待一段時間後重試;

緩存雪崩

當某一時刻發生大規模的緩存失效的狀況,好比緩存服務宕機了;

解決方法

  • 跟緩存穿透同樣加鎖排隊;
  • 創建備份緩存,緩存A和緩存B,A設置超時時間,B不設置超時時間,先從A讀緩存,A沒有則讀B,而且更新A和B的緩存;

解決熱點數據集中失效問題

在設置緩存的時候,通常會給緩存設置一個失效時間,過了這個時間,緩存就失效了;

對於一些熱點的數據來講,當緩存失效之後會存在大量的請求過來,而後打到數據庫去,從而可能致使數據庫崩潰的狀況;

解決辦法

  • 設置不一樣的失效時間;
  • 採用緩存擊穿的解決辦法,加鎖;
  • 永不失效,就是採用定時任務對快要失效的緩存進行更新緩存和失效時間;

緩存的測試點

功能

  • 緩存是否能夠正確被建立,包括位置、名字和內容;
  • 緩存是否被清除,包括主動清楚以及被第三方發起的清除,清除後是否正常工做及清除失效的狀況;
  • 系統運行過程當中,redis緩存數據生效、緩存的數據讀取正確、數據寫入落地正確,數據有效期設置合理;
  • 緩存與數據庫的數據一致性檢測;
  • DB事務性致使回滾,緩存是否回滾,有沒有產生髒數據;
  • 緩存是否有大小限制,達到大小臨界值如何處理;
  • 緩存時忽然被中斷,如何處理;
  • 緩存失效後,是否能正常表現;

自動化

  • 自動化用例中斷言部分設計緩存層斷言而且自動化框架自己對於斷層層次可配置;

性能及穩定性

  • 關注業務自己應用場景及緩存結構,是否使用緩存;
  • 預防緩存穿透、緩存雪崩、緩存擊穿引起的系統風險;

擴容

  • 關注擴容方案設計、老數據備份策略、回滾方案;
  • 關注擴容後分片策略的變化;
  • 擴容後熱點數據失效率或命中率以及對後端DB帶來的壓力;

環境

無網絡&有數據:

  • 緩存大小未超過,緩存時間有效期內,顯示緩存數據加載;
  • 緩存大小超過,本地緩存數據刪除,顯示無網提示,無數據加載;
  • 緩存時間過時,本地緩存數據刪除,顯示無網提示,無數據加載;

無網絡&無數據:

  • 顯示無數據加載;

有網絡&有數據:

  • 緩存大小未超過,緩存時間有校內,顯示緩存數據加載;
  • 緩存大小超過了,本地緩存數據刪除,直接從線上拉取數據;
  • 緩存時間過時,本地緩存數據刪除,直接從線上拉取數據;

有網絡&無數據:

  • 直接從線上拉取數據存到本地;

緩存存儲

  • 客戶端安裝後,有網絡,開始存儲數據到本地;
  • 覆蓋安裝,緩存數據依然存儲在本地;
  • 清除數據、卸載、重裝,內存和本地緩存數據清零;

異常狀況

  • 因爲網絡緣由緩存失敗,則沒法讀取緩存數據;
  • 因爲服務器緣由致使緩存失敗,則沒法取緩存數據;
  • 終端本地的數據接近滿值,內存被佔用,沒法讀取緩存數據;
  • 設置的緩存文件夾和數據文件不可讀寫;
  • 緩存的刷新機制是否手動操做;

小結

以前沒深刻了解過緩存,真的沒有覆蓋那麼多場景,基本都須要瞭解技術細節,才能設計出這樣的測試場景,偏後臺內部邏輯的測試;

相關文章
相關標籤/搜索