一、Redis 的持久化機制有哪些？**

Redis 提供兩種主要的持久化機制：

? RDB（Redis DataBase）快照持久化

• 定期將 Redis 中的數據以“快照”的形式寫入磁盤（生成 .rdb 文件）。
• 啟動 Redis 時會加載 .rdb 文件恢復數據。
• 觸發方式：
  • 手動執行 SAVE 或 BGSAVE 命令。
  • 根據配置（如 save 900 1）定期自動觸發。
• 優點：
  • 恢復速度快，占用磁盤小。
• 缺點：
  • 異常宕機可能會丟失最近修改的數據（非實時）。

? AOF（Append Only File）追加日志持久化

• 將每次寫操作（如 SET, HSET, INCR 等）以日志方式記錄到 .aof 文件中。
• 啟動 Redis 時重放 .aof 日志以恢復數據。
• 刷新策略：
  • always：每次操作都寫入磁盤，最安全但性能差。
  • everysec（默認）：每秒寫一次，性能與安全的折中。
  • no：完全由操作系統控制刷盤時機。
• 優點：
  • 持久化更可靠，可恢復最近的數據。
• 缺點：
  • 文件比 RDB 大，恢復速度慢。

? 混合持久化（Redis 4.0+）

• 同時使用 AOF 和 RDB 優勢。
• RDB 保存大部分數據，AOF 記錄最后的增量變化。
• 適用于既要快速恢復也要數據盡量完整的場景。

總結一張圖（文字版）：

機制類型	描述	優缺點
RDB	快照形式保存數據到硬盤	快速恢復、可能丟數據
AOF	每次寫操作記錄日志	數據更完整、文件大
主從復制	主節點寫、從節點讀	高可用、讀寫分離
過期刪除	定時 / 惰性 / 定期	兼顧性能和內存釋放

🏢 實際大廠方案舉例（簡化版）

公司/場景	持久化策略	說明
阿里巴巴	關閉持久化（緩存場景）	Redis 宕機自動重建緩存，不做持久化
字節跳動	AOF everysec + RDB 混合	用于關鍵服務，定期冷備 RDB
京東	主從復制 + AOF + 異地災備	高可用架構，主機持久化 AOF，從節點只讀
騰訊云 Redis	默認開啟 AOF everysec + RDB	提供用戶可選關閉
美團	自研容器化 Redis + AOF everysec	使用混合持久化恢復用戶 session 數據

🧠 總結建議

需求類型	推薦持久化方案	理由
緩存為主、能容忍丟失	不持久化	最佳性能
數據重要、不能丟	AOF everysec + RDB	高可靠性恢復
啟動速度要求高	RDB + 備份定期觸發	恢復快，節省磁盤
高可用架構	主從 + 哨兵 + 持久化	容災能力強

---

二、Redis 主從復制的實現原理

Redis 主從復制（Replication）用于實現讀寫分離、數據備份和高可用架構。

實現流程：

1. 從節點發送 SYNC 請求：
   • 啟動后通過配置或命令（如 SLAVEOF）向主節點發起復制請求。
2. 主節點執行 RDB 快照：
   • 執行 BGSAVE 生成 RDB 快照，將數據發送給從節點。
3. 從節點加載快照：
   • 清空原有數據后加載主節點傳過來的 RDB 文件。
4. 復制增量寫命令：
   • 主節點在 RDB 傳輸完后將期間的寫命令緩存在 replication backlog buffer 中，一并發給從節點。
   • 此后主節點每執行一次寫命令就同步給所有從節點。

特點：

• 異步復制： 默認是異步，但 Redis 6.0 起支持部分同步機制。
• 斷線重連：
  • 若斷線，從節點嘗試“部分重同步”（基于 runId 和 offset）。
  • 不行時才進行完整的 RDB + AOF 同步。

---

三、 Redis 數據過期后的刪除策略

Redis 為了釋放內存，提供了三種刪除過期 key 的策略：

? 定時刪除（主動刪除）

• 給 key 設置了過期時間后，Redis 會為其設置一個定時器，到時間自動刪除。
• 優點： 內存及時釋放。
• 缺點： 會影響 CPU 性能（每個 key 都定時檢查代價高）。

? 惰性刪除（被動刪除）

• 客戶端訪問某個 key 時，Redis 會先檢查是否過期，若過期就刪除。
• 優點： 不浪費 CPU。
• 缺點： 若沒有訪問，過期 key 會長期占內存。

? 定期刪除（定期抽樣刪除）

• Redis 會周期性（默認 100ms）隨機抽取部分 key 進行過期檢查并刪除。
• 優點： 兼顧性能與內存控制。
• 缺點： 某些 key 可能在長時間內未被檢查到，造成內存浪費。

---

四、淘汰策略

策略名稱 策略說明 適用場景
noeviction 不淘汰，直接拒絕寫入操作（默認策略） 數據不能丟的場景（如金融）
allkeys-lru 所有鍵中，淘汰最久未使用的（Least Recently Used） 通用緩存、Web緩存
volatile-lru 只在設置了過期時間（TTL）的鍵中，淘汰最久未使用的 局部熱數據緩存
allkeys-random 所有鍵中隨機淘汰 對訪問頻率無強依賴的緩存
volatile-random 只在設置了過期時間的鍵中隨機淘汰 弱一致性、低優先級緩存
volatile-ttl 只淘汰 TTL 剩余時間最短的 key（即快要過期的 key） 想優先保留長期 key

五、LUR/隨機策略內部機制

? allkeys-lru 是最常用的策略
Redis 內部維護了訪問信息（LRU/approximate LRU），采用 采樣+近似LRU算法：

抽樣 5 個 key（默認），比較其訪問時間，淘汰最久未使用的。
可以通過 maxmemory-samples 設置樣本數（越大越精準，但耗 CPU）：

六、實踐建議

💡 推薦策略組合：
場景 推薦配置
通用緩存 allkeys-lru（經典）
只緩存部分熱點數據 volatile-lru + 設置 TTL
極限性能下，快速釋放空間 allkeys-random
數據敏感/不能自動淘汰 noeviction（程序層判斷+降級處理）