#加速讀寫：因為快取通常都是全記憶體的（例如Redis、Memcache），而儲存層通常讀寫效能不夠強悍（例如MySQL），記憶體讀寫的速度遠高於磁碟I/O。透過快取的使用可以有效加速讀寫，優化使用者體驗。
降低後端負載：幫助後端減少存取量（Mysql設定有最大連接數，如果大量的存取同時達到資料庫，而磁碟I/O的速度又很慢，很容易造成最大連接數被使用完，但Redis 理論最大）和複雜計算（例如很複雜的SQL語句），在很大程度上降低了後端的負載。
#資料不一致性：快取層和儲存層的資料存在著一定時間視窗的不一致性，時間窗口跟更新策略有關。
程式碼維護成本：加入快取後，需要同時處理快取層和儲存層的邏輯，增加了開發者維護程式碼的成本。
維運成本：以Redis Cluster為例，加入後無形增加了維運成本。
#開銷大的複雜計算：以MySQL為例子，一些複雜的運算或計算（例如大量聯表操作、一些分組計算），如果不加緩存，不但無法滿足高並發量，同時也會為MySQL帶來巨大的負擔。
加速請求回應：即使查詢單一後端資料夠快，那麼依然可以使用緩存，以Redis為例子，每秒可以完成數萬次讀寫，並且提供的批次操作可以優化整個IO鏈的響應時間
思考：在生產環境的redis 常常會丟掉一些數據，寫進去了，過一會兒可能就沒了。是什麼原因？
通常情況下，Redis快取都是儲存在記憶體中，但考慮到記憶體寶貴且有限，因此使用廉價而大量的磁碟進行儲存是很常見的。一台機器可能只配備了幾十個 GB 的內存，但可以有幾個 TB 的硬碟容量。 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只回應讀取操作
根據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}動態設定。寫入指令導致當記憶體溢出時會頻繁執行回收記憶體成本很高，在主從複製架構中，回收記憶體操作對應的刪除指令會同步到從節點來，來保障主從節點資料一致性，進而導致寫入放大的問題。
Redis 服務端採用的 過期策略是 ： 惰性刪除 定期刪除
惰性刪除：
每個Redis庫都包含一個過期字典，其中保存了所有鍵的過期時間。當客戶端讀取一個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.先更新資料庫，再刪除快取(推薦)為什麼不是寫完資料庫後更新快取？主要是怕兩個並發的寫入操作導致髒數據。
快取全部資料比部分資料更通用，但從實際經驗看，很長一段時間內應用只需要幾個重要的屬性。
快取全部資料要比部分資料佔用更多的空間，存在以下問題：
全部資料會造成記憶體的浪費。
全部資料可能每次傳輸產生的網路流量會比較大，耗時也相對較大，在極端情況下會阻塞網路。
全部資料的序列化和反序列化的CPU開銷更大。
全量資料具有明顯的優勢，而部分資料若要新增字段，則需要修改業務程式碼，並且通常還需刷新快取數據。
以上是Redis快取更新策略是什麼的詳細內容。更多資訊請關注PHP中文網其他相關文章！
