Redis緩存更新策略詳解
本文實例為大傢分享瞭Redis緩存更新策略的具體代碼，供大傢參考，具體內容如下
一、緩存的收益與成本
1.1 收益
- 加速讀寫：因為緩存通常都是全內存的（例如Redis、Memcache），而存儲層通常讀寫性能不夠強悍（例如MySQL），內存讀寫的速度遠遠高於磁盤I/O。通過緩存的使用可以有效地加速讀寫，優化用戶體驗。
- 降低後端負載：幫助後端減少訪問量（Mysql設置有最大連接數，如果大量的訪問同時達到數據庫，而磁盤I/O的速度又很慢，很容易造成最大連接數被使用完，但Redis 理論最大）和復雜計算（例如很復雜的SQL語句），在很大程度降低瞭後端的負載。
1.2 成本
- 數據不一致性：緩存層和存儲層的數據存在著一定時間窗口的不一致性，時間窗口跟更新策略有關。
- 代碼維護成本：加入緩存後，需要同時處理緩存層和存儲層的邏輯，增大瞭開發者維護代碼的成本。
- 運維成本：以Redis Cluster為例，加入後無形中增加瞭運維成本。
1.3 使用場景
- 開銷大的復雜計算：以MySQL為例子，一些復雜的操作或者計算（例如大量聯表操作、一些分組計算），如果不加緩存，不但無法滿足高並發量，同時也會給MySQL帶來巨大的負擔。
- 加速請求響應：即使查詢單條後端數據足夠快，那麼依然可以使用緩存，以Redis為例子，每秒可以完成數萬次讀寫，並且提供的批量操作可以優化整個IO鏈的響應時間
二、緩存更新策略
2.1 內存溢出淘汰策略
思考：在生產環境的 redis 經常會丟掉一些數據，寫進去瞭，過一會兒可能就沒瞭。是什麼原因？
Redis 緩存通常都是全內存，內存是很寶貴而且是有限的，磁盤是廉價而且是大量的。可能一臺機器就幾十個 G 的內存，但是可以有幾個 T 的硬盤空間。Redis 主要是基於內存來進行高性能、高並發的讀寫操作。那既然內存是有限，比如 redis 就隻能用 10G，你要是往裡面寫瞭 20G 的數據，會咋辦？當然會幹掉 10G 的數據，然後就保留 10G 的數據瞭。那幹掉哪些數據？保留哪些數據？當然是幹掉不常用的數據，保留常用的數據瞭。數據明明過期瞭，怎麼還占用著內存？這是由 redis 的過期策略來決定。
在Redis中，當所用內存達到maxmemory上限（used_memory>maxmemory）時會觸發相應的溢出控制策略。具體策略受maxmemory-policy參數控制。
Redis支持6種策略：
- noeviction：默認策略，不會刪除任何數據，拒絕所有寫入操作並返回客戶端錯誤信息（error）OOM command not allowed when used memory，此時Redis隻響應讀操作
- volatile-lru：根據LRU算法刪除設置瞭超時屬性（expire）的鍵，直到騰出足夠空間為止。如果沒有可刪除的鍵對象，回退到noeviction策略
- volatile-random：隨機刪除過期鍵，直到騰出足夠空間為止
- allkeys-lru：根據LRU算法刪除鍵，不管數據有沒有設置超時屬性，直到騰出足夠空間為止
- allkeys-random：隨機刪除所有鍵，直到騰出足夠空間為止（不推薦）
- volatile-ttl：根據鍵值對象的ttl（剩餘時間(time to live,TTL) ）屬性，刪除最近將要過期數據。如果沒有，回退到noeviction策略
LRU :Least Recently Used ，最近最少使用的，緩存的元素有一個時間戳，當緩存容量滿瞭，而又需要騰出地方來緩存新的元素的時候，那麼現有緩存元素中時間戳離當前時間最遠的元素將被清出緩存。
內存溢出控制策略可以采用config set maxmemory-policy{policy}動態配置。寫命令導致當內存溢出時會頻繁執行回收內存成本很高，在主從復制架構中，回收內存操作對應的刪除命令會同步到從節點來，來保障主從節點數據一致性，從而導致寫放大的問題。
2.2 過期策略
Redis 服務端采用的 過期策略是 ： 惰性刪除 + 定期刪除
惰性刪除：
Redis的每個庫都有一個過期字典，過期字典中保存所有key的過期時間。當客戶端讀取一個key時會先到過期字典內查詢key是否已經過期，如果key已經超過，會執行刪除操作並返回空。這種策略是出於節省CPU成本考慮，但是單獨用這種方式存在內存泄露的問題，當過期鍵一直沒有訪問將無法得到及時刪除，從而導致內存不能及時釋放。
定時刪除：
Redis內部維護一個定時任務，默認每秒運行10次過期掃描（通過 redis.conf 中通過 hz 配置 修改運行次數），掃描並不是遍歷過期字典中的所有鍵，而是采用瞭自適應算法，根據鍵的過期比例、使用快慢兩種速率模式回收鍵：
1.從過期字典中隨機取出 20 個鍵
2.刪除這 20 個鍵中過期的鍵
3.如果過期鍵的比例超過 25% ，重復步驟 1 和 2
為瞭保證掃描不會出現循環過度，一直在執行定時刪除定時任務無法對外提供服務，導致線程卡死現象，還增加瞭掃描時間的上限，默認是 25 毫秒（即默認在慢模式下，25毫秒還未執行完，切換為塊模式，模式下超時時間為1毫秒且2秒內隻能運行1次，當慢模式執行完畢正常退出，會重新切回快模式）
三、應用方更新
1.應用程序先從cache取數據，沒有得到，則從數據庫中取數據，成功後，放到緩存中。
2.先刪除緩存，再更新數據庫：這個操作有一個比較大的問題，更新數據的請求在對緩存刪除完之後，又收到一個讀請求，這個時候由於緩存被刪除所以直接會讀庫，讀操作的數據是老的並且會被加載進入緩存當中，後續讀請求全部訪問的老數據。
3.先更新數據庫，再刪除緩存(推薦)為什麼不是寫完數據庫後更新緩存？主要是怕兩個並發的寫操作導致臟數據。
四、緩存粒度
1 通用性
緩存全部數據比部分數據更加通用，但從實際經驗看，很長時間內應用隻需要幾個重要的屬性。
2 占用空間
緩存全部數據要比部分數據占用更多的空間，存在以下問題：
- 全部數據會造成內存的浪費。
- 全部數據可能每次傳輸產生的網絡流量會比較大，耗時相對較大，在極端情況下會阻塞網絡。
- 全部數據的序列化和反序列化的CPU開銷更大。
3 代碼維護
全部數據的優勢更加明顯，而部分數據一旦要加新字段需要修改業務代碼，而且修改後通常還需要刷新緩存數據。
以上就是本文的全部內容，希望對大傢的學習有所幫助，也希望大傢多多支持WalkonNet。