单个List过长会导致Redis并发瓶颈，因其LPOP、RPOP、LRANGE等操作时间复杂度为O(N)，N为List长度；在单线程模型下，一个慢命令会阻塞后续所有对该key的操作，引发全局延迟。
为什么单个List过长会导致并发操作瓶颈
Redis的LPOP、RPOP、LRANGE等List操作在底层是O(N)时间复杂度（N为List长度），当List包含几十万甚至上百万元素时，一次LRANGE 0 -1可能阻塞主线程数十毫秒；更关键的是，所有对同一个key的写/读/删操作都串行排队——哪怕只是LLEN或LTRIM，也会被前面的大操作拖住。这不是吞吐量问题，是单线程模型下“一个慢命令卡住全队列”的本质限制。
List分片的核心原则：避免跨分片逻辑耦合
分片不是简单地把一个大List拆成多个小List就完事。关键在于业务语义是否允许“无序”“可丢失”“不强一致”。比如消息队列场景，只要保证每条消息最终被消费一次，顺序和分片归属可以弱化；但如果是订单流水号生成，则不能分片。
- 用
key:{shard_id}代替单个key，例如order_queue:0、order_queue:1…order_queue:7 - 分片数建议取2的幂（如4/8/16），方便用
hash(key) % N做一致性哈希，后续扩容时迁移成本可控 - 客户端必须自己维护分片路由逻辑，Redis本身不感知分片关系；不要依赖
CLUSTER KEYSLOT去算，那是集群槽位，不是业务分片
如何安全地从单List迁移到分片List
直接改代码+清空原List会丢数据。必须边写边读、平滑过渡：
- 上线前先启用双写：新消息同时
LPUSH到原order_queue和某个分片order_queue:{n}（n由哈希决定） - 消费者端改为轮询所有分片List（用
BRPOP order_queue:0 order_queue:1 ... order_queue:7 0），并继续消费原order_queue - 监控原List的
LLEN降到0后，停掉双写，下线原key - 注意：
BRPOP多key时，返回格式是[key, value]，需解析第一个字段判断来源分片
分片后仍要警惕的隐藏陷阱
分片解决的是“单点阻塞”，但没解决“整体负载不均”和“运维复杂度上升”：
- 如果所有请求都哈希到同一个分片（比如用户ID全是偶数），那个分片List依然会膨胀——必须检查哈希函数分布，必要时加随机盐（如
hash(user_id + salt)） -
DEL单个分片List很快，但想清空全部分片？得发N次DEL命令，别用KEYS order_queue:*，它会阻塞且不准 - 监控粒度要下沉到每个分片，而不是只看总QPS；
redis-cli --stat看不到分片差异，得靠INFO commandstats里查各cmdstat_lpush的调用频次
分片不是银弹。真正难的不是拆，而是确认哪些业务逻辑能接受“消息乱序”“分片间不可原子性”“运维面变宽”——这些权衡点，往往在第一次压测时才暴露出来。
