基本原則
-
只應將熱數據放到緩存中
-
所有緩存信息都應設置過期時間
-
緩存過期時間應當分散以避免集中過期
-
緩存key應具備可讀性
-
應避免不同業務出現同名緩存key
-
可對key進行適當的縮寫以節省內存空間
-
選擇合適的數據結構
-
確保寫入緩存中的數據是完整且正確的
-
避免使用耗時較長的操作命令，如：keys *
- Redis默認配置中操作耗時超過10ms即視為慢查詢
-
一個key對應的數據不應過大
- 對於string類型，一個key對應的value大小應控制在10K以內，1K左右更優
- hash類型，不應超過5000行
-
避免緩存穿透
- 數據庫中未查詢到的數據，可在Redis中設置特殊標識，以避免因緩存中無數據而導致每次請求均達到數據庫
-
緩存層不應拋出異常
- 緩存應有降級處理方案，緩存出了問題要能回源到數據庫進行處理
-
可以進行適當的緩存預熱
- 對於上線后可能會有大量讀請求的應用，在上線之前可預先將數據寫入緩存中
-
讀的順序是先緩存，后數據庫；寫的順序是先數據庫，后緩存
-
數據一致性問題
-
數據源發生變更時可能導致緩存中數據與數據源中數據不一致，應根據實際業務需求來選擇適當的緩存更新策略：
-
主動更新：在數據源發生變更時同步更新緩存數據或將緩存數據過期。一致性高，維護成本較高。
-
被動刪除：根據緩存設置的過期時間有Redis負責數據的過期刪除。一致性較低，維護成本較低。
-
-
緩存過期算法
-
LRU
- 淘汰最后使用時間距當前時間較長的數據
-
LFU
- 淘汰某段時間內的使用頻次較低的數據
-
FIFO
- 淘汰先寫入的數據