【Redis】Redis中scan与keys的区别及优缺点

当我们需要遍历Redis所有key或者指定模式的key时，首先想到的是KEYS命令，例如:keys *

相当于关系型数据库里的select *，因此在一个生产环境中的大Redis数据库中使用这个命令可能会造成性能问题。

从Redis2.8版本以后官方给我们提供了一个更好的遍历KEY的命令SCAN

语法为:

SCAN cursor [MATCH pattern] [COUNT count]

例如:

127.0.0.1:6379> scan 0 match *192.168*

或者

1) "105"

2) 1) "192.168.0.220:6379:CommandCountByMinute"

   2) "192.168.0.121:6379:memory"

   3) "192.168.0.213:6379:CommandCount:1528190604"

   4) "192.168.0.221:6379:KeyCount:1528190601"

   5) "192.168.0.226:6379:KeyCount:1528190334"

   6) "192.168.0.129:6379:CommandCount:1528121363"

   7) "192.168.0.129:6379:KeyCount:1528121366"

 

SCAN 命令返回的每个元素都是一个数据库键,该命令对数据库的性能影响比较小，因此推荐在生产环境中使用。

在redis中，scan和keys两者的功能都是可以查询reids缓存中相同前缀的参数。

keys 可以将所有以该前缀的参数都查询出来，但是当缓存中参数过大时，使用keys查询会使redis进入卡顿；

而scan是根据迭代来查询的，每次查询的数量不一定，可以通过设置一个参数来控制每次查询的数量接近于这个数；

这样的话，当你设置查询的数量为10时，那每次查询出来的数量可能是8,7,11，反正就接近于这个数。

所以在数据量大的时候使用scan，当数据量小时可以使用keys，这就是两者最大的区别。

常用的使用场景：redis 用scan 代替keys 解决百万数据模糊查询超时问题

要求：

Redis server version >= 2.8.24

scan搜索：

Jedis jedis=RedisUtils.getConn();

ScanParams scanParams = new ScanParams();

scanParams.match(“key*”);
scanParams.count(100000);//每10万条查询
Long startTime = System.currentTimeMillis();
List<String> retList = new ArrayList<String>();
final String scanRet = "0";
do {
ScanResult<String> ret = jedis.scan(scanRet, scanParams);
scanRet = ret.getStringCursor();// 返回用于下次遍历的游标
retList.addAll(ret.getResult());// 返回结果
} while (!scanRet.equals("0"));
System.out.println("retList size:"+retList.size());
Long endTime = System.currentTimeMillis();
System.out.println("using time is:" + (endTime - startTime)+"ms");

测试结果：局域网测试结果从700万数据搜索某个key耗时11秒 仅供参考

 

edis的keys命令，通来在用来删除相关的key时使用，但这个命令有一个弊端，在redis拥有数百万及以上的keys的时候，会执行的比较慢，更为致命的是，这个命令会阻塞redis多路复用的io主线程，如果这个线程阻塞，在此执行之间其他的发送向redis服务端的命令，都会阻塞，从而引发一系列级联反应，导致瞬间响应卡顿，从而引发超时等问题，所以应该在生产环境禁止用使用keys和类似的命令smembers，这种时间复杂度为O（N），且会阻塞主线程的命令，是非常危险的。

keys命令的原理就是扫描整个redis里面所有的db的key数据，然后根据我们的通配的字符串进行模糊查找出来。官网详细的介绍如下。

https://redis.io/commands/KEYS

取而代之的，如果需要查找然后删除key的需求，那么在生产环境我们应该使用scan命令，代替keys命令，同样是O（N）复杂度的scan命令，支持通配查找，scan命令或者其他的scan如SSCAN ，HSCAN，ZSCAN命令，可以不用阻塞主线程，并支持游标按批次迭代返回数据，所以是比较理想的选择。keys相比scan命令优点是，keys是一次返回，而scan是需要迭代多次返回。

https://redis.io/commands/scan

但scan命令的也有缺点，返回的数据有可能重复，需要我们在业务层按需要去重，scan命令的游标从0开始，也从0结束，每次返回的数据，都会返回下一次游标应该传的值，我们根据这个值，再去进行下一次的访问，如果返回的数据为空，并不代表没有数据了，只有游标返回的值是0的情况下代表结束。

redis命令例子如下：

scan 0 match my*key count 10000

在Java项目里面，使用jedis执行scan命令的模板例子如下：

Jedis jedis = getJedis();               //存储返回的结果
Set<String> result=new HashSet<String>();                //设置查询的参数
ScanParams scanParams=new ScanParams().count(scanLimitSize).match(pattern);                //游标的开始
String cur=ScanParams.SCAN_POINTER_START;                
    do {                   //遍历每一批数据
        ScanResult<String> scan=jedis.scan(cur, scanParams);                    //得到结果返回
        List<String> scanResult =scan.getResult();                    
        result.addAll(scanResult);                    //获取新的游标
        cur=scan.getStringCursor();                //判断游标迭代是否结束
    }while (!cur.equals(ScanParams.SCAN_POINTER_START));                //返回结果
        return result;

 

 

 

.附录：Protobuf性能到底有没有比JSON快5倍：https://blog.csdn.net/xiaoxiaoyusheng2012/article/details/81102369

 

1、相关资料

《一个基于Protocol Buffer的Java代码演示》
《强列建议将Protobuf作为你的即时通讯应用数据传输格式》
《Protobuf通信协议详解：代码演示、详细原理介绍等》
《请教IM中netty+protobuf 如何更好地使用？》

2、benchmark结果

benchmark 的对象有以下几个： 

• Jackson：Java 程序里用的最多的 JSON 解析器。benchmark 中开启了 AfterBurner 的加速特性；
• DSL-JSON：世界上最快的 Java JSON 实现；
• Jsoniter：我抄袭 DSL-JSON 写的实现。特别申明：我是 Jsoniter 的作者。这里提到的所有关于Jsoniter 的评测数据都不应该被盲目相信。大部分的性能优化技巧是从 DSL-JSON 中直接抄来的；
• Fastjson：在中国很流行的 JSON 解析器；
• Protobuf：在 RPC （远程方法调用）里非常流行的二进制编解码格式；
• Thrift：另外一个很流行的 RPC 编解码格式。这里 benchmark 的是 TCompactProtocol。

Protobuf 解析 double 是 Jackson 的 13 倍。毫无疑问，JSON真的不适合存浮点数。