當Redis的used_memory_peak_perc（當前內存占歷史峰值的百分比）和used_memory_dataset_perc（數據集內存占比）均超過90%時，可能引發以下問題及風險：

---

一、used_memory_peak_perc > 90% 的影響

1. 內存交換風險（Swap）

   • 若當前內存使用量（used_memory）接近歷史峰值（used_memory_peak），且系統物理內存不足，操作系統會將部分內存數據交換到磁盤（Swap），導致性能急劇下降。
   • 表現：Redis響應延遲顯著增加，吞吐量降低，甚至出現超時或連接中斷。

2. 持久化操作風險

   • 若此時觸發RDB快照或AOF重寫，Redis會fork子進程復制內存數據。若物理內存不足，可能導致：
     • 內存溢出（OOM）：進程被系統強制終止。
     • 數據丟失：持久化失敗導致未保存的數據在崩潰時丟失。

3. 內存碎片加劇

   • 頻繁的內存分配與釋放可能使內存碎片率（mem_fragmentation_ratio）升高，導致實際可用內存減少，進一步加劇內存壓力。

---

二、used_memory_dataset_perc > 90% 的影響

1. 內存管理余量不足

   • 數據集占用總內存比例過高，意味著Redis的管理開銷內存（如緩沖區、元數據） 剩余空間極小。可能導致：
     • 寫入失敗：新數據無法分配內存，觸發淘汰策略或直接拒絕寫入（取決于maxmemory-policy配置）。
     • 復制/客戶端緩沖區溢出：主從復制或客戶端輸出緩沖區因內存不足中斷，影響高可用性和請求處理。

2. 潛在性能瓶頸

   • 內存碎片化可能增加，尤其是存儲大量小對象或頻繁更新數據時，進一步降低內存利用率。
   • 若數據集接近maxmemory限制，頻繁的鍵淘汰（如LRU/LFU策略）會增加CPU開銷。

---

三、優化建議

1. 控制內存使用量

   • 設置合理的maxmemory并配置淘汰策略（如allkeys-lru），避免內存耗盡。
   • 對大Key進行拆分（如Hash分片），或使用壓縮數據結構（如ziplist）。

2. 監控與調優

   • 定期檢查mem_fragmentation_ratio：若 >1.5，重啟實例或執行MEMORY PURGE（需Redis 4.0+）以清理碎片。
   • 啟用監控告警，關注used_memory_rss（物理內存占用）和Swap使用情況。

3. 持久化策略調整

   • 避免在內存高峰期觸發RDB/AOF操作，或預留足夠內存供fork使用（通常需預留當前內存的2倍）。
   • 對于高寫入場景，優先使用AOF的everysec配置而非always，減少磁盤壓力。

4. 架構擴展

   • 采用集群分片（Redis Cluster）分散內存壓力。
   • 使用讀寫分離或緩存預熱，降低單節點負載。

---

關鍵指標關系總結

指標	健康范圍	超過90%的風險場景
used_memory_peak_perc	<80%	內存交換、持久化失敗、OOM
used_memory_dataset_perc	70%~90%	寫入拒絕、緩沖區溢出、碎片化加劇

---

若需進一步診斷，可通過INFO MEMORY命令獲取詳細數據，并結合redis-cli --bigkeys分析大Key分布。長期高內存占用建議升級實例規格或優化業務邏輯。