9个提升逼格的redis命令
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) 2
2) (integer) 1532656201
3) (integer) 2033
4) 1) "flushddbb"
2) 1) (integer) 1 ---- 慢日志编码,一般不用care
2) (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 items
524 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
作者:阿飞的博客
来源:https://www.jianshu.com/p/4df5f2356de9
看完两件小事
如果你觉得这篇文章对你挺有启发,我想请你帮我两个小忙:
- 把这篇文章分享给你的朋友 / 交流群,让更多的人看到,一起进步,一起成长!
- 关注公众号 「方志朋」,公众号后台回复「666」 免费领取我精心整理的进阶资源教程
![JS中文网,Javascriptc中文网是中国领先的新一代开发者社区和专业的技术媒体,一个帮助开发者成长的社区,是给开发者用的 Hacker News,技术文章由为你筛选出最优质的干货,其中包括:Android、iOS、前端、后端等方面的内容。目前已经覆盖和服务了超过 300 万开发者,你每天都可以在这里找到技术世界的头条内容。](https://static.javajike.com/img/common/wx-fzp.png)
本文著作权归作者所有,如若转载,请注明出处
转载请注明:文章转载自「 Java极客技术学习 」https://www.javajike.com