Redis进阶-如何从海量的 key 中找出特定的key列表 & Scan详解

本文涉及的产品
云数据库 Tair(兼容Redis),内存型 2GB
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
简介: Redis进阶-如何从海量的 key 中找出特定的key列表 & Scan详解

20200307112715522.png


需求


假设你需要从 Redis 实例成千上万的 key 中找出特定前缀的 key 列表来手动处理数据,可能是修改它的值,也可能是删除 key。那该如何从海量的 key 中找出满足特定前缀的 key 列表来?


我们可以用 keys 来列出所有满足特定正则字符串规则的 key .

192.168.18.131:8001> set artisan 1
OK
192.168.18.131:8001> set artisan2 2
-> Redirected to slot [6066] located at 192.168.18.132:8002
OK
192.168.18.132:8002> set artisan3 3
-> Redirected to slot [1939] located at 192.168.18.131:8001
OK
192.168.18.131:8001> set artisan4 4
-> Redirected to slot [14196] located at 192.168.18.132:8005
OK
192.168.18.132:8005> set artisan5 5
-> Redirected to slot [10069] located at 192.168.18.132:8002
OK
192.168.18.132:8002> 
192.168.18.132:8002> keys *
1) "artisanKey"
2) "clusterArtisan"
3) "artisan2"
4) "ar"
5) "test"
6) "artisan5"
192.168.18.132:8002> keys artisan*
1) "artisanKey"
2) "artisan2"
3) "artisan5"
192.168.18.132:8002> 

我这个是集群环境,有几个key被分到了其他的slot上去了,所以看到的数据仅仅是当前slot的数据。


keys 优点呢 ,使用简单


当然了,也有缺点


一次性列出所有满足条件的 key. keys 算法是遍历算法,复杂度是 O(n) ,如果数据量很大,会导致 Redis 服务卡顿,所有读写 Redis 的其它的指令都会被延后甚至会超时报错,因为Redis 是单线程程序,顺序执行所有指令,其它指令必须等到当前的 keys 指令执行完了才可以继续。


咋办呢? ---------------> Redis在 2.8 版本中加入了scan指令.


scan


scan 相比keys 具备有以下特点:


复杂度虽然也是 O(n),但是它是通过游标分步进行的,不会阻塞线程;

提供 limit 参数,可以控制每次返回结果的最大条数,limit 只是一个 hint,返回的结果可多可少;

同 keys 一样,它也提供模式匹配功能;

服务器不需要为游标保存状态,游标的唯一状态就是 scan 返回给客户端的游标整数;

返回的结果可能会有重复,需要客户端去重复,这点非常重要;

遍历的过程中如果有数据修改,改动后的数据能不能遍历到是不确定的;

单次返回的结果是空的并不意味着遍历结束,而要看返回的游标值是否为零


scan基本使用

批量写入一批模拟数据


import redis.clients.jedis.HostAndPort;
import redis.clients.jedis.JedisCluster;
import redis.clients.jedis.JedisPoolConfig;
import java.io.IOException;
import java.util.HashSet;
import java.util.Set;
public class JedisClusterDemo {
    public static void main(String[] args) throws IOException {
        JedisPoolConfig config = new JedisPoolConfig();
        config.setMaxTotal(20);
        config.setMaxIdle(10);
        config.setMinIdle(5);
        Set<HostAndPort> jedisClusterNode = new HashSet<HostAndPort>();
        jedisClusterNode.add(new HostAndPort("192.168.18.131", 8001));
        jedisClusterNode.add(new HostAndPort("192.168.18.131", 8004));
        jedisClusterNode.add(new HostAndPort("192.168.18.132", 8002));
        jedisClusterNode.add(new HostAndPort("192.168.18.132", 8005));
        jedisClusterNode.add(new HostAndPort("192.168.18.133", 8003));
        jedisClusterNode.add(new HostAndPort("192.168.18.133", 8006));
        JedisCluster jedisCluster = null;
        try {
            //connectionTimeout:指的是连接一个url的连接等待时间
            //soTimeout:指的是连接上一个url,获取response的返回等待时间
            jedisCluster = new JedisCluster(jedisClusterNode, 6000, 5000, 10, "artisan", config);
            for (int i = 0; i < 10000; i++) {
                jedisCluster.set("{art}:clusterArtisan:" + i, "artisanValue:" + i);
            }
            System.out.println("DONE");
        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            if (jedisCluster != null)
                jedisCluster.close();
        }
    }
}


20200427224331398.png

scan 参数提供了三个参数:

  • 第一个是 cursor 整数值
  • 第二个是 key 的正则模式
  • 第三个是遍历的 limit hint。

第一次遍历时,cursor 值为 0,然后将返回结果中第一个整数值作为下一次遍历的 cursor。一直遍历到返回的 cursor 值为 0 时结束。

192.168.18.132:8005> scan 0 match {art}:clusterArtisan:9* count 1000
1) "13848"
2)   1) "{art}:clusterArtisan:9927"
     2) "{art}:clusterArtisan:9660"
     3) "{art}:clusterArtisan:994"
     4) "{art}:clusterArtisan:934"
     .....
     ......
     ......
   129) "{art}:clusterArtisan:9830"
   130) "{art}:clusterArtisan:9470"
192.168.18.132:8005> 

将第一次的返回结果 13848 ,作为第二次的入参

192.168.18.132:8005> scan  13848  match {art}:clusterArtisan:9* count 1000
1) "11596"
2)   1) "{art}:clusterArtisan:9347"
     2) "{art}:clusterArtisan:9737"
     3) "{art}:clusterArtisan:9943"
     4) "{art}:clusterArtisan:9944"
    .....
     ......
     ......
   122) "{art}:clusterArtisan:9744"
   123) "{art}:clusterArtisan:9256"
192.168.18.132:8005> 


省略过程 …

依次,获取 ,直到cursor为0 ,遍历结束

192.168.18.132:8005> scan  13209  match {art}:clusterArtisan:9* count 10000
1) "0"
2)   1) "{art}:clusterArtisan:927"
     2) "{art}:clusterArtisan:9474"
     3) "{art}:clusterArtisan:9685"
    ........
    ........
    ........
   424) "{art}:clusterArtisan:9424"
192.168.18.132:8005> 


我们发现limit 是 1000,但是返回的结果并不是返回1000个。因为这个 limit 不是限定返回结果的数量,而是限定服务器单次遍历的字典槽位数量(约等于)。

如果将 limit 设置为 10,你会发现返回结果是空的,但是游标值不为零,意味着遍历还没结束。

比如

192.168.18.132:8005> scan  13822  match {art}:clusterArtisan:999* count 1000
1) "13209"
2) (empty list or set)
192.168.18.132:8005> 

字典的结构


在 Redis 中所有的 key 都存储在一个很大的字典中.

这个字典的结构和 Java 中的HashMap 一样,是一维数组 + 二维链表结构.

第一维数组的大小总是 2^n(n>=0),扩容一次数组大小空间加倍,也就是 n++。



20200430000249774.png


scan 指令返回的游标就是第一维数组的位置索引,我们将这个位置索引称为槽 (slot)。


如果不考虑字典的扩容缩容,直接按数组下标挨个遍历就行了。


limit 参数就表示需要遍历的槽位数,之所以返回的结果可能多可能少,是因为不是所有的槽位上都会挂接链表,有些槽位可能是空的,还有些槽位上挂接的链表上的元素可能会有多个。


每一次遍历都会将 limit数量的槽位上挂接的所有链表元素进行模式匹配过滤后,一次性返回给客户端。


scan 遍历顺序 (高位进位法)


scan 的遍历顺序非常特别。它不是从第一维数组的第 0 位一直遍历到末尾,而是采用了高位进位加法来遍历。之所以使用这样特殊的方式进行遍历,是考虑到字典的扩容和缩容时避免槽位的遍历重复和遗漏.


高位进位法从左边加,进位往右边移动,同普通加法正好相反。但是最终它们都会遍历所有的槽位并且没有重复。


渐进式 rehash


Java 的 HashMap 在扩容时会一次性将旧数组下挂接的元素全部转移到新数组下面。


如果 HashMap 中元素特别多,线程就会出现卡顿现象。Redis 为了解决这个问题,它采用渐进式 rehash。


它会同时保留旧数组和新数组,然后在定时任务中以及后续对 hash 的指令操作中渐渐地将旧数组中挂接的元素迁移到新数组上。这意味着要操作处于 rehash 中的字典,需要同时访问新旧两个数组结构。如果在旧数组下面找不到元素,还需要去新数组下面去寻找。


scan 也需要考虑这个问题,对与 rehash 中的字典,它需要同时扫描新旧槽位,然后将结果融合后返回给客户端。


更多的 scan 指令


scan 指令是一系列指令,除了可以遍历所有的 key 之外,还可以对指定的容器集合进行遍历。


比如 zscan 遍历 zset 集合元素,hscan 遍历 hash 字典的元素、sscan 遍历 set 集

合的元素。


它们的原理同 scan 都会类似的,因为 hash 底层就是字典,set 也是一个特殊的

hash(所有的 value 指向同一个元素),zset 内部也使用了字典来存储所有的元素内容.


大 key 扫描 --bigkeys

[redis@artisan redis-5.0.3]$ ./bin/redis-cli -c -h 192.168.18.131 -p 8001 -a artisan --bigkeys
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
# Scanning the entire keyspace to find biggest keys as well as
# average sizes per key type.  You can use -i 0.1 to sleep 0.1 sec
# per 100 SCAN commands (not usually needed).
[00.00%] Biggest string found so far 'artisan3' with 1 bytes
-------- summary -------
Sampled 2 keys in the keyspace!
Total key length in bytes is 15 (avg len 7.50)
Biggest string found 'artisan3' has 1 bytes
2 strings with 2 bytes (100.00% of keys, avg size 1.00)
0 lists with 0 items (00.00% of keys, avg size 0.00)
0 sets with 0 members (00.00% of keys, avg size 0.00)
0 hashs with 0 fields (00.00% of keys, avg size 0.00)
0 zsets with 0 members (00.00% of keys, avg size 0.00)
0 streams with 0 entries (00.00% of keys, avg size 0.00)
[redis@artisan redis-5.0.3]$ 

如果你担心这个指令会大幅抬升 Redis 的 ops 导致线上报警,还可以增加一个休眠参数。

--bigkeys -i 0.1


上面这个指令每隔 100 条 scan 指令就会休眠 0.1s,ops 就不会剧烈抬升,但是扫描的时间会变长.

[redis@artisan redis-5.0.3]$ ./bin/redis-cli -c -h 192.168.18.131 -p 8001 -a artisan --bigkeys  -i 0.1

使用scan的注意事项 20201101更新


如果在scan的过程中如果有键的变化(增加、 删除、 修改) ,遍历效果可能会碰到如下问题: 新增的键可能没有遍历到, 遍历出了重复的键等情况, 也就是说scan并不能保证完整的遍历出来所有的键, 我们在使用的过程中需要考虑到这一点。

相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务,基于高可靠双机热备架构及可无缝扩展的集群架构,满足高读写性能场景及容量需弹性变配的业务需求。 产品详情:https://www.aliyun.com/product/kvstore &nbsp; &nbsp; ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库&nbsp;ECS 实例和一台目标数据库&nbsp;RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&amp;RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
相关文章
|
6天前
|
消息中间件 缓存 NoSQL
Redis 高并发竞争 key ,如何解决这个难点?
本文主要探讨 Redis 在高并发场景下的并发竞争 Key 问题,以及较为常用的两种解决方案(分布式锁+时间戳、利用消息队列)。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
Redis 高并发竞争 key ,如何解决这个难点?
|
20天前
|
NoSQL 关系型数据库 MySQL
Redis 列表(List)
10月更文挑战第16天
15 2
|
21天前
|
NoSQL Unix Redis
Redis 键(key)
10月更文挑战第15天
30 1
|
4天前
|
存储 NoSQL Java
Redis命令:列表模糊删除详解
通过本文的介绍,我们详细探讨了如何在Redis中实现列表的模糊删除。虽然Redis没有直接提供模糊删除命令,但可以通过组合使用 `LRANGE`和 `LREM`命令,并在客户端代码中进行模糊匹配,来实现这一功能。希望本文能帮助你在实际应用中更有效地操作Redis列表。
9 0
|
28天前
|
缓存 监控 负载均衡
如何解决Redis热点Key问题?技术干货分享
【10月更文挑战第2天】在Redis的使用过程中,热点Key问题是一个常见的性能瓶颈。热点Key指的是那些被频繁访问的Key,它们可能导致Redis服务器的负载不均衡,进而影响整体性能。本文将深入探讨热点Key问题的成因、影响以及多种解决方案,帮助读者在实际工作中有效应对这一挑战。
41 3
|
1月前
|
存储 分布式计算 NoSQL
大数据-40 Redis 类型集合 string list set sorted hash 指令列表 执行结果 附截图
大数据-40 Redis 类型集合 string list set sorted hash 指令列表 执行结果 附截图
24 3
|
1月前
|
缓存 NoSQL Redis
Redis命令:列表模糊删除详解
Redis命令:列表模糊删除详解
41 3
|
12天前
|
存储 NoSQL Redis
Redis常见面试题:ZSet底层数据结构,SDS、压缩列表ZipList、跳表SkipList
String类型底层数据结构,List类型全面解析,ZSet底层数据结构;简单动态字符串SDS、压缩列表ZipList、哈希表、跳表SkipList、整数数组IntSet
|
1月前
|
NoSQL Redis
redis 的 key 过期策略是怎么实现的(经典面试题)超级通俗易懂的解释!
本文解释了Redis实现key过期策略的方式,包括定期删除和惰性删除两种机制,并提到了Redis的内存淘汰策略作为补充,以确保过期的key能够被及时删除。
50 1
|
2月前
|
NoSQL Redis 数据库
12)Redis 的游标迭代器(scan)
12)Redis 的游标迭代器(scan)
32 1
下一篇
无影云桌面