必须显式设置maxmemory才生效，否则Redis持续分配内存致OOM；需同步配置maxmemory-policy（如allkeys-lru），并依据used_memory_rss峰值设定值，重启进程方生效，还需关注内存碎片。
直接改 maxmemory 才算真正生效
Redis 不会自己限制内存用量，必须显式设置 maxmemory，否则它会一直往上涨，直到系统 OOM 或被 kill。这个值不是“建议上限”，而是硬性阈值——一旦 used_memory 触达它，后续写入行为就取决于你配的淘汰策略，而不是继续分配。
- 配置文件里加一行：
maxmemory 300mb（支持kb/mb/gb，不区分大小写） - 别写成
maxmemory 300，缺单位 Redis 会当成字节，等于只给 300 字节，立刻报错 - 如果用
redis-server --maxmemory 300mb启动，记得同时指定配置文件路径，否则其他配置（比如密码、端口）会丢失 - 动态设置可用：
redis-cli CONFIG SET maxmemory 300mb，但重启后失效，仅适合临时调试
maxmemory-policy 不设等于白设 maxmemory
设置了 maxmemory 却没配 maxmemory-policy，Redis 默认是 noeviction：新数据写不进去，直接返回 (error) OOM command not allowed when used memory > 'maxmemory'。这不是“自动清理”，是直接拒绝服务。
- 日常缓存场景推荐
allkeys-lru（全键 LRU）或volatile-lru（仅淘汰带过期时间的键），前者更通用，后者适合严格区分“缓存”和“持久数据” - 如果业务能容忍随机丢数据，
allkeys-random比 LRU 省 CPU，但命中率下降明显 - 千万别在生产环境用
noeviction，除非你确定所有写操作都有容错重试逻辑 - 策略要和
maxmemory-samples配合调优，默认 5 样本够用；压测时发现淘汰不准，可提到 10～15
别忽略内存碎片和真实占用差异
maxmemory 控制的是 Redis 自己统计的 used_memory，但操作系统看到的物理内存（used_memory_rss）往往更高。如果 mem_fragmentation_ratio > 1.5，说明碎片严重，即使 used_memory 还没到 maxmemory，RSS 已经快把机器内存吃光了。
- 用
redis-cli INFO memory | grep -E "(used_memory|used_memory_rss|mem_fragmentation_ratio)"快速检查 - 碎片高常见于频繁写删小对象（比如短 token）、长期运行未重启、使用 libc 分配器；换
jemalloc编译能缓解 -
maxmemory建议按used_memory_rss的峰值来设，而不是看used_memory_human显示的“干净数字” - 300MB 的
maxmemory，实际可能需要预留 400MB+ 物理内存才稳
配置改完不重启，很可能没生效
修改 redis.conf 后只执行 redis-cli CONFIG REWRITE，并不能保证 maxmemory 生效——这个命令只保存运行时通过 CONFIG SET 改过的参数，而 maxmemory 是启动时读取的静态配置，必须重启进程。
- systemd 环境下用
sudo systemctl restart redis，别只 reload - 确认是否生效：重启后立刻跑
redis-cli CONFIG GET maxmemory和INFO memory对比 - 容器部署时，别只改宿主机配置文件却忘了重建镜像或挂载新配置
- 云数据库（如腾讯云 CRS、阿里云 Tair）不开放配置文件修改，得走控制台或 API 设置，且部分策略可能受限
maxmemory、淘汰策略、碎片、监控这四块必须一起看，漏掉任何一块，都可能在某次流量高峰时突然发现缓存全崩了。 
