Redis SET 命令不全局阻塞，但单次执行时间随 value 长度线性增长，占用主线程导致后续命令延迟；大 value 主要瓶颈在内存分配、拷贝与驱逐逻辑，可通过 SLOWLOG 和 latency-monitor 验证，优化方式包括拆分 key、改用 Stream/Hash 或移出大 blob。
Redis SET 命令在不同 value 长度下是否阻塞？
不会全局阻塞，但单次 SET 操作的执行时间随 value 长度线性增长，会占用主线程更久——这意味着它会延迟同一时刻其他命令的响应，尤其在大 value 场景下，延迟可感知甚至超 1ms。
Redis 是单线程处理命令的（6.0+ 支持多线程 I/O，但命令执行仍串行），所以任何耗时操作都会“卡住”后续请求。关键不是“是否阻塞”，而是“卡多久”。
-
SET key "hello"：纳秒级，几乎无感 -
SET key "a" * 10KB：通常 -
SET key "a" * 1MB：实测常达 0.5–2ms（取决于内存带宽和 CPU） -
SET key "a" * 10MB：可能 > 10ms，已明显影响 P99 延迟
为什么大 String 写入变慢？核心瓶颈在哪
主要开销不在网络传输（TCP 层可缓冲），而在 Redis 内存管理环节：分配新空间、拷贝数据、释放旧对象（如果覆盖）、触发惰性删除或内存碎片整理前的检查。
尤其当 value 超过 proto-max-bulk-len（默认 512MB）虽不报错，但实际分配大块连续内存会加剧 malloc 压力；若启用了 maxmemory 且接近上限，还可能触发 LRU/LFU 驱逐逻辑，进一步拉长耗时。
- 小 value（
- 中等 value（1KB–1MB）：常规
malloc+memcpy，主耗时在此 - 超大 value（> 10MB）：可能触发 jemalloc 的 arena 切换或内存碎片告警，延时抖动增大
如何验证你正在被大 String 拖慢？
别猜，用 redis-cli --latency 和 SLOWLOG GET 5 直接看真实毛刺。重点观察 command 字段是否频繁出现 SET 或 GET，以及 duration 是否持续 > 1ms。
更准的方式是开启 latency-monitor-threshold 1（单位 ms），再执行 latency latest 查最近异常事件。注意：仅监控命令执行阶段，不含网络往返。
- 若
SLOWLOG GET中大量SET耗时 > 2ms，且 value 确实很大，基本可定位 - 用
DEBUG OBJECT key查看内部编码（如embstrvsraw），辅助判断存储形态 - 避免在生产环境用
MEMORY USAGE key扫描全量 key，它本身就会阻塞
能优化吗？绕过还是拆分？
没有银弹，但有明确取舍：如果业务允许，优先拆分；否则只能接受延迟或升级硬件。Redis 本身不提供异步写 String 的接口。
- 拆成多个小 key（如
user:1001:profile:part1）+ 客户端聚合，适合读多写少、value 可分割场景 - 改用
Stream或Hash存储结构化大内容（如日志片段、JSON 字段），利用其天然分片能力 - 纯二进制大 blob（如图片 base64）建议移出 Redis，交给对象存储，只存 URL
- 确认
activedefrag yes和active-defrag-threshold-lower 10是否启用——对长期运行的大 value 实例，内存碎片会放大写入延迟
真正容易被忽略的是：哪怕 value 只有 100KB，如果每秒调用几千次 SET，累积的主线程占用也足以把 P99 推高。这时候问题不在单次，而在频率与体积的乘积。
