lrange大偏移量会阻塞redis，因其list底层为双向链表或ziplist，需从头遍历n次（n为偏移量）才能定位，时间复杂度o(n)而非o(1)，导致主线程卡死、接口超时；应改用分片key或sorted set优化。

别用 LRANGE key 0 -1 全量读，也别用 DEL 直删百万元素的 List——这两步都会让 Redis 线程卡死几秒到几十秒，业务请求直接超时。

为什么 LRANGE 大偏移量会阻塞

Redis 的 List 底层是双向链表（小数据）或压缩列表（ziplist），LRANGE 查第 10 万条，就得从头遍历 10 万次节点。不是 O(1)，是 O(n)；n 是偏移量，不是总长度。哪怕只读不写，百万级 List 上执行 LRANGE key 999999 999999 也会卡住主线程。

• 常见错误现象：redis-cli 命令 hang 住、应用接口响应时间突增至 5s+、监控显示 latency 飙升
• 容易被忽略的坑：很多分页工具类把 page=5000&size=20 自动转成 start=99980，再喂给 LRANGE —— 这等于在逼 Redis 做线性扫描
• 性能影响：单次 LRANGE 耗时随偏移量线性增长，100 万元素下偏移 50 万，实测常超 800ms（普通 SSD + 4 核实例）

用分片 Key 替代单一大 List

核心是把逻辑上“一个列表”拆成多个物理 Key，每个控制在 1000–5000 元素以内。写入走 RPUSH 到当前活跃分片，读取时先查分片索引再并发 LRANGE。

Redis Skill - 高性能缓存管理

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

下载

• 分片命名示例：user:123:msgs:202605（按月）、user:123:msgs:seq:00001（按序号段）
• 分片映射存哪？用 Hash：HSET user:123:msg:shards 202605 "user:123:msgs:202605"，避免每次都要猜 Key
• 删除旧数据用 DEL 整 Key，比 LTRIM key 0 999 快得多 —— DEL 是 O(1)，LTRIM 对百万 List 是 O(n)
• 粒度别太细：单用户分片超过 50 个，Key 数暴涨，影响集群 slot 迁移和 KEYS 类命令扫描效率

什么情况下该换 Sorted Set

如果你的查询模式天然带顺序（如“最新 20 条”“某时间段消息”“按权重排序”），ZSET 比 List 分片更省事，底层是跳跃表，ZRANGE、ZRANGEBYSCORE 都是 O(log N)。

• 插入示例：ZADD user:123:timeline 1748392000 "msg_id:abc"（时间戳作 score）
• 取最新 20 条：ZREVRANGE user:123:timeline 0 19，毫秒级返回
• 注意点：ZADD 同 member 会覆盖 score，若业务要求唯一性，得加前缀（如 "msg_id:abc:1748392000"）
• 别犯懒：ZRANGE key 0 -1 仍是 O(N)，哪怕比 List 快，也不该全量扫

批量操作必须走 Pipeline

插入或删除百万级 List 元素时，不用 Pipeline 就等于主动制造阻塞。单条 RPUSH 或 DEL 带来的是网络往返 + Redis 单线程串行执行，Pipeline 把命令攒批发，一次 RTT 解决。

• 插入示例（Python）：pipeline.rpush('list_key', *batch_items)，每 1000–5000 条 execute() 一次
• 删除大 List：先用 SCAN 渐进式遍历 key，再用 Pipeline 批删 —— 别直接 DEL，否则过期触发同步删除可能卡住
• 客户端陷阱：Jedis 的 del(String... keys) 看似批量，但仍是服务端逐个执行，不等价于 Pipeline

真正难的不是选技术，而是判断“这个列表到底需不需要随机访问”。如果只是队列消费（RPOP/BRPOP），List 本身没问题；一旦出现分页、跳读、范围查，就该立刻切分或换结构——拖得越久，重构成本越高。