Redis maxmemory应设为总内存的60%–70%（如8GB机器设5GB），并配合volatile-lru等策略、Hash压缩、BigKey治理，才能避免OOM。
maxmemory 设置多少才不炸内存
单机 Redis 的 maxmemory 不是“填个 80% 物理内存”就完事——它限制的是 Redis 自身的 used_memory，但实际进程占用会更高，因为内存碎片（mem_fragmentation_ratio）和后台持久化（AOF rewrite / RDB fork）都会额外吃掉物理内存。比如你设了 maxmemory 6gb，jemalloc 分配器碎片率到 1.6 时，RSS 可能已逼近 9.6GB，再叠加 AOF 重写临时开销，8GB 服务器大概率触发 OOM Killer。
实操建议：
- 先查服务器总内存：
free -h，确认可用 RAM； -
maxmemory建议设为总内存的 60%–70%（如 8GB 机器设maxmemory 5gb），给系统、其他服务、碎片、fork 留足余量； - 别信“预留 20% 就够”——Debian 上 systemd、rsyslog、sshd、cron 等常驻进程加起来轻松占 800MB+，尤其开了日志轮转或监控 agent；
- 用
CONFIG SET maxmemory 5gb动态调，观察INFO memory中的used_memory_peak和mem_fragmentation_ratio，连续几天都
淘汰策略选错，缓存命中率直接腰斩
设了 maxmemory 却没配 maxmemory-policy？Redis 默认是 noeviction，一满就拒绝写入（返回 (error) OOM command not allowed when used memory > 'maxmemory'.），线上服务瞬间报错。这不是“保守”，是误配。
常见场景与对应策略：
- 纯缓存（商品页、配置项）→ 用
allkeys-lru：无差别淘汰冷数据，简单高效； - 带过期时间的会话/令牌 → 用
volatile-lru：只动你主动设了EXPIRE的 key，避免误删永不过期的配置； - 短时验证码/临时 token →
volatile-ttl：优先清掉马上要过期的，减少无效扫描； - 千万别用
allkeys-random做主缓存——随机删可能刚热起来的 key，命中率波动大，debug 困难。
配置方式：maxmemory-policy volatile-lru 写进 /etc/redis/redis.conf，或运行时 CONFIG SET maxmemory-policy volatile-lru。
Hash 比 String 节省一半内存？得看你怎么用
用 10 万个 user:1:name、user:1:age 这种 String 存用户信息，不如一个 HSET user:1 name Tom age 25 ——但这不是白省的，得满足条件：
- Hash 必须开启 ziplist 编码：检查
hash-max-ziplist-entries（默认 512）和hash-max-ziplist-value（默认 64）； - 单个 field value 长度 ≤ 64 字节，且总 field 数 ≤ 512，Redis 才会把整个 Hash 压成一块连续内存；否则退化为 dict，元数据开销翻倍；
- 用
MEMORY USAGE user:1对比验证：压缩后通常只有非压缩版的 1/3～1/2； - 反例：存一个 2KB 的 JSON 到
HSET user:1 profile "{...}"，value 超限，立马失效，还多了一层 hash 元数据。
BigKey 是隐形内存杀手，别等 OOM 才发现
一个 SET product:1000 "{...2MB JSON...}" 看似只是 2MB，但它会导致：DEL 阻塞主线程超百毫秒、AOF 重写卡顿、主从同步延迟飙升、内存碎片激增。更糟的是，MEMORY USAGE 返回的只是逻辑大小，实际分配可能更大（jemalloc 对齐、指针数组等）。
防 BigKey 的硬约束：
- String 类型 value 严格 ≤ 10KB；
- Hash/List/Set/ZSet 单 key 元素数 ≤ 5000，且单元素 ≤ 1KB；
- 上线前跑一次扫描：
redis-cli --bigkeys（注意：生产环境慎用，会阻塞）； - 业务层拆分：商品详情拆成
HSET product:1000 base price stock+product:1000:desc（单独存长文本）； - 监控告警：对
used_memory_peak_human和instantaneous_ops_per_sec做同比异常检测，BigKey 往往伴随 ops 突降 + 内存尖峰。
真正难的不是算出该设多少 GB，而是让每个 key 都“守规矩”——Schema 约束、上线校验、定期巡检，缺一不可。
