Redis MGET性能衰减分析

最新推荐文章于 2025-06-24 22:55:51 发布

近路

最新推荐文章于 2025-06-24 22:55:51 发布

阅读量1.7w

点赞数 3

CC 4.0 BY-SA版权

分类专栏：缓存文章标签： redis 性能高并发

本文链接：https://blog.youkuaiyun.com/Jinlu_npu/article/details/79744689

本文通过实验探讨了Redis MGET命令在不同数量key下的性能表现，发现在key数目较小（50以内）时性能良好，随着key数量增加，性能逐渐衰减，尤其是在key数目超过1000时，响应时间与key数目成正比。实验结果显示，合理控制MGET的key数目对于优化Redis性能至关重要。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

MGET是redis中较为常用的命令，用来批量获取给定key对应的value。因为redis使用基于RESP (REdis Serialization Protocol)协议的rpc接口，而redis本身的数据结构非常高效，因此在日常使用中，IO和协议解析是个不容忽略的资源消耗。通过mget将多个get请求汇聚成一条命令，可以大大降低网络、rpc协议解析的开销，从而大幅提升缓存效率。mget的定义如下（来自REDIS命令参考）：

MGET key [key ...]
返回所有(一个或多个)给定 key 的值。
如果给定的 key 里面，有某个 key 不存在，那么这个 key 返回特殊值 nil 。因此，该命令永不失败。

返回值：
    一个包含所有给定 key 的值的列表。q

例：
    redis> SET redis redis.com
    OK
    redis> SET mongodb mongodb.org
    OK
    redis> MGET redis mongodb
    1) "redis.com"
    2) "mongodb.org"

但是，在某些需要一次批量查询大量key的场景下，我们会发现mget并没有想象中的那么完美。

以电商库存系统（或价格系统）为例，作为原子级的服务，我们经常要面对商品列表页、活动页、购物车、交易等系统的批量查询，一次请求中动辄包含几十甚至上百个sku，此时mget是否还能像我们想象中那般保持极高的吞吐？

我们先来设计一个实验，探一探mget性能的底。

1 实验设计

在本地进行了压测模拟，redis key设计：

key为string类型，固定为八位数字字符串以模拟SKU ID，不足8位者高位填0
value为5位整型数字，模拟商品库存
实验中将SKU ID设置为1～500000的数字

单元测试代码设计原则：

可以方便地调整测试参数
尽量减少GC对结果的影响，设置合适的堆空间和垃圾回收器

压测代码做了局部优化以尽量保证结果的准确性，包括：

针对每一轮压测，提前准备好随机的key列表，避免随机生成key列表时大量的内存操作对测试结果造成影响
每一轮压测统计多次mget的平均执行时间
每一轮压测完成后，强制触发fullgc，尽量避免在压测进行中发生gc

@Test
public void testRedisMultiGetPerformance() {
    final int[] keyLens = new int[]{
   
   1, 2, 3, 4, 5, ..., 10000 };
    for(int keyLen : keyLens){
        noTransactionNoPipelineMultiGetWithSpecifiedKeyList(getPreparedKeys(keyLen));
    }
}
// 在mget前准备好随机的key列表
private List<String[]> getPreparedKeys(int keyLen, int loopTimes) {
    int loopTimes = 1000;
    if(keyLen<10) loopTimes *= 100;
    else if (keyLen<100) loopTimes *= 50;
    else if (keyLen<500) loopTimes *= 10;
    else if (keyLen<1000) loopTimes *= 5;
    return generateKeys(keyLen, i);
}
// 生成 times 组不同的 String[] keys ，每组keys长度为 keyLen
private List<String[]> generateKeys(