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 可能先杀进程。
