Redis单个List极少直接导致OOM，主因是大量小List堆积或误用作长期存储；应优先通过MEMORY USAGE查内存、LTRIM截断、调优ziplist参数及合理设置淘汰策略来优化。
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 缓存和数据结构管理技能。通过自然语言操作 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 2048list-max-ziplist-value 256maxmemory-policy allkeys-lru
分片集群不是银弹——List跨节点操作根本不可行
Redis Cluster按key的CRC16值哈希分片，而List所有操作（LPUSH、LLEN、LRANGE）都要求key落在同一节点。这意味着你无法把一个超长List“拆开”存在多个节点上——它天然就是单点结构。强行分片只会带来两个后果：
- 业务层自己分片（如
logs:shard:0、logs:shard:1），但LLEN、LRANGE等需客户端聚合，逻辑复杂且无法原子执行 - 改用其他中间件（如Codis）或自研Proxy，但维护成本陡增，且仍绕不开单key内存上限
真正需要集群的，是key数量爆炸（千万级不同key），而不是单个key体积过大。一个存了200万条的List，哪怕放在单节点32GB内存实例上，也比拆成20个集群节点更稳、更快、更易监控。
