超大对象直接存Redis String易致OOM或超时，应序列化压缩后分片存储，10MB+对象建议改用S3/Streams等专用方案。
超大对象直接存String会触发Redis OOM或网络超时
Redis 的 SET 命令对单个 String 值没有硬性大小限制（理论最大 512MB），但实际中超过几 MB 就容易出问题：客户端读写超时、主从同步卡顿、RDB/AOF 写入慢、内存碎片加剧。更关键的是，Redis 是单线程处理命令，一个 100MB 的 SET 会阻塞其他所有请求长达数百毫秒甚至秒级。
序列化 + 压缩必须在客户端完成，Redis 不参与
Redis 本身不提供序列化或压缩能力，所有处理必须由应用层完成。常见错误是误以为用 redis-cli --compress 或某语言驱动的“自动压缩选项”能生效——多数驱动压根没这个功能，或仅作用于传输层（如启用 snappy over RESP3），不改变存储内容。
- 推荐组合：
pickle（Python） /JSON.stringify+msgpack（JS） /Protobuf（Go/Java）做序列化，再用zlib/lz4压缩 - 压缩前先测效果：纯文本压缩率高（60%+），加密后或已压缩二进制（如 JPEG）几乎无收益，反而增加 CPU 开销
- 务必设置压缩阈值，比如只对 >128KB 的对象压缩，避免小对象徒增开销
分片存储要自己管理 key 命名与合并逻辑
Redis 没有内置分片 API，所谓“分片”就是把一个大对象切分成多个 SET 存不同 key，读取时再拼接。难点不在切分，而在一致性与容错：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- key 命名建议用
{object_id}:chunk:{index}格式，加{...}保证 hash tag 同 slot（集群模式必需） - 必须存一份元数据，例如
{object_id}:meta，记录总 chunk 数、原始大小、校验和（如xxh3_64），否则无法判断是否写全 - 写入必须用
PIPELINE+EXEC包裹所有 chunk 和 meta，但注意：这不能保证原子性（Redis 不支持跨 key 事务），需配合过期时间（EXPIRE）和客户端重试逻辑 - 读取失败时，不能简单报错，要检查缺失 chunk 是否超时、是否可降级返回部分数据
真正的大对象（>10MB）该换存储方案
哪怕做了序列化、压缩、分片，10MB+ 对象在 Redis 中依然脆弱：故障恢复慢、内存占用不可控、监控指标失真。这时候该考虑替代路径：
- 用
Redis Streams存事件流（适合日志、变更记录类大对象） - 把主体存
S3/MinIO，Redis 只存 URL + TTL + ETag，用 HTTP Range 请求按需加载 - 改用专为大对象设计的 KV 存储，如
etcd（限 2MB）或Apache Ignite（支持分段内存映射）
分片逻辑越复杂，越说明你正在把 Redis 当成通用文件系统用——它不是为此设计的。
