redis写入报oom是因默认noeviction策略拒绝写入，需配置maxmemory-policy（如allkeys-lru）并调优maxmemory-samples；volatile类策略要求键设ttl，内存碎片>1.5或峰值过高也会触发oom。
写入直接报 OOM 错误，说明没开淘汰策略
Redis 默认是 noeviction 策略，内存一满就拒绝所有写命令，返回 (error) OOM command not allowed when used memory > 'maxmemory'。这不是 bug，是设计行为——它不会自动删数据，只报错。
临时救急：立刻执行 redis-cli config set maxmemory-policy allkeys-lru（缓存场景通用）或 volatile-lru（只淘汰带 EX/EXPIRE 的键）。该命令即时生效，无需重启，但重启后失效，后续得改 redis.conf 固化。
- 别用
allkeys-random或volatile-random—— 完全随机删，可能刚写入的热点数据就被干掉 - 别盲目设
maxmemory 0—— 这等于放弃内存控制，服务器可能被 Redis 吃光内存后触发系统级 OOM Killer，直接 kill 进程 - 确认是否真设置了
maxmemory：如果值是0（未限制），那报 OOM 就不合理，得查是不是内存碎片或客户端连接数爆了
用了淘汰策略还写不进，大概率是 LRU/LFU 不够准
Redis 的 allkeys-lru 和 volatile-lfu 都是近似算法，不是精确追踪每个 key 的访问时间或频次。它默认只采样 5 个 key 做比较，容易误判——比如某个冷 key 刚好被采样到，而真正热点的 key 没被扫到，结果删错了。
调优方法：增大采样数，提升淘汰精度：
- 执行
redis-cli config set maxmemory-samples 10（支持 1–255，建议 10–20） - 注意：采样数越高，每次淘汰时 CPU 开销越大，高并发下可能轻微影响吞吐
-
allkeys-lfu在 Redis 4.0+ 才支持，且需确保业务确实存在明显访问频次差异；如果访问模式接近均匀，lfu反而不如lru稳定
volatile-* 类策略失效，往往因为键根本没设过期时间
volatile-lru、volatile-ttl 这类策略只对设置了 TTL 的 key 生效。如果你的数据全是永久存储（比如用 SET user:1001 "xxx" 而没加 EX），那这些策略等于没开——内存满了照样报 OOM。
检查方式：
- 用
redis-cli info keyspace看各数据库中expires字段是否为 0 - 抽样查几个 key：
ttl keyname，返回-1表示永不过期，-2表示 key 不存在 - 如果是缓存场景，必须统一加过期时间；哪怕只是
EX 3600，也能让volatile-*策略真正起作用
内存明明没超限，却报 OOM？先看碎片和峰值
info memory 输出里的 used_memory 是当前用量，但真正卡住你的可能是 used_memory_peak 或 mem_fragmentation_ratio。
-
mem_fragmentation_ratio > 1.5：说明内存碎片严重，操作系统给 Redis 分了 2GB 物理内存，但 Redis 实际能用的连续块可能只剩 1.2GB，导致写入失败 -
used_memory_peak远高于used_memory：说明之前有瞬时大写入（如批量导入），峰值冲高后虽回落，但碎片残留，仍影响新分配 - 临时缓解：执行
redis-cli memory purge（Redis 4.0+），主动整理碎片（注意：该命令会短暂阻塞主线程） - 长期方案：在
redis.conf中开启activedefrag yes，让 Redis 后台自动做碎片整理
淘汰策略本身不解决碎片问题，但它和碎片共同决定了你能不能继续写入——策略选得再准，内存没法分配，照样 OOM。
