大集合导致Redis阻塞需改用分片Key或ZSET分页：将大Set/Hash按ID哈希拆为多个子Key（如user:ids:0a），读取时遍历合并；或改用ZSET配合ZRANGEBYSCORE游标分批读取，避免SMEMBERS/HGETALL全量拉取阻塞主线程。
大集合导致Redis阻塞怎么办
ThinkPHP 里用 Redis 存大 Set 或 Hash（比如用户标签、权限列表、商品类目树），一旦成员超 10 万，SMEMBERS、HGETALL 这类全量拉取命令就会卡住 Redis 主线程，CPU 突增、请求超时、集群节点失联——这不是缓存配置能调出来的，得从数据结构和访问方式上拆。
用分片 Key 替代单个大 Key
别把所有用户 ID 塞进一个 user:all:ids，改用哈希后缀分片：
- 写入时按用户 ID 哈希到 N 个子 Key：例如
user:ids:0a、user:ids:1f（其中0a来自substr(md5($uid), 0, 2)） - 读取时遍历全部分片再合并：
foreach (['0a','1f','2c'] as $suffix) { $ids = $redis->smembers("user:ids:{$suffix}"); } - 避免用随机后缀（如
:rand(0,9)），否则无法保证同一用户归属稳定，导致查漏或重复 - 分片数建议 16–256 个，太少起不到分散效果，太多增加客户端聚合开销
改用有序集合 + 分页游标读取
如果业务本质是「按某种顺序批量获取」（如最新 1000 个活跃用户），别用 Set，换成 ZSET 并配合 ZRANGEBYSCORE：
- 存的时候带时间戳分数：
$redis->zAdd('user:active', time(), $uid) - 读的时候用游标分批：
$redis->zRangeByScore('user:active', '-inf', '+inf', ['limit' => [0, 500]]) - 下一批传上次最后的 score + uid 组合作为
min，避免OFFSET性能退化 - 注意：score 精度要够（微秒级），否则同分排序不稳定
ThinkPHP 中如何安全封装分片逻辑
别在每个控制器里手写哈希和循环，统一收口到模型或缓存服务中：
立即学习“PHP免费学习笔记（深入）”；
- 在
app/common/service/RedisShard.php定义getShardKey($baseKey, $id)，确保所有地方哈希逻辑一致 - 用
Cache::store('redis')->handler()拿到底层 Redis 实例，绕过 ThinkPHP 缓存层对大 Key 的无脑序列化 - 禁用
Cache::get('user:ids')这种直接读大 Key 的写法；强制走分片方法UserCache::getAllIds() - 上线前必须验证分片一致性：随机选 100 个用户 ID，确认它们在分片写入后能被完整读出，且无重复、无遗漏
最易被忽略的是：分片后没同步清理逻辑。删用户时，必须根据哈希规则定位到对应子 Key 执行 SREM，而不是清空整个大 Key——否则残留数据会越积越多，最终又变回热 Key。
