Redis单线程模型导致大String操作阻塞全局：SET/GET/DEL 1MB以上String会同步占用主线程数百毫秒，使所有请求排队；UNLINK可异步删除避免阻塞；官方建议单value控制在100KB内，超限应序列化压缩分片或改用S3等专用存储。
因为 Redis 单线程处理命令，一个超大 String 的读写或删除会独占主线程数百毫秒甚至秒级，期间所有其他请求全部排队等待。
为什么 SET/GET 一个大 String 会卡住整个 Redis？
Redis 处理每个命令都是串行的，SET 10MB 数据时，主线程要完成：内存分配、数据拷贝、计算 CRC（如果启用了 RDB/AOF）、网络发送响应 —— 这些全在单线程里同步做。实测中，5MB String 的 GET 在普通机器上常耗时 80~200ms；10MB 就很容易破 500ms。这不是“慢”，是“阻塞”：这期间新进来的 INCR、HGET、甚至 PING 全部挂起。
- 客户端表现就是大量
JedisConnectionException或TimeoutException - 监控上看到
latency突增，instantaneous_ops_per_sec断崖下跌 - 不是带宽瓶颈，而是主线程被绑死 —— 千兆网卡也救不了
DEL 大 String 比读写更危险？
很多人以为删掉就完了，其实 DEL 一个大 String 同样同步释放内存，耗时和 GET 接近甚至更长（尤其碎片多时）。而 UNLINK 才是正确选择：它立刻断开 key 引用，把内存回收扔给后台线程异步做。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
DEL：同步，阻塞，适用于 KB 级小值 -
UNLINK：非阻塞，Redis 4.0+ 支持，应作为大 key 删除的默认操作 - 注意：
UNLINK不保证立即释放内存，但能保住主线程不卡
10MB 是分水岭吗？还是更早就要干预？
别等 10MB —— 实际业务中，超过 1MB 的 String 就该警惕。Redis 官方建议把单个 value 控制在 100KB 以内，这是兼顾吞吐与稳定的经验阈值。
- 1MB
String在 QPS 500+ 场景下，一次GET就可能拖垮平均延迟 - 网络层压力：1MB × 100 QPS = 100MB/s，轻松打满千兆网卡
- 更隐蔽的问题：RDB fork 时，大
String会让 copy-on-write 开销剧增，导致 bgsave 延迟飙升
真正该做的不是“怎么扛住大 String”，而是“怎么不让它存在”
把大对象硬塞进 String 是设计误用。Redis 的 String 适合存 token、计数器、序列化后的短结构体，不是文件柜。
- 超过 100KB 的对象，优先考虑序列化压缩（如
zlib）后分片存成多个 key，用MGET并行取 - 1MB+ 的内容，直接退到 S3 / 对象存储 + Redis 存 URL，这才是合理分工
- 千万别依赖所谓“驱动自动压缩”——
redis-cli --compress不影响存储，多数客户端库压根没实现传输层压缩
阻塞不是配置调优能解决的，是数据模型越界了。看到 redis-cli --bigkeys 报出 Biggest string found，第一反应不该是加内存，而是拆、移、弃。
