Redis使用場景 目錄 緩存 緩存穿透 緩存擊穿 緩存雪崩 雙寫一致性 持久化 數據過期策略 數據淘汰策略 分散式鎖 實現原理（setnx、redission） 其他 哨兵模式、集群腦裂 分片集群、數據讀取規則 redis是單線程的卻很快 緩存 一、緩存穿透 定義：查詢一個不存在的數據，Mysql ...
Redis使用場景
目錄
緩存
- 緩存穿透
- 緩存擊穿
- 緩存雪崩
- 雙寫一致性
- 持久化
- 數據過期策略
- 數據淘汰策略
分散式鎖
- 實現原理（setnx、redission）
其他
- 哨兵模式、集群腦裂
- 分片集群、數據讀取規則
- redis是單線程的卻很快
緩存
一、緩存穿透
定義：查詢一個不存在的數據，Mysql查詢不到數據也不會直接寫入緩存，導致每次請求都要查資料庫
兩個解決方案：
-
緩存空數據
優點：簡單
缺點：消耗記憶體，可能發生不一致問題 -
使用布隆過濾器（作用：攔截不存在的數據）
優點：記憶體占用較少
缺點：實現複雜，存在誤判
舉例說明：根據文章id查詢文章，請求路徑如下：
一個get請求： api/enws/getById/1
正常緩存流程：根據id到redis中爬取數據，若找到數據則返回結果；若redis中未找到，再到資料庫中查找，將結果返回，返回前需將資料庫中查到的數據存儲於redis中
緩存穿透是查詢一個不存在的數據，Mysql查詢不到數據也不會直接寫入緩存，導致每次請求都要查資料庫。導致這種情況一般是由於系統被惡意攻擊，請求路徑被獲取後製造假id（0、複數、很大的值），瘋狂衝擊資料庫，資料庫併發並不高，請求達到一定量就會造成宕機
關於布隆過濾器
二、緩存擊穿
定義：給某個key設置過期時間，當key過期時，剛好這個時間點key有大量的併發請求，這些併發請求可能瞬間把DB壓垮。
雖然我們再查詢時把數據同步到redis，但可能在緩存重建時，存入的是多個表彙總的結果，可能需要分組統計花費較長的時間，比如花費了50毫秒，這時若有大量請求資料庫是承受不住的。
兩個解決方案：
- 互斥鎖
- 邏輯過期
互斥鎖：強一致性、性能差
比如：跟錢相關的業務需要保證強一致性
互斥鎖文字描述：線程1請求查詢，在redis中未查詢到緩存數據，於是獲取互斥鎖，查詢資料庫重建緩存數據，寫入緩存，釋放鎖；線程1進行的同時線程2也請求查詢未命中，於是獲取互斥鎖但失敗了，只能休眠會再一直重試到緩存命中。
互斥鎖的作用：確保任意時刻只有一個線程可以訪問共用資源，從而避免數據競爭和不一致問題。
邏輯過期：高可用、性能優
比如：互聯網行業，更加註重用戶體驗
邏輯過期文字描述：線程1查詢緩存，發現邏輯時間已過期，獲取互斥鎖後，開啟新線程2查詢資料庫重建緩存數據、寫入緩存並重置邏輯過期時間、釋放鎖，同時線程1中繼續並返回過期數據。線程1進行的同時線程3也查詢發現邏輯時間過期，獲取互斥鎖失敗後返回過期數據。當線程4命中緩存並沒有過期，就可以獲得最新查詢數據了。
三、緩存雪崩
定義：指同一時段大量緩存key同時失效或Redis服務宕機，導致大量請求達到資料庫造成巨大壓力。
解決方案
- 給不同key的TTL添加隨機值（給不同key設置不同的過期時間）
- 利用redis集群服務的可用性，比如哨兵模式、集群模式（解決redis宕機問題）
- 給緩存業務添加降級限流策略，例如ngxin、spring cloud gateway
- 給業務添加多級緩存，例如Guava、Caffeine
降級可作為系統的保底策略，適用於穿透、擊穿、雪崩
四、雙寫一致性
定義：當修改了資料庫數據也要更新緩存的數據，保持緩存和資料庫的數據一致
- 讀操作：緩存命中，直接返回；緩存未命中查詢資料庫，寫入緩存，設定超時時間
- 寫操作：延遲雙刪
先刪除緩存，還是先修改資料庫？
先刪除緩存，再修改資料庫
- 正常情況：
- 出現臟數據情況：
修改資料庫數據前被其他線程寫入緩存，導致緩存與資料庫數據不一致
先修改操作資料庫，再刪除緩存
-
正常情況：
-
出現臟數據情況：
線程1得到的返回的結果寫入緩存，與線程2更新的資料庫數據對不上
所以不管先刪除緩存，還是先修改資料庫都會出現臟數據，應該採取延遲雙刪的方法，即刪除兩次緩存，可以降低臟數據的出現。延遲刪除是因為資料庫是主存模式，延遲刪除讓主節點把數據同步到從節點，但延遲刪除也只是控制了一部分臟數據的風險，由於延遲時間不好確認，也有臟數據的風險，做不到絕對的強一至。
如何保持強一致性？
- 可以採用分散式鎖（互斥鎖）
強一致，性能低
一般存入緩存的數據都是讀多寫少，用讀寫鎖來進行控制
- 共用鎖：加鎖後其他線程可以共用讀操作
- 排他鎖：加鎖後阻塞其他線程讀寫操作
具體代碼操作：
- 讀操作
- 寫操作
- 非同步通知保證數據的最終一致性
利用非同步通知解決數據同步問題
- MQ
- canal
它是基於mysql的主從同步實現
當有數據修改寫入資料庫後，資料庫一旦變化就會記錄到BINLOG日誌文件中，cannal通過binlog數據文件獲取變化，我們就可以在緩存服務獲取變化的數據，然後更新到緩存
五、持久化
兩種方式：RDB、AOF
- RDB(redis數據備份文件，也叫數據快照)
將記憶體中的數據存到磁碟中，當redis實例故障重啟後，從磁碟讀取快照文件，恢複數據
人工主動備份：
redis內部有觸發RBG的機制，可以在redis.conf文件中找到
- AOF（追加文件，redis處理的每一個命令都記錄在AOF文件，可看作是命令日誌文件）
六、數據過期策略
Redis過期刪除策略：惰性刪除 + 定期刪除兩種策略配合使用
- 惰性刪除
定義：訪問key時再判斷是否過期，過期則刪除，反之返回key
優點：對CPU友好
缺點：對記憶體不友好
- 定期刪除
定義：每隔一段時間，會從一定數量的資料庫中取出一定數量的隨機key進行檢查，並刪除其中的過期key（隨之時間推一會遍歷所有key，把所有過期key刪除）
- 定期刪除分兩種模式：SLOW、FAST
SLOW模式是定時任務，執行頻率預設為10hz，每次不超過25ms，以通過修改配置文件redis.conf的hz選項來調整次數
FAST模式執行頻率不固定，但兩次間隔不低於2ms，每次耗時不好過1ms
優點：可通過限制刪除操作執行時長和頻率減少刪除操作對CPU的影響，另外定期刪除能有效釋放過期鍵占用的記憶體
缺點：難以確定刪除操作執行的時長和頻率
七、數據淘汰策略
定義：當redis記憶體不足想添加新key，會按照某種規則將記憶體數據刪除，這種數據刪除規則被成為記憶體的淘汰策略
- redis支持8中不同策略來選擇刪除key
- noeviction：不淘汰任何key，但記憶體滿不語序寫入新數據，預設策略
使用建議
本文來自博客園，作者：竹林編夢，轉載請註明原文鏈接：https://www.cnblogs.com/PandaVerse/p/18399430
