本文介紹了 Azure Cache for Redis 中記憶體管理的最佳做法。
選擇正確的驅逐策略
選擇適用於您應用程式的收回原則。 Azure Cache for Redis 的預設策略為 volatile-lru，這意味著只有使用 EXPIRE 等命令設置了存留時間 （TTL） 值的鍵才有資格逐出。 如果沒有鍵具有TTL值，則系統不會驅逐任何鍵。 如果您希望系統在記憶體壓力下允許逐出任何鍵，請考慮該 allkeys-lru 策略。
設置金鑰到期日期
由於記憶體壓力而導致的逐出可能會導致伺服器負載增加。 在密鑰上設置過期值以主動刪除金鑰，而不是等到出現記憶體壓力。 有關更多資訊，請參閱 Redis EXPIRE 和 EXPIREAT 命令的文件。
最小化記憶體分散
較大的鍵值可能會在逐出時使記憶體碎片化，並可能導致高記憶體使用率和伺服器負載。
監視記憶體使用量
監控記憶體使用方式 以確保您不會耗盡記憶體。 創建警報 ，讓您有機會在問題發生之前擴展緩存。
設定您的 maxmemory-reserved 設定
配置 maxmemory-reserved 設置 以最大限度地提高系統回應能力。 對於寫入密集型工作負載，或者如果您在緩存中存儲 100 KB 或更大的值，則足夠的預留設置尤其重要。
該
maxmemory-reserved設置配置為非緩存作（例如故障轉移期間的複製）保留的內存量（以集群中每個實例的 MB）為單位。 設定此值可讓您在負載變動時具有更一致的 Redis 伺服器體驗。該
maxfragmentationmemory-reserved設置配置為容納記憶體碎片而保留的內存量（以集群中每個實例 MB 為單位）。 當您設定此值時，如果快取已滿或接近全滿且分散比率很高，則 Redis 伺服器體驗會更一致。
當為這些作預留記憶體時，它不可用於存儲緩存的數據。 預設情況下，在建立快取時，大約 10% 的可用記憶體保留給 maxmemory-reserved，另外 10% 保留給 maxfragmentationmemory-reserved。 如果您的寫入負載較重，則可以增加預留量。
允許的範圍 for maxmemory-reserved 和 for maxfragmentationmemory-reserved 為 10%-60% maxmemory。 如果您嘗試將這些值設定為低於 10% 或高於 60%，則會重新評估，並將其設定為最小值 10% 和最大值 60%。
當您向上或向下調整快取時，maxmemory-reserved 和 maxfragmentationmemory-reserved 設定都會自動依快取大小的比例調整。 例如，如果在 maxmemory-reserved 6 GB 快取上設置為 3 GB，並且您擴展到 12 GB 快取，則設置將在擴展期間自動更新為 6 GB。 如果縮小規模，則情況正好相反。
考慮更改 maxmemory-reserved or maxfragmentationmemory-reserved 記憶體預留值如何影響已在運行的包含大量數據的緩存。 例如，如果您有一個 53 GB 的緩存，並且保留值設置為最小值 10%，則系統的最大可用記憶體約為 42 GB。 如果當前used_memory值 或 used_memory_rss 值大於 42 GB，則系統必須逐出數據，直到兩者used_memoryused_memory_rss均低於 42 GB。
收回會增加伺服器負載並讓記憶體過於分散。 如需 used_memory 或 used_memory_rss 等快取計量的詳細資訊，請參閱建立您自己的計量。
注意
使用 Azure PowerShell、Azure CLI 或 REST API 以程式設計方式擴展或縮減緩存時，更新請求中將忽略任何包含 maxmemory-reserved 的設置 maxfragmentationmemory-reserved 或設置。 只會接受您的縮放變更。 您可以在擴展作完成後更新記憶體設置。