maxmemory无固定值，须据真实内存余量、访问特征及业务容忍度动态设定：先查used_memory和mem_fragmentation_ratio（>1.5需警惕碎片），再结合系统可用内存（预留OS 512MB+其他进程+aof/slave缓冲），建议maxmemory≤系统可用内存×0.7且≤used_memory_peak×1.3；淘汰策略须匹配key过期设置，volatile类策略要求所有缓存key带EX/PX，否则退化为noeviction导致OOM；调优后须监控evicted_keys与hit_rate，并用--bigkeys/--hotkeys验证热点分布以校准策略。
没有“最合适”的固定值，maxmemory 必须基于你的真实内存余量、数据访问特征和业务容忍度来定，硬套 4GB 或 “总内存的 70%” 会直接导致频繁淘汰或 OOM。
怎么算出安全的 maxmemory 上限？
不能只看 Redis 自身 used_memory，得留足系统级缓冲：
- 用
redis-cli INFO memory查当前used_memory和mem_fragmentation_ratio（若 >1.5，说明内存碎片严重，实际物理内存占用比指标高） - 用
free -h或cat /proc/meminfo看系统剩余可用内存，减去：OS 预留（至少 512MB）、其他进程常驻内存、Redis 的aof_buffer和slave_buf（主从场景下可能额外吃 1–2GB） - 最终留给 Redis 的
maxmemory建议 ≤ 系统可用内存 × 0.7，且必须 ≤used_memory_peak× 1.3（防止突发写入打满）
淘汰策略选错，再大的 maxmemory 也白搭
策略和 maxmemory 是绑定生效的，不是独立配置：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
volatile-lru或volatile-ttl要求你所有缓存 key 都带EX/PX，否则淘汰范围为 0 —— 这时即使maxmemory设再小，也会退化成noeviction，写入直接报(error) OOM command not allowed when used memory > 'maxmemory' -
allkeys-lfu在 Redis 4.0+ 可用，但会额外记录访问频次，maxmemory_samples默认 5，若设太高（如 100）会显著增加 CPU 开销，尤其在每秒数千写入的场景 - 如果业务中大量 key 没设过期时间（比如持久化配置项），又误配了
volatile-*策略，等于关闭了淘汰能力 —— 此时maxmemory就只是个摆设
线上调优必须验证的两个动作
光改配置不观察，等于没调：
- 改完后，持续监控
evicted_keys和expired_keys的每秒增量：若evicted_keys暴涨但hit_rate（keyspace_hits / (keyspace_hits + keyspace_misses)）骤降，说明淘汰太激进，要么调大maxmemory，要么换allkeys-lfu替代allkeys-lru - 用
redis-cli --bigkeys和redis-cli --hotkeys（Redis 4.0+）确认真实热点分布 —— 如果 95% 请求集中在 5% 的 key 上，allkeys-lfu明显优于allkeys-lru；反之，若访问时间局部性强（比如用户 session 按登录时间集中失效），volatile-ttl更稳
真正卡住人的从来不是数字本身，而是你是否清楚每个 key 的生命周期、访问 pattern 和系统内存真实水位。一个没设过期时间的 SET 命令，可能让整个 maxmemory 配置失效。
