Redis批量获取5-10MB HMSET数据响应延迟高优化方案求助

性能劣化根因 #

• Redis单线程处理模型下，单次Pipeline提交的命令过多会导致请求排队，总响应时间随提交命令量线性上升
• 并行Pipeline未控制并发度时，多请求同时抢占Redis执行资源，反而会导致单批次请求的排队耗时上涨
• Spring Data Redis默认序列化器存在额外的类型转换开销，放大了批量数据的处理耗时

可落地优化方案 #

1. 控制Pipeline单次提交的批次大小 #

不要一次性把500-600个HGETALL命令塞进同一个Pipeline，建议单批次提交的key数量控制在30-50个，这个区间是Redis Pipeline处理哈希拉取的性价比最高区间，既减少了往返次数，也不会导致单请求阻塞过久。

2. 限制并行请求的并发度 #

如果采用分片并行拉取的方案，并发度不要超过Redis服务端的核心数（通常3-4足够），避免多Pipeline请求在Redis端排队。同时要确保Redis连接池的最大连接数不低于并发度，避免客户端等待连接的额外开销。
示例逻辑：

// 分片大小30，并发度3
int batchSize = 30;
int concurrency = 3;
List<List<String>> batches = Lists.partition(keys, batchSize);
ExecutorService executor = new ThreadPoolExecutor(concurrency, concurrency, 0L, TimeUnit.MILLISECONDS, new LinkedBlockingQueue<>());
// 提交所有分片任务并行执行
List<Future<Map<String, Map<String, T>>>> futures = batches.stream()
    .map(batch -> executor.submit(() -> getAllMulti(batch)))
    .collect(Collectors.toList());
// 合并结果
Map<String, Map<String, T>> result = new HashMap<>();
for (Future<Map<String, Map<String, T>>> future : futures) {
    result.putAll(future.get());
}
executor.shutdown();

3. 优化序列化逻辑 #

你当前的实现中，返回结果的反序列化默认使用RedisTemplate配置的全局序列化器，对于哈希类型可以直接指定原生字节序列化，避免多余的类型转换：

// 执行Pipeline时指定结果序列化器为字节数组序列化，自行处理转换
List<Object> resultSet = redisTemplate.executePipelined((RedisCallback<T>) connection -> {
    connection.setSerializer(RedisSerializer.byteArray());
    for (String key : keys) {
        connection.hGetAll(key.getBytes());
    }
    return null;
}, RedisSerializer.byteArray());

4. 数据结构优化（可选） #

如果业务允许调整存储结构，可以把多个tp keys的内容合并为一个聚合大哈希，用原tp key + 哈希字段作为新的聚合哈希的字段名：

• 原存储：tp1 -> {i1:v1, i2:v2}、tp2 -> {i3:v3, i4:v4}
• 优化后存储：tp:agg -> {tp1:i1:v1, tp1:i2:v2, tp2:i3:v3, tp2:i4:v4}
  调整后只需要单次HGETALL或者批量HMGET即可拉取所有需要的数据，完全消除多key批量拉取的开销。注意控制聚合大键的大小不超过10MB，避免引发大键问题。

5. 缓存兜底（可选） #

如果tp keys的数据更新频率较低，可以在客户端加一层本地Caffeine缓存，设置合理的过期时间，优先走本地缓存，缓存 miss 再走Redis拉取，能大幅降低Redis的请求量和响应耗时。

内容的提问来源于stack exchange，提问作者Sugam Agarwal