redis持久化機制
redis的數據都存放在內存中，如果沒有配置持久化機制，重啓之後就會全丟失了。需要開啓持久化機制，將數據保存到磁盤上，當redis重啓後，可以從磁盤上恢復。
兩種持久化方式RDB和AOF
RDB
在指定時間內對數據記性快照保存，會缺失部分數據。
恢復方式 ：
1.client端直接用命令BGSAVE或者SAVE創建一個內存快照
BGSAVE 調用fork來創建子進程，子進程負責寫入快照磁盤中，而父進程仍然處理命令
SAVE 執行命令過程中，不再響應其他命令
配置文件 redis.conf,默認滿足條件的觸發
# 900秒之內至少一次寫操作
save 900 1
# 300秒之內至少發生10次寫操作
save 300 10
# 60秒之內發生至少10000次
save 60 1000
優點和缺點
| 優點 | 缺點 |
| 對性能影響最小 | 同步丟失數據 |
| 比AOF恢復要快 | 如果數據集非常大且CPU不夠強（比如單核 CPU），Redis在fork子進程時可能會消耗相 對較長的時間，影響Redis對外提供服務的 能力。 |
AOF
記錄每次對服務器數據讀寫的操作命令，服務器重啓，就會執行這些命令恢復原始的數據。
方式：
BGREWRITEAOF命令可以觸發日誌重寫或自動重寫，廢除對同一個Key歷史的無用命令，重建當前數據集所需的最短命令序列。
意外中斷，如果最後的命令只寫了一部分，恢復時則會跳過它，執行後面完整的命令。
配置文件redis.cof
開啓AOF持久化
appendonly yes
AOF策略調整
#每次有數據修改發生時都會寫入AOF文件，非常安全非常慢
appendfsync always
#每秒鐘同步一次，該策略爲AOF的缺省策略，夠快可能會丟失1秒的數據
appendfsync everysec
#不主動fsync,由操作系統決定，更快，更不安全的方法
appendfsync no
優點和缺點
| 優點 | 缺點 |
| 安全 | 文件體積大 |
| 容災 | IO消耗高 |
| 易讀，可修改 | 比RDB慢 |
redis丟失的可能原因
持久化丟失的可能 ：
RDB 方式
快照產生的策略，天生就不保證數據安全
AOF 持久化策略
默認每秒同步一次磁盤，可能會有1秒的數據丟失
每次修改都同步，數據安全可保證，但Redis高性能的特性全無
主從複製丟失的可能：
異步複製，存在一定的時間窗口數據丟失
網絡、服務器問題，存在一定數據的丟失
淘汰策略
首先我們要對內存分配有了解
內存分配
Strings類型：一個String類型的value最大可以存儲512M。
Lists類型：list的元素個數最多爲2^32-1個，也就是4294967295個。
Sets類型：元素個數最多爲2^32-1個，也就是4294967295個。
Hashes類型：鍵值對個數最多爲2^32-1個，也就是4294967295個
# 最大內存控制
maxmemory 最大內存閾值
maxmemory-policy 到達閾值的執行策略
內存壓縮
#配置字段最多512個
hash-max-zipmap-entries 512
#配置value最大爲64字節
hash-max-zipmap-value 64
#配置元素個數最多512個
list-max-ziplist-entries 512
#配置value最大爲64字節
list-max-ziplist-value 64
#配置元素個數最多512個
set-max-intset-entries 512
#配置元素個數最多128個
zset-max-ziplist-entries 128
#配置value最大爲64字節
zset-max-ziplist-value 64
#如果超出範圍，redis將自動轉換成正常大小
過期數據的處理策略
主動處理
（ redis 主動觸發檢測key是否過期）每秒執行10次。
過程如下：
1. 從具有相關過期的密鑰集中測試20個隨機密鑰
2. 刪除找到的所有密鑰已過期
3. 如果超過25％的密鑰已過期，請從步驟1重新開始
被動處理：
1. 每次訪問key的時候，發現超時後被動過期，清理掉
數據恢復階段過期數據的處理策略
RDB方式
過期的key不會被持久化到文件中。
載入時過期的key，會通過redis的主動和被動方式清理掉。
AOF方式
當 redis 使用 AOF 方式持久化時，每次遇到過期的 key redis 會追
加一條 DEL 命令 到 AOF 文件，
也就是說只要我們順序載入執行 AOF 命令文件就會刪除過期的鍵。
LRU算法
Least recently used 最少使用
根據歷史的訪問記錄來進行淘汰數據
核心思想：如果數據最近被訪問過，那麼將來被訪問的機率也更高。
注意：Redis的LRU算法並非完整的實現，完整的LRU實現是因爲這需要太多的內存。
方法：通過對少量keys進行取樣(50%)，然後回收其中一個最好的key。
配置方式： maxmemory-samples 5
LFU算法
Least Frequently Used
根據數據的歷史訪問頻率來淘汰數據
核心思想：如果數據過去被訪問多次，那麼將來被訪問的頻率也更高。
Redis實現的是近似的實現，每次對key進行訪問時，用基於概率的對數計數器來記錄
訪問次數，同時這個計數器會隨着時間推移而減小。
Morris counter算法依據：
https://en.wikipedia.org/wiki/Approximate_counting_algorithm
啓用LFU算法後，可以使用熱點數據分析功能。（ redis-cli --hotkeys ）
內存回收策略
配置文件：maxmemory-policy noeviction
動態設置：maxmemory-policy noeviction
| 回收策略 | 備註 |
| noeviction | 客戶端嘗試執行會讓更多內存被使用的命令直接報錯 |
| allkeys-lru | 在所有key裏執行LRU算法 |
| volatile-lru | 在所有已經過期的key裏執行LRU算法 |
| volatile-lfu | 使用過期集在密鑰中使用近似LFU進行驅逐 |
| allkeys-lfu | 使用近似LFU逐出任何鍵 |
| allkeys-random | 在所有key裏隨機回收 |
| volatile-random | 在已經過期的key裏隨機回收 |
| volatile-ttl | 回收已經過期的key，並且優先回收存活時間（TTL）較短的鍵 |
緩存擊穿，緩存穿透，緩存雪崩
緩存擊穿
某一熱點key，洪峯期突然緩存key失效，造成直擊數據庫
解決方案：
1.設置熱點key永不過期 2.增加互斥鎖（拿到鎖的纔有資格去查詢數據庫）
緩存穿透
查詢一個不存的key,導致redis不可用，穿透造成數據庫壓力
解決方案：
1.增加檢驗參數
2.從nigix增加配置項，對單個key每秒訪問的次數超過閥值，就把IP名單拉黑
3.布隆過濾器，提前判斷值存在不存在，有誤差率
4.設置不存在key值，並設置過期的時間。
緩存雪崩
洪峯期大面積緩存key失效或數據庫掛掉，導致海量數據請求去查詢室數據庫
解決方案：
1.批量往redis存數據的時候，key的失效時間設置隨機值，保證在同一時間不會大面積失效
2.集羣部署，均勻的分佈在不同的redis庫中也能避免
3.設置熱點數據永遠不過期，有更新操作更新緩存就好
4.緩存穿透和緩存擊穿都是造成雪崩的前提
5.緩存降級