标签：key

最常见的指令是:

keys 前缀*

后面的参数跟通配符来列出所有符合的key。

由于KEYS命令一次性返回所有匹配的key，所以，当redis中的key非常多时，对于内存的消耗和redis服务器都是一个隐患，
对于Redis 2.8以上版本给我们提供了一个更好的遍历key的命令 SCAN 该命令的基本格式：

SCAN cursor [MATCH pattern] [COUNT count]  

SCAN 每次执行都只会返回少量元素，所以可以用于生产环境，而不会出现像 KEYS 或者 SMEMBERS 命令带来的可能会阻塞服务器的问题。

SCAN命令是一个基于游标的迭代器。这意味着命令每次被调用都需要使用上一次这个调用返回的游标作为该次调用的游标参数，以此来延续之前的迭代过程

当SCAN命令的游标参数（即cursor）被设置为 0 时， 服务器将开始一次新的迭代， 而当服务器向用户返回值为 0 的游标时， 表示迭代已结束。

简单的迭代演示：

redis 127.0.0.1:6379> scan 0
1) "17"
2)  1) "key:12"
    2) "key:8"
    3) "key:4"
    4) "key:14"
    5) "key:16"
    6) "key:17"
    7) "key:15"
    8) "key:10"
    9) "key:3"
   10) "key:7"
   11) "key:1"
redis 127.0.0.1:6379> scan 17
1) "0"
2) 1) "key:5"
   2) "key:18"
   3) "key:0"
   4) "key:2"
   5) "key:19"
   6) "key:13"
   7) "key:6"
   8) "key:9"
   9) "key:11"

在上面这个例子中， 第一次迭代使用 0 作为游标， 表示开始一次新的迭代。第二次迭代使用的是第一次迭代时返回的游标 17 ，作为新的迭代参数 。

显而易见，SCAN命令的返回值 是一个包含两个元素的数组， 第一个数组元素是用于进行下一次迭代的新游标， 而第二个数组元素则又是一个数组， 这个数组中包含了所有被迭代的元素。

注意：返回的游标不一定是递增的，可能后一次返回的游标比前一次的小。

在第二次调用 SCAN 命令时， 命令返回了游标 0 ， 这表示迭代已经结束， 整个数据集已经被完整遍历过了。

full iteration ：以 0 作为游标开始一次新的迭代， 一直调用 SCAN 命令， 直到命令返回游标 0 ， 我们称这个过程为一次完整遍历。

SCAN增量式迭代命令并不保证每次执行都返回某个给定数量的元素,甚至可能会返回零个元素， 但只要命令返回的游标不是 0 ， 应用程序就不应该将迭代视作结束。

不过命令返回的元素数量总是符合一定规则的， 对于一个大数据集来说， 增量式迭代命令每次最多可能会返回数十个元素；而对于一个足够小的数据集来说，可能会一次迭代返回所有的key。

前不久重构系统的时候，发现redis的key已经超过5000万个了，已经没法用keys做遍历了，即使用迭代器*scan做遍历，开销也大到无法接受了。对业务我是相当熟悉的，我很确定我们不需要这么多的key，于是着手开始清理。

首先我跑了个脚本，统计出最常见的key的前缀，发现有两类最多，都超过1000万，分别是

• carbrand_udid_，缓存的是每个用户的绑定了车牌的车型

• 1100_341_，缓存的是某个URL对应的图片是否允许被展示

这些key都没有过期时间，也没有清理机制。而业务本身是要求carbrand_udid_永不过期的，1100_341_的时效则比较短，通常在半个月以内，最长也不会超过三个月。

针对第一种情况，原先一个carbrand_udid_$userId对应一个车型列表，通常这个列表长度不超过10，毕竟拥有10个以上车牌且在我们平台上绑定过的用户是极其稀有的。而且每次对这个列表都是整体存取的，不需要单独访问其中一个车型。这种情况其实很好改造，我们放弃每个用户一个key的做法，改用hashtable，table.carbrand，用$userId做hashtable的field，然后把JSON序列化后的车型ID作为value，Redis的hashtable可以存储40亿个键值对，我们用户数才3亿，绑定了牌照的用户不过几千万，在可以预见的未来，不存在超过40亿的可能性。第一种情况的改造，把数千万个key塞到了hashtable内，变成了一个key加这个key内部的数千万个field。

本质上这种改造，是把二维的数据压缩成一维的，data[][]变成data[]，消失的那个维度是通过JSON编码成字符串完成的。

针对第二种情况，原先是1100_341_$URL，值是0或1，用来存储一个广告图片是否能展示，0是不能展示，1是可以展示。直接用上面那种方法也能大大减少key的数量，但是我需要做的更好，增加一个过期的功能。由于redis只能对key设置过期时间，不能对二维数据结构内部元素做过期设置，只能想别的办法了。能不能好好利用有效期最长也不会超过三个月这个特性呢？当然可以，而且很简单。我们把日期编码进key里面就行了，比如这样

• image.audit.white.2018.Q1

• image.audit.black.2018.Q2

• image.audit.white.2018.Q1

• image.audit.black.2018.Q2

每个季度一个白名单set和黑名单set，把URL存储在set里面，再通过判断集合中是否存在某个元素决定URL是否能访问。我们每次最多需要查4个名单，可以确定URL在哪个集合，利用redis的pipeline特性，可以在一个报文里批量查询，一次查完。4条O(1)复杂度的命令执行起来是很快的。还能不能继续优化一些呢？考虑到大部分URL都很长，在空间利用上有些浪费，所以我选择用sha1把URL做个签名，只存储这个签名就行了。第二种改造，成功把数千万个key，减少到每个季度2个，然后定期删除上上季度的key，就能完成清理工作了。

Redis有丰富的数据结构，需要因地制宜好好使用。如若不然，还不如用memcached算了。

redis的–bigkeys参数：对redis整个keyspace进行统计（数据量大时采样，调用scan命令），寻找每种数据类型较大的keys，给出数据统计

redis-cli –bigkeys -i 0.1 -h 127.0.0.1

最近生产环境的redis服务器由于key过期不及时，现在发现时key的个数已经暴增到5000多万了。然后运维同学那边就报警了，最大内存12G，已经用了9G多了，正好下面快要双11了，让我们快些解决。

redis服务器里面堆积大量的队列状态相关的key，其实这些key可以设置有效期，或者任务完成以后删除或者过期，但是由于我们使用类库的问题，这些key既没有删除也没有过期，堆积到redis里面去了，现在我们要做的就是删除这些无用key。在删除这些keys的过程中，走了不少弯路，这里说一下我最终采用的方案。

redis的del函数可以删除单个key，也可以删除多个key，del函数官方文档可以看这里。在google之后看到目前网络上很多文章的思路是使用keys匹配返回要删除的key，然后调用del函数去删除。这种方案在数据量较小时无可厚非，但如果像我这样面临的处理的数据有5千W时，keys的阻塞问题可能会给线上生产环境带来致命的问题。所以我们需要对这种方案作出一些修改。

可喜的是自从2.8.0以后redis提供scan来遍历key，而且这个过程是非阻塞，不会影响线上生产环境。最终经过修改的方案是用scan遍历要删除的key，然后调用del删除。

下面是我用python写的用来删除key的脚本。

import sys,redis

r = redis.Redis(host="127.0.0.1", port=6379,db=0)

if  len(sys.argv) <= 1:
    print("必须指明匹配key字符串")
    exit(1)
pattern = sys.argv[1]

cursor = 0
num = 1
while 1 :
    resut = r.scan(cursor, pattern, 10000)
    del_keys = []
    for i in resut[1]:
        key = i.decode()
        del_keys.append(key)
    #print("del keys len :%d" % len(result))
    if len(del_keys) == 0:
        break
    r.delete(*del_keys)
    cursor = resut[0]
    print("delete keys num : %dw" % (num))
    num +=1

print("donen")

如何利用我这个脚本删除符合某个规则的key哪，如以king开头的key？

下面的命令即可完成上面的问题。

python3 main.py "king*"

期间我看到网上利用keys+del的lua脚本的方案，花了一段时间把scan+del改成lua脚本来删除。但是可惜的是目前redis并不支持这么做，由于scan返回的结果是不确定的，所以禁止在其后直接调用del操作。