redis内存配置需据服务器角色设定：单机独占型可配物理内存80%～90%，混部型限40%～60%，集群分片型单节点建议≤12gb；须结合淘汰策略预留弹性空间，并通过info memory实时监控碎片率、峰值与驱逐量，动态校准。

子网划分本身不直接影响 Redis 内存配置，它属于网络层规划（如隔离缓存节点、控制流量路径、提升安全性），而 Redis 内存比例是主机资源分配问题。真正需要关注的是：在已部署 Redis 的服务器（物理机或虚拟机）上，如何为其分配合理的内存份额——这个比例必须结合子网内整体架构来定，比如是否独占机器、是否与数据库/应用共存、是否启用集群分片等。

看服务器角色再定内存上限

同一子网中，Redis 节点的部署模式决定内存策略：

• 单机独占型（子网内该服务器只跑 Redis，无其他关键服务）：可设为物理内存的 80%～90%，例如 32GB 机器配 maxmemory 28gb；仍需预留至少 2～4GB 给系统缓冲、内核、jemalloc 分配器开销及突发连接缓冲区。
• 混部型（Redis 与 MySQL、Nginx 或业务应用同机部署）：严格限制在物理内存的 40%～60%，并用 cgroup 或容器内存 limit 硬隔离，避免互相挤占。例如 16GB 机器，Redis 最多配 maxmemory 8gb，其余留给数据库 buffer pool 和应用堆内存。
• 集群分片型（子网内多台 Redis 实例组成 Cluster 或主从组）：每节点按数据规模预估，总缓存容量 = 单节点 maxmemory × 主节点数；建议单节点不超过 12GB（避免 RDB/AOF fork 压力过大），大容量场景优先横向扩容而非单机加内存。

结合淘汰策略反推安全余量

内存不是“填满即止”，要为淘汰机制留出弹性空间：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 若使用 allkeys-lru 或 volatile-lfu：实际数据量建议控制在 maxmemory 的 70%～85% 以内，避免频繁触发淘汰影响延迟。
• 若使用 volatile-ttl（如会话缓存）：因 TTL 集中过期可能引发瞬时写压力，建议预留 20% 缓冲，防止 mem_fragmentation_ratio 突破 1.5。
• 禁用淘汰（noeviction）时：maxmemory 必须大于峰值数据量 + 客户端缓冲区（client-output-buffer-limit）+ 复制积压区（repl-backlog-size，建议调至 128MB 起）+ AOF 缓冲，否则写操作直接报错。

监控驱动的动态校准

静态配置需配合实时指标持续验证：

• 定期执行 redis-cli info memory，重点关注：
  used_memory_human（当前数据占用）
  mem_fragmentation_ratio（理想值 1.0～1.5；＞1.5 表示碎片高，需重启或启用 activedefrag yes）
  used_memory_peak_human（历史峰值，用于上调 maxmemory 的依据）
• 若 evicted_keys 持续增长，说明内存不足或淘汰策略不匹配，应先检查访问模式（是否突发热点？是否大量短 TTL 键？），再调整比例或策略。
• 子网级可观测性：通过 Prometheus + Redis Exporter 汇总所有节点的 redis_memory_used_bytes / redis_memory_max_bytes 比率，设定告警阈值（如 >85% 持续 5 分钟），自动触发扩容或限流。

单位与配置落地要点

避免常见低级错误：

• 配置文件中写 maxmemory 12g（推荐），别写 maxmemory 12884901888（易出错且难维护）；单位不区分大小写，但统一用小写更稳妥。
• 临时修改用 config set maxmemory 12gb 后，务必同步更新 redis.conf，否则重启失效。
• 容器化部署时，在 docker run 或 k8s resources.limits.memory 中设置内存上限，并确保其 ≥ Redis 的 maxmemory，否则 OOM Killer 可能先杀进程。