Redis List数据过长导致内存溢出_使用Redis分片集群与内存淘汰策略-Redis-PHP中文网

redis单个list极少直接导致oom，主因是大量小list堆积或误用作长期存储；应优先通过memory usage查内存、ltrim截断、调优ziplist参数及合理设置淘汰策略来优化。

redis list数据过长导致内存溢出_使用redis分片集群与内存淘汰策略

Redis List过长直接导致OOM？先确认是不是真List撑爆的

Redis内存溢出（OOM）很少由单个List直接引发，更常见的是大量小List堆积、或List被误用作日志/队列且从不清理。Redis本身对单个List长度无硬限制，但每个元素都存字符串对象，总内存 = 元素数量 ×（平均字符串长度 + Redis对象头开销）。若一个List存了500万条1KB消息，仅数据就超5GB，加上指针和编码开销，极易触发maxmemory淘汰或系统OOM。

用DEBUG OBJECT key查List实际内存占用（注意：生产慎用，会阻塞）
用MEMORY USAGE key替代（Redis 4.0+，非阻塞，推荐）
结合INFO memory看used_memory_peak和mem_fragmentation_ratio，判断是缓存膨胀还是内存碎片高

别急着上分片集群——先看List是否真的需要全量保留在Redis里

很多场景下，把日志、事件流、消息队列全塞进List是设计偏差。Redis不是数据库，List也不适合做长期存储。真正该做的，是厘清访问模式：

如果是FIFO队列（如任务分发），用LPUSH+RPOP或BRPOP，消费后自然出队，长度可控
如果是时间窗口聚合（如最近1小时点击），用LPUSH+LTRIM主动截断，例如LPUSH logs "event" ; LTRIM logs 0 9999只留最新1万条
如果是归档类数据（如用户操作历史），应写入MySQL/Elasticsearch，Redis只存最近N条摘要，用LSET或LREM配合定时清理

必须用List存大量数据？那就配对使用内存淘汰策略+合理编码

List在Redis中默认使用ziplist编码（紧凑存储），但当元素数超过list-max-ziplist-entries（默认512）或任一元素长度超过list-max-ziplist-value（默认64字节）时，会转为linkedlist（内存翻倍甚至更多）。所以调参比换集群更立竿见影：

Redis Skill - 高性能缓存管理

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

下载

若元素短且固定（如用户ID、状态码），调大list-max-ziplist-value到256，保持ziplist编码
若元素多但总量可控（如每List≤1万条），调大list-max-ziplist-entries到2048，避免过早转链表
淘汰策略选allkeys-lru或volatile-lru，但注意：List本身不支持TTL，得靠给整个key设过期（EXPIRE），否则淘汰无效

示例配置（redis.conf）：
list-max-ziplist-entries 2048
list-max-ziplist-value 256
maxmemory-policy allkeys-lru