redis string最大长度默认为512mb，由proto-max-bulk-len配置项控制，但实际稳定写入通常不超过10–50mb，受限于协议解析、客户端缓冲、内存碎片及连续内存可用性。
SET 命令不适合存超过几 MB 的数据包。512MB 是理论上限，但实际能稳定写入的通常不超过 10–50MB，取决于配置、客户端、网络和内存碎片情况。
proto-max-bulk-len 决定协议层能否接收大值
Redis 6.0+ 默认 proto-max-bulk-len 是 512mb（注意单位是小写 mb），它控制 RESP 协议中 bulk string 的最大长度。如果客户端发的命令以 $513000000 开头，而服务端该值仍是默认 512mb，会直接断连并报 invalid bulk length 错误。
- 修改需重启 Redis：
redis.conf中设proto-max-bulk-len 1gb - 单位必须小写：
1GB或1GB无效，只认1gb、200mb - 调太高有风险：超大 bulk 解析会阻塞单线程，影响其他请求响应
客户端缓冲区和反序列化内存常先于 Redis 报错
即使 Redis 允许存 200MB，redis-py 默认 socket 接收缓冲只有 16MB；Jedis 默认响应读取上限约 100MB；redis-cli 更容易因超时或 OOM 失败。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- Python 示例：
redis.Redis(decode_responses=False, socket_read_size=209715200)才能读 200MB - K8s Pod 内存 limit 设为 1GiB，Redis 自身开销 + 已有 key 占用后，可能只剩不到 300MB 连续空间
-
GET返回值在客户端本地要完整加载进内存——Go/Java/Python 都可能触发OutOfMemoryError或 panic
超过 50MB 就该考虑分片或换存储方案
不是不能存，而是代价陡增：慢查询、主从同步卡顿、RDB/AOF 文件暴涨、备份恢复耗时、故障排查困难。
- 拆成多个 key：
file:12345:part:001、file:12345:part:002，用MGET并行取 - 用
SCAN+DEL清理失败残留，避免单次DEL阻塞太久 - 真正需要存 PDF/音频/模型权重？用 S3/OSS 存原始文件，Redis 只存
{url, size, md5, expire_at}
EMBSTR 和 RAW 编码对小值更友好，但不影响上限
Redis 对 ≤44 字节字符串用 EMBSTR（对象头+字符串连续分配），>44 字节转 RAW（分开 malloc）。这影响内存碎片和访问速度，但不改变 512MB 上限。
- 存一个 1KB 的 JSON？没问题，
RAW分配一次就够了 - 频繁
APPEND到接近 50MB 的值？每次扩容可能触发 realloc，产生大量内存碎片 -
STRLEN始终 O(1)，因为 SDS 结构里存了 len 字段，不用遍历
512MB 这个数字，而是 proto 解析、客户端堆内存、连续内存可用性这三道隐形关卡。别等失败了再查日志，提前在测试环境用真实大小压测整条链路。
