keys

我把这个命令放在第一位，是因为笔者曾经做过的项目，以及一些朋友的项目，都因为使用keys这个命令，导致出现性能毛刺。这个命令的时间复杂度是O(N)，而且redis又是单线程执行，在执行keys时即使是时间复杂度只有O(1)例如SET或者GET这种简单命令也会堵塞，从而导致这个时间点性能抖动，甚至可能出现timeout。

强烈建议生产环境屏蔽keys命令（后面会介绍如何屏蔽）。

scan

既然keys命令不允许使用，那么有什么代替方案呢？有！那就是scan命令。如果把keys命令比作类似select * from users where username like '%afei%'这种SQL，那么scan应该是select * from users where id>? limit 10这种命令。

官方文档用法如下：

SCAN cursor [MATCH pattern] [COUNT count]

初始执行scan命令例如scan 0。SCAN命令是一个基于游标的迭代器。这意味着命令每次被调用都需要使用上一次这个调用返回的游标作为该次调用的游标参数，以此来延续之前的迭代过程。当SCAN命令的游标参数被设置为0时，服务器将开始一次新的迭代，而当redis服务器向用户返回值为0的游标时，表示迭代已结束，这是唯一迭代结束的判定方式，而不能通过返回结果集是否为空判断迭代结束。

使用方式：

127.0.0.1:6380> scan 0
1) "22"
2)  1) "23"2) "20"3) "14"4) "2"5) "19"6) "9"7) "3"8) "21"9) "12"10) "25"11) "7"

返回结果分为两个部分：第一部分即1)就是下一次迭代游标，第二部分即2)就是本次迭代结果集。

slowlog

上面提到不能使用keys命令，如果就有开发这么做了呢，我们如何得知？与其他任意存储系统例如mysql，mongodb可以查看慢日志一样，redis也可以，即通过命令slowlog。用法如下：

SLOWLOG subcommand [argument]

subcommand主要有：

get，用法：slowlog get [argument]，获取argument参数指定数量的慢日志。
len，用法：slowlog len，总慢日志数量。
reset，用法：slowlog reset，清空慢日志。

执行结果如下：

127.0.0.1:6380> slowlog get 5
1) 1) (integer) 22) (integer) 15326562013) (integer) 20334) 1) "flushddbb"
2) 1) (integer) 1  ----  慢日志编码，一般不用care2) (integer) 1532646897  ----  导致慢日志的命令执行的时间点，如果api有timeout，可以通过对比这个时间，判断可能是慢日志命令执行导致的3) (integer) 26424  ----  导致慢日志执行的redis命令，通过4)可知，执行config rewrite导致慢日志，总耗时26ms+4) 1) "config"2) "rewrite"

命令耗时超过多少才会保存到slowlog中，可以通过命令config set slowlog-log-slower-than 2000配置并且不需要重启redis。注意：单位是微妙，2000微妙即2毫秒。

rename-command

为了防止把问题带到生产环境，我们可以通过配置文件重命名一些危险命令，例如keys等一些高危命令。操作非常简单，只需要在conf配置文件增加如下所示配置即可：

rename-command flushdb flushddbb
rename-command flushall flushallall
rename-command keys keysys

bigkeys

随着项目越做越大，缓存使用越来越不规范。我们如何检查生产环境上一些有问题的数据。bigkeys就派上用场了，用法如下：

redis-cli -p 6380 --bigkeys

执行结果如下：

... ...
-------- summary -------Sampled 526 keys in the keyspace!
Total key length in bytes is 1524 (avg len 2.90)Biggest string found 'test' has 10005 bytes
Biggest   list found 'commentlist' has 13 items524 strings with 15181 bytes (99.62% of keys, avg size 28.97)
2 lists with 19 items (00.38% of keys, avg size 9.50)
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)

最后5行可知，没有set,hash,zset几种数据结构的数据。string类型有524个，list类型有两个；通过Biggest ... ...可知，最大string结构的key是test，最大list结构的key是commentlist。

需要注意的是，这个bigkeys得到的最大，不一定是最大。说明原因前，首先说明bigkeys的原理，非常简单，通过scan命令遍历，各种不同数据结构的key，分别通过不同的命令得到最大的key：

如果是string结构，通过strlen判断；
如果是list结构，通过llen判断；
如果是hash结构，通过hlen判断；
如果是set结构，通过scard判断；
如果是sorted set结构，通过zcard判断。

正因为这样的判断方式，虽然string结构肯定可以正确的筛选出最占用缓存，也可以说最大的key。但是list不一定，例如，现在有两个list类型的key，分别是：numberlist--[0,1,2]，stringlist--["123456789123456789"]，由于通过llen判断，所以numberlist要大于stringlist。而事实上stringlist更占用内存。其他三种数据结构hash，set，sorted set都会存在这个问题。使用bigkeys一定要注意这一点。

monitor

假设生产环境没有屏蔽keys等一些高危命令，并且slowlog中还不断有新的keys导致慢日志。那我们如何揪出这些命令是由谁执行的呢？这就是monitor的用处，用法如下：

redis-cli -p 6380 monitor

如果当前redis环境OPS比较高，那么建议结合linux管道命令优化，只输出keys命令的执行情况：

[afei@redis ~]# redis-cli -p 6380 monitor | grep keys
1532645266.656525 [0 10.0.0.1:43544] "keyss" "*"
1532645287.257657 [0 10.0.0.1:43544] "keyss" "44*"

执行结果中很清楚的看到keys命名执行来源。通过输出的IP和端口信息，就能在目标服务器上找到执行这条命令的进程，揪出元凶，勒令整改。

info

如果说哪个命令能最全面反映当前redis运行情况，那么非info莫属。用法如下：

INFO [section]

section可选值有：

Server：运行的redis实例一些信息，包括：redis版本，操作系统信息，端口，GCC版本，配置文件路径等；
Clients：redis客户端信息，包括：已连接客户端数量，阻塞客户端数量等；
Memory：使用内存，峰值内存，内存碎片率，内存分配方式。这几个参数都非常重要；
Persistence：AOF和RDB持久化信息；
Stats：一些统计信息，最重要三个参数：OPS(instantaneous_ops_per_sec)，keyspace_hits和keyspace_misses两个参数反应缓存命中率；
Replication：redis集群信息；
CPU：CPU相关信息；
Keyspace：redis中各个DB里key的信息；

config

config是一个非常有价值的命令，主要体现在对redis的运维。因为生产环境一般是不允许随意重启的，不能因为需要调优一些参数就修改conf配置文件并重启。redis作者早就想到了这一点，通过config命令能热修改一些配置，不需要重启redis实例，可以通过如下命令查看哪些参数可以热修改：

config get *

热修改就比较容易了，执行如下命令即可：

config set

例如：config set slowlog-max-len 100，config set maxclients 1024

这样修改的话，如果以后由于某些原因redis实例故障需要重启，那通过config热修改的参数就会被配置文件中的参数覆盖，所以我们需要通过一个命令将config热修改的参数刷到redis配置文件中持久化，通过执行如下命令即可：

config rewrite

执行该命令后，我们能在config文件中看到类似这种信息：

# 如果conf中本来就有这个参数，通过执行config set，那么redis直接原地修改配置文件
maxclients 1024
# 如果conf中没有这个参数，通过执行config set，那么redis会追加在Generated by CONFIG REWRITE字样后面
# Generated by CONFIG REWRITE
save 600 60
slowlog-max-len 100

set

set命令也能提升逼格？是的，我本不打算写这个命令，但是我见过太多人没有完全掌握这个命令，官方文档介绍的用法如下：

SET key value [EX seconds] [PX milliseconds] [NX|XX]

你可能用的比较多的就是set key value，或者SETEX key seconds value，所以很多同学用redis实现分布式锁分为两步：首先执行SETNX key value，然后执行EXPIRE key seconds。很明显，这种实现有很严重的问题，因为两步执行不具备原子性，如果执行第一个命令后出现某些未知异常导致无法执行EXPIRE key seconds，那么分布式锁就会一直无法得到释放。

通过SET命令实现分布式锁的正式姿势应该是SET key value EX seconds NX（EX和PX任选，取决于对过期时间精度要求）。另外，value也有要求，最好是一个类似UUID这种具备唯一性的字符串。当然如果问你redis是否还有其他实现分布式锁的方案。你能说出redlock，那对方一定眼前一亮，心里对你竖起大拇指，但嘴上不会说。

关于redis分布式锁方案，强烈建议你阅读redis官方文档Redis分布式锁:http://redis.cn/topics/distlock.html

不到 10 个提升逼格的 Redis 命令相关推荐

超全Redis命令总结，墙裂建议收藏，说不定就用上了呢
前言 Redis是一个开源的使用ANSIC语言编写.支持网络.可基于内存亦可持久化的日志型.Key-Value数据库,并提供多种语言的API. Redis可以广泛用于微服务架构.它可能是您应用程序以多 ...
被字节跳动T4级大佬鄙视了：让你10倍提升认知效率，就这3个方法！
来源| 技术领导力(ID:jishulingdaoli) 国庆长假前,老K跟一位字节跳动T4级的大佬吃饭,聊到技术人如何快速提升认知的问题.我说,很简单啊,努力到无能为力,拼搏到感动自己......话 ...
10个提升PPT幻灯片制作效率的方法
PPT是职场当中几乎每个人都有机会接触的工具,做PPT做的时间久了,要是你一直都在重复某些操作,但却没想办法提升效率. 这就不能怪别人都早早下班,而你还在苦逼苦逼地做着PPT了. 今天本文给大家总结了 ...
【视频学习】12堂快速阅读课，10倍提升阅读效率
12堂快速阅读课,10倍提升阅读效率视频下载链接:https://download.csdn.net/download/qq_36749728/19827075 先导课-阅读缓慢的普通人,也能实现& ...
10道不得不会的 Redis 面试题
以下是 Redis 面试题,相信大家都会有种既眼熟又陌生的感觉.看过可能在短暂的面试后又马上忘记了.JavaPub在这里整理这些容易忘记的重点知识及解答,建议收藏,经常温习查阅. 评论区见 @ 1. ...
8款瞬间提升逼格是电脑小软件！
大家电脑上一定都有很多软件,但是有的时候感觉操作起来并不让人很享受,也不是很便捷.今天,小编给大家整理了8款小众却实用的电脑软件,快点拿去提升逼格吧! 1.证照之星证照之星是一款顶级的证件照制作方面 ...
creator 数字翻页效果_用好这款Fliqlo翻页时钟屏保让你电脑瞬间提升逼格和幸福感！...
?本文共计:2088字·⏰阅读时长:6分钟 ?目录预览 -------------- ① 电脑屏幕保护有啥? ② Fliqlo的基本介绍 ③ Fliqlo不同系统的使用教程 + Mac OS系统的使用 ...
10个提升着陆页设计效果的小技巧
网站的着陆页承载了太多的东西.当用户打开着陆页的时候,你得让他们感知到你的品牌调性,通过行为召唤元素促使用户执行特定的操作,通过视觉化的手法,给用户留下深刻的印象等等.想要做好,真的很难.今天的文章将 ...
linux 关闭redis 命令_面试必问的 Redis：RDB、AOF、混合持久化
前言本来说 Redis 分3篇,但是上周写持久化时发现持久化的内容还越多的,于是持久化就单拆一篇了. 我估计后面的主从复制.哨兵.集群内容也是不少,所以说实话,我也不知道之前说的3篇会拆成几篇了持 ...

不到 10 个提升逼格的 Redis 命令