超大对象直接存Redis String易致OOM或超时，应序列化压缩后分片存储，10MB+对象建议改用S3/Streams等专用方案

超大对象直接存String会触发Redis OOM或网络超时

理论上，Redis的SET命令对单个String值的大小限制是512MB，但这只是个“纸面数字”。一旦对象大小超过几MB，麻烦就来了：客户端读写动不动就超时，主从同步变得卡顿，RDB和AOF持久化写入速度骤降，内存碎片也会显著加剧。更要命的是，Redis采用单线程模型处理命令。想象一下，一个100MB的SET操作，足以让后续所有请求排队等待数百毫秒甚至更久，这对线上服务简直是灾难。

序列化 + 压缩必须在客户端完成，Redis 不参与

这里有个常见的误区：很多人以为Redis能帮忙做序列化或压缩。实际上，Redis本身不提供这些能力，所有处理都必须在应用层完成。别指望redis-cli --compress或者某些客户端驱动的“自动压缩”选项能搞定存储——它们要么压根没这功能，要么只作用于网络传输层（比如启用snappy压缩RESP3协议），并不会改变最终存储在内存里的内容。

• 推荐组合：序列化可以用pickle（Python）、JSON.stringify配合msgpack（JS）、或者Protobuf（Go/Ja va），然后再用zlib或lz4这类库进行压缩。
• 压缩前先测效果：纯文本压缩率通常很高（60%以上），但如果是已经加密过的数据，或者像JPEG这样的二进制文件，压缩收益微乎其微，反而会白白消耗CPU资源。
• 务必设置压缩阈值：比如只对大于128KB的对象启用压缩，避免小对象也走一遍压缩流程，得不偿失。

分片存储要自己管理 key 命名与合并逻辑

Redis没有内置的分片API。所谓的“分片”，其实就是把一个大对象手动切成若干小块，分别用多个SET命令存到不同的key里，读取时再拼装回来。技术难点不在于如何切分，而在于如何保证整个过程的一致性和容错性。

• key命名规范：建议采用{object_id}:chunk:{index}这样的格式。注意用{...}包裹关键部分，以确保在集群模式下，所有相关分片都能落到同一个slot上。
• 元数据必不可少：必须单独存储一份元数据，比如存到{object_id}:meta这个key里，记录总分片数、原始对象大小、以及校验和（可以用xxh3_64算法）。没有这份“地图”，你根本无法判断所有分片是否都已成功写入。
• 写入逻辑：写入所有分片和元数据时，应该用PIPELINE和EXEC包裹起来。但请注意，这并不能保证跨key的原子性（Redis事务不支持）。因此，通常需要配合设置合理的过期时间（EXPIRE）和客户端的重试机制来兜底。
• 读取容错：读取失败时，不能直接抛个错误了事。应该检查是否有分片因超时缺失，并考虑是否能够降级，返回部分可用的数据。

真正的大对象（>10MB）该换存储方案

即便你费尽心思做了序列化、压缩和分片，一个超过10MB的对象放在Redis里，依然是个“定时冲击波”。故障恢复慢、内存占用难以预测、监控指标容易失真，这些问题会接踵而至。这时候，是时候考虑更合适的替代方案了：

• 使用Redis Streams来存储事件流，这非常适合日志、变更记录这类具有时序性的大对象。
• 将对象主体存储到S3或MinIO这类对象存储中，Redis里只保存其URL、TTL和ETag。需要时，通过HTTP Range请求按需加载部分内容。
• 直接换用为大数据量设计的KV存储，比如etcd（注意其单值上限约为2MB）或支持分段内存映射的Apache Ignite。

说到底，如果你的分片逻辑变得越来越复杂，这本身就是一个强烈的信号：你正在试图把Redis当作一个通用的文件系统来用——而它，从来就不是为这个场景设计的。