Redis中String类型存取大对象为什么-原因分析和处理思路

Redis要先对准具体问题，重点落在为什么 SET/GET 一个大 String 会卡住整个 Redis？、DEL 大 String 比读写更危险？、10MB 是分水岭吗？还是更早就要干预？，不能只用一个大类词概括。

Redis单线程模型导致大String操作阻塞全局：SET/GET/DEL 1MB以上String会同步占用主线程数百毫秒，使所有请求排队；最新更适合单value控制在100KB内，超限应序列化压缩分片或改用S3等专用存储；因为 Redis 单线程处理命令，一个超大 String 的读写或删除会独占主线程数百毫秒甚至秒级，期间所有其他请求全部排队等待。为什么 SET/GET 一个大 String 会卡住整个 Redis；Redis 处理每个命令都是串行的，SET 10MB 数据时，主线程要完成：内存分配、数据拷贝、计算 CRC（如果启用了 RDB/AOF）、网络发送响应 —— 这些全在单线程里同步；实测中，5MB String 的 GET 在普通机器上常耗时 80~200ms。这不是“慢”，是“阻塞”：这期间新进来的 INCR、HGET、甚至 PING 全部挂起；客户端表现就是大量 JedisConnectionException 或 TimeoutException 监控上看到 latency 突增，instantaneous；很多人以为删掉就完了，其实 DEL 一个大 String 同样同步释放内存，耗时和 GET 接近甚至更长（尤其碎片多时）。