大文本写入Redis导致内存暴涨，根本原因在于直接用set存几MB字符串，而非管道误用；正确做法是压缩、分片或换存储，>1MB文本须gzip压缩后再存，禁用管道塞单个大value。
大文本写入Redis时内存暴涨，是管道没用对
直接用 jedis.set(key, hugeString) 或 lettuce.sync().set(key, hugeString) 写几MB的字符串，客户端和Redis都会吃紧：Jedis会把整个字符串转成byte[]一次性发出去，Lettuce默认同步调用也阻塞线程且无缓冲控制。真正该用管道的场景，其实是「批量小操作」，不是「单次大内容」——大文本本身不该走管道，而应先压缩、分片或换存储方式。
如果非得存，优先考虑：
- 用 SET 命令的 EX 和 NX 参数避免覆盖风险
- 对 >1MB 的文本启用 gzip 压缩（Java 用 java.util.zip.GZIPOutputStream）再存
- 避免在管道里塞单个超大 set 操作——管道适合 set key1 val1、set key2 val2、expire key1 3600 这类组合
Jedis管道写入多个String键值对的实际写法
Jedis 管道（Pipeline）本质是把多条命令攒成一个批次发给Redis，减少网络往返。但它不自动序列化或分片，也不处理大value的流式写入。
正确用法示例：
Pipeline p = jedis.pipelined();
for (int i = 0; i < 1000; i++) {
String key = "doc:" + i;
String value = shortContent(i); // 单个value建议 ≤100KB
p.set(key, value);
p.expire(key, 3600);
}
List<Object> results = p.syncAndReturnAll(); // 必须显式触发发送
注意点：
- p.syncAndReturnAll() 必须调用，否则命令一直缓在本地
- 不要传入含 \n\r 或二进制零字节的 raw bytes 到 set，Jedis 会静默截断
- 管道不保证原子性，某条失败不影响其余执行（返回 null 或异常对象）
Lettuce异步管道写入String并控制并发量
Lettuce 的 AsyncCommands 天然支持异步+批处理，比 Jedis 管道更轻量，也更适合高并发写大文本的场景（只要不是单value超5MB）。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
立即学习“Java免费学习笔记（深入）”；
关键控制点：
- 用 StatefulRedisConnection.async() 获取异步接口
- 批量提交前用 Flux.fromIterable() + flatMap() 控制并发数（如 flatMap(..., 16)）
- 避免直接 set(key, hugeString).block()，这等于退化成同步阻塞
简写示意：
AsyncCommands<String, String> async = connection.async();
List<RedisFuture<String>> futures = keysAndValues.stream()
.map(kv -> async.set(kv.key, kv.value))
.collect(Collectors.toList());
async.flushCommands(); // 显式刷出缓冲（非必须，但可减少延迟波动）
// 后续用 CompletableFuture.allOf() 或 reactor 等待全部完成
易错点：
- flushCommands() 不等于执行完成，只是把命令从Netty buffer推到socket
- 如果 value 含 Unicode 辅助字符（如 emoji），确认 Redis 服务端配置了 redis.conf 中的 io-threads-do-reads yes 和客户端编码一致（UTF-8）
- Lettuce 默认开启命令压缩（enableCommandCompression），但仅对协议层有效，不压缩value内容
读取大String时Connection超时或OOM，不是代码问题而是配置漏了
常见现象：java.net.SocketTimeoutException: Read timed out 或 JVM GC 频繁甚至 OOM —— 很可能不是Java代码写错了，而是 Redis 配置或客户端参数没调。
必须检查的项：
- Redis 服务端：client-output-buffer-limit normal 0 0 0（设为0表示不限制，否则大get可能被强制断连）
- Jedis：构造 JedisPool 时设置 maxWaitMillis 和 soTimeout，例如 new JedisPoolConfig().setMaxWaitMillis(5000)
- Lettuce：在 ClientResources 中配置 SocketOptions.connectTimeout() 和 SocketOptions.soTimeout()，别只依赖 timeoutCommands()
- 应用层：对 >512KB 的读取，改用 getrange 分段拉取（jedis.getrange(key, 0, 1024*1024-1)），避免单次分配超大byte[]
真正难处理的，是那些没做容量评估就往Redis塞几十MB日志文本的case——Redis不是文件系统，这种需求该上MinIO或ES。
