redis 运维常用命令

time #查看时间戳与微妙数

dbsize #查看当前数据库中key数量

bgrewriteaof #后台进程重写aof

bgsave #后台保存rdb快照

save #保存rdb快照

lastsave #上次保存时间

flashall #清空所有的db

flashdb #清空当前db

shutdown[""|save|nosave] #断开连接，关闭服务器

slowlog #显示慢查询（slowlog get 5）

info #显示服务器信息

config get #获取配置信息

config set #设置配置信息

monitor #打开控制台

sync #主从同步

client list #客户端列表

client kill #关闭某个客户端

client setname #为客户端设置名字

client getname #获取客户端名字

禁用/重命名危险命令（KEYS/FLUSHALL/FLUSHDB/CONFIG/EVAL）

二、一个监控软件redis-stst的使用

redis-stat是一个用ruby写成的监控redis的程序，基于info命令获取信息，而不是通过monitor获取信息，因此不会额外消耗性能。

1、安装ruby
yum install -y ruby ruby-devel rubygems

2、安装redis-stat
git clone https://github.com/junegunn/redis-stat.git

3、启动
./redis-stat --verbose --server=8090 5 127.0.0.1:6378 -a 22a66ec8b51b4263daf3f1afd58ba9a7

注意：这里做了一个shh的端口转发，将本地的端口转发到线上的redis进程端口
ssh -L 6378:线上ip:6378 用户名@ip

三、基准性能测试，了解你的 Redis 在生产环境服务器上的基准性能。

什么是基准性能？

简单来讲，基准性能就是指 Redis 在一台负载正常的机器上，其最大的响应延迟和平均响应延迟分别是怎样的？

为什么要测试基准性能？我参考别人提供的响应延迟，判断自己的 Redis 是否变慢不行吗？

答案是否定的。

因为 Redis 在不同的软硬件环境下，它的性能是各不相同的。

为了避免业务服务器到 Redis 服务器之间的网络延迟，你需要直接在 Redis 服务器上测试实例的响应延迟情况。执行以下命令，就可以测试出这个实例 60 秒内的最大响应延迟：

$ redis-cli -h 127.0.0.1 -p 6379 --intrinsic-latency 60

Max latency so far: 1 microseconds.
Max latency so far: 15 microseconds.
Max latency so far: 17 microseconds.
Max latency so far: 18 microseconds.
Max latency so far: 31 microseconds.
Max latency so far: 32 microseconds.
Max latency so far: 59 microseconds.
Max latency so far: 72 microseconds.

1428669267 total runs (avg latency: 0.0420 microseconds / 42.00 nanoseconds per run).
Worst run took 1429x longer than the average latency.

从输出结果可以看到，这 60 秒内的最大响应延迟为 72 微秒（0.072毫秒）。

你还可以使用以下命令，查看一段时间内 Redis 的最小、最大、平均访问延迟：

$ redis-cli -h 127.0.0.1 -p 6379 --latency-history -i 1
min: 0, max: 1, avg: 0.13 (100 samples) -- 1.01 seconds range
min: 0, max: 1, avg: 0.12 (99 samples) -- 1.01 seconds range
min: 0, max: 1, avg: 0.13 (99 samples) -- 1.01 seconds range
min: 0, max: 1, avg: 0.10 (99 samples) -- 1.01 seconds range
min: 0, max: 1, avg: 0.13 (98 samples) -- 1.00 seconds range
min: 0, max: 1, avg: 0.08 (99 samples) -- 1.01 seconds range
...

以上输出结果是，每间隔 1 秒，采样 Redis 的平均操作耗时，其结果分布在 0.08 ~ 0.13 毫秒之间。

了解了基准性能测试方法，那么你就可以按照以下几步，来判断你的 Redis 是否真的变慢了：

1、在相同配置的服务器上，测试一个正常 Redis 实例的基准性能
2、找到你认为可能变慢的 Redis 实例，测试这个实例的基准性能
3、如果你观察到，这个实例的运行延迟是正常 Redis 基准性能的 2 倍以上，即可认为这个 Redis 实例确实变慢了

四、扫描出实例中 bigkey 的分布情况

Redis 提供了扫描 bigkey 的命令，执行以下命令就可以扫描出，一个实例中 bigkey 的分布情况，输出结果是以类型维度展示的：

$ redis-cli --bigkeys -i 0.01

对线上实例进行 bigkey 扫描时，Redis 的 OPS 会突增，为了降低扫描过程中对 Redis 的影响，最好控制一下扫描的频率，
指定 -i 参数即可，它表示扫描过程中每次扫描后休息的时间间隔，单位是秒

扫描结果中，对于容器类型（List、Hash、Set、ZSet）的 key，只能扫描出元素最多的 key。但一个 key 的元素多，
不一定表示占用内存也多，你还需要根据业务情况，进一步评估内存占用情况

这里有两点可以优化：

1、业务应用尽量避免写入 bigkey
2、如果你使用的 Redis 是 4.0 以上版本，用 UNLINK 命令替代 DEL，此命令可以把释放 key 内存的操作，放到后台线程中去执行，从而降低对 Redis 的影响
3、可以开启 lazy-free 机制（lazyfree-lazy-user-del = yes），在执行 DEL 命令时，释放内存也会放到后台线程中执行