Redis存储大对象：序列化压缩与分片技巧

超大对象直接存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，读取时再拼接。难点不在切分，而在一致性与容错：

• 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 当成通用文件系统用——它不是为此设计的。