Redi緩存注意事項

緩存使用的場景

在一個高頻訪問的應用系統中，每次用戶的請求須要去存儲中獲取數據，會對數據庫形成很大的壓力、容易致使數據庫的奔潰。因此纔會出現緩存來分擔一部分的數據庫的壓力。

具體會產生數據庫訪問壓力的業務場景以下：

1 高頻訪問數據存儲會對數據庫的QPS形成很大的壓力。

2數據統計類的查詢須要消耗很大的數據庫cpu、改爲由定時任務產生數據推送緩存、每次查詢從緩存裏面取。

3 業務中產生中間態的數據沒有什麼業務含義、但有須要有個存儲來持久化、因此放到緩存中來。例如驗證碼、登陸的token等。 

 

緩存使用的問題

 

1 緩存一致性問題

當數據時效性要求很高時，須要保證緩存中的數據與數據庫中的保持一致，並且須要保證緩存節點和副本中的數據也保持一致，不能出現差別現象。這就比較依賴緩存的過時和更新策略。通常會在數據發生更改的時，主動移除對應的緩存。

  因此須要經過事物機制來保證緩存的一致性。

2緩存高併發訪問問題

在高併發場景下，有多個請求去共同請求一份相同的業務數據。有可能多個請求先去從緩存中獲取數據、獲取不到的併發的去從數據庫獲取數據，對後端數據庫形成極大的衝擊，甚至致使 「雪崩」現象。

方案一

能夠作一個隨機的等待、錯峯去訪問緩存的信息。這樣就能保證同一時刻高併發的訪問、通過時間離散以後只有小部分的請求訪問數據庫、大部分的請求去命中緩存。

方案二

能夠按照比例限制有部分數據直接訪問數據庫而後更新緩存、大部分的數據直接請求緩存。

按照實際的場景去作判斷例如 1%的場景直接訪問數據庫，99%的能夠經過緩存獲取到數據。

方案一和方案有什麼區別呢？你們能夠思考下。

 

3緩存擊穿的問題

 在系統設計的的時候預期是經過緩存來減輕數據庫的壓力、防止數據奔潰的狀況。在某個實際發生的場景中、大量的請求並無命中緩存而致使了大量請求達到數據庫、從而致使數據庫有巨大沖擊和壓力。

 場景一 緩存中沒有數據

  在某個大促活動中有大量的熱點數據，互動一開始須要訪問這些數據。因爲活動開始的時候洪峯流量到來，全部的請求緩存、緩存直接擊穿，訪問數據庫致使數據庫直接cpu 100%,業務系統直接奔潰。

對於這種場景能夠提早對數據進行預熱，開活動開始前先將數據推送到緩存中。

 

 場景二 緩存集中失效

 

因爲咱們在緩存使用的過程當中會設置緩存的失效時間、若是設置的不合理可能會致使數據集中失效的狀況。因爲緩存集中失效會致使系統緩存穿透、在同一時刻高併發的訪問數據，形成數據雪崩。

解決這種場景的能夠將失效的時間由固定值+隨機值來構成。EXPIRE_TIME=FIX_TIME+RUND_TIME 例如你想保證整個EXPIRE_TIME是5S 左右，能夠 經過EXPIRE_TIME=4000+Random(1000)

3單條緩存數據過大

  咱們大多數緩存服務的實現都依賴於內存，而大多數緩存服務在設計的時候都是用來存儲不少小數據的內存分配機制。而內存分配算法都是 512 bte ,1k,2k,4k的內存分配機制來確保系統的內存可以容納更多的記錄數。

 同時對接持久存儲的時候大多都遵循磁盤4k對其的刷盤原理。若是咱們存儲的一條記錄數據超過4K、對整個緩存的性能形成很大的影響。從而致使系統oom。

例如REDIS內存分配策略：

Redis默認內存分配器採用jemalloc，可選的分配器還有：glibe、tcmalloc。

內存分配器是爲了更好的管理和重複利用內存，分配內存策略通常採用固定範圍的內存塊進行內存分配。

這裏不去深究jemalloc的內存分配原理，簡單地說jemalloc將內存空間劃分爲三個部分：Small class、Large class、Huge class，每一個部分又劃分爲不少小的內存塊單位： 
- Small class: [8byte], [16byte, 32byte, … 128byte], [192byte, 256byte, … 512byte], [768byte, 1024byte, … 3840byte] 
- Large class: [4kb, 8kb, 12kb, … 4072kb] 
- Huge class: [4mb, 8mb, 12mb …]

https://blog.csdn.net/Leon_cx/article/details/82597722

常見使用方式

 1定時失效

 

用發起請求後系統從緩存獲取數據、獲取不到從數據庫獲取、獲取以後放入到緩存中，設置一個主動失效的時間。

 

2 主動失效

 

在數據查詢的時候會設置一個時間、超時會依賴緩存自身的機制來失效數據。當數據更新的時候、會主動失效緩存。保證緩存的數據和數據庫的數據儘量一致。

3 定時更新緩存

 

對於統計類的需求、每次查詢須要耗費不少數據庫資源、直接查詢數據庫會嚴重影響數據庫的性能。而且數據變化很是快、採用主動或者被動緩存都會有緩存擊穿的風險。因此直接經過定時任務來統計數據、統計完之後會更新到緩存中，每次用去取都是從緩存中查詢。這樣作會形成緩存中的數據不是實時的，但能確保整個系統的穩定性。

 

3 按比例放行更新緩存

 

當用戶在大流量訪問的時候能夠按照比列來更新數據緩存信息 這樣既能保證數據的實時性，又能保證數據庫的穩定性。在用戶訪問量小的狀況下能夠將訪問數據庫的比列調大一點，在數據訪問的高峯期的是能夠將比列調小。