记录一下redis常用运维命令

2023年1月26日 281次阅读来源: jerrik

一、命令集

auth passwd 认证登录
TIME 查看时间戳与微秒数
DBSIZE 查看当前库中的key数量
BGREWRITEAOF 后台进程重写AOF
BGSAVE 后台保存rdb快照
SAVE 保存rdb快照
LASTSAVE 上次保存时间
SLAVEOF 设为slave服务器
FLUSHALL 清空所有db
FLUSHDB 清空当前db
SHUTDOWN[“”|save|nosave] 断开连接,关闭服务器
SLOWLOG 显示慢查询
INFO 显示服务器信息
CONFIG GET 获取配置信息
CONFIG SET 设置配置信息
MONITOR 打开控制台
SYNC 主从同步
CLIENT LIST 客户端列表
CLIENT KILL 关闭某个客户端
CLIENT SETNAME 为客户端设置名字
CLIENT GETNAME 获取客户端名字

二、几个比较常用的命令

1. info命令(可以查看Redis 服务器的各种信息和统计数值)

# Server
redis_version:2.6.9
redis_git_sha1:00000000
redis_git_dirty:0
redis_mode:standalone
os:Linux 3.4.9-gentoo x86_64
arch_bits:64
multiplexing_api:epoll          # redis的事件循环机制
gcc_version:4.6.3
process_id:18926
run_id:df8ad7574f3ee5136e8be94aaa6602a0079704cc # 标识redis server的随机值
tcp_port:6379
uptime_in_seconds:120           # redis server启动的时间(单位s)
uptime_in_days:0                # redis server启动的时间(单位d)
lru_clock:321118                # Clock incrementing every minute, for LRU management TODO 不清楚是如何计算的

# Clients
connected_clients:3             # 连接的客户端数
client_longest_output_list:0    # 当前客户端连接的最大输出列表    TODO
client_biggest_input_buf:0      # 当前客户端连接的最大输入buffer TODO
blocked_clients:0               # 被阻塞的客户端数

# Memory
used_memory:573456              # 使用内存，单位B
used_memory_human:560.02K       # human read显示使用内存
used_memory_rss:1798144         # 系统给redis分配的内存（即常驻内存）
used_memory_peak:551744         # 内存使用的峰值大小
used_memory_peak_human:538.81K  # human read显示内存使用峰值
used_memory_lua:31744           # lua引擎使用的内存
mem_fragmentation_ratio:3.14    # used_memory_rss/used_memory比例，一般情况下，used_memory_rss略高于used_memory，当内存碎片较多时，则mem_fragmentation_ratio会较大，可以反映内存碎片是否很多
mem_allocator:jemalloc-3.3.1    # 内存分配器

# Persistence
##########################
# rdb和aof事redis的两种持久化机制
#
# rdb是通过配置文件设置save的时间的改动数量来操作
# 把上次改动后的数据达到设置的指标后保存到db
# 如果中间发生了crash，则数据会丢失
# 这种策略被叫做快照
#
# aof是持续的把写操作执行写入一个类似日志的文件
# 但是会影响应能
# 分为appendfsync always和appendfsync eversec
# 前者每次写操作都同步，数据安全性高，但是特别消耗性能
# 后者每秒同步一次，如果发生crash，则可能会丢失1s的数据
##########################
loading:0                       #
rdb_changes_since_last_save:0   # 自上次dump后rdb的改动
rdb_bgsave_in_progress:0        # 标识rdb save是否进行中
rdb_last_save_time:1366359865   # 上次save的时间戳
rdb_last_bgsave_status:ok       # 上次的save操作状态
rdb_last_bgsave_time_sec:-1     # 上次rdb save操作使用的时间(单位s)
rdb_current_bgsave_time_sec:-1  # 如果rdb save操作正在进行，则是所使用的时间
----------------------------
aof_enabled:0                   # 是否开启aof，默认没开启
aof_rewrite_in_progress:0       # 标识aof的rewrite操作是否在进行中
aof_rewrite_scheduled:0         # 标识是否将要在rdb save操作结束后执行
aof_last_rewrite_time_sec:-1    # 上次rewrite操作使用的时间(单位s)
aof_current_rewrite_time_sec:-1 # 如果rewrite操作正在进行，则记录所使用的时间
aof_last_bgrewrite_status:ok    # 上次rewrite操作的状态
-----------------------------
# 开启aof后增加的一些info信息
aof_current_size:0              # aof当前大小
aof_base_size:0                 # aof上次启动或rewrite的大小
aof_pending_rewrite:0           # 同上面的aof_rewrite_scheduled
aof_buffer_length:0             # aof buffer的大小
aof_rewrite_buffer_length:0     # aof rewrite buffer的大小
aof_pending_bio_fsync:0         # 后台IO队列中等待fsync任务的个数
aof_delayed_fsync:0             # 延迟的fsync计数器 TODO
-----------------------------

# Stats
total_connections_received:7    # 自启动起连接过的总数
total_commands_processed:7      # 自启动起运行命令的总数
instantaneous_ops_per_sec:0     # 每秒执行的命令个数
rejected_connections:0          # 因为最大客户端连接书限制，而导致被拒绝连接的个数
expired_keys:0                  # 自启动起过期的key的总数
evicted_keys:0                  # 因为内存大小限制，而被驱逐出去的键的个数
keyspace_hits:0                 # 在main dictionary(todo)中成功查到的key个数
keyspace_misses:0               # 同上，未查到的key的个数
pubsub_channels:0               # 发布/订阅频道数
pubsub_patterns:0               # 发布/订阅模式数
latest_fork_usec:0              # 上次的fork操作使用的时间（单位ms）
##########################
# pubsub是一种消息传送的方式，分为频道和模式两种
# 消息不支持持久化，消息方中断后再连接，前面的消息就会没了
# 频道是指通过SUBSCRIBE指定一个固定的频道来订阅
# 模式是指通过PSUBSCRIBE模式匹配来订阅相关的匹配给定模式的频道
##########################

# Replication
role:master                     # 角色
connected_slaves:1              # 连接的从库数
slave0:127.0.0.1,7777,online
-----------------------------
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:4
master_sync_in_progress:0       # 标识主redis正在同步到从redis
slave_priority:100
slave_read_only:1
connected_slaves:0

# CPU
used_cpu_sys:0.00           # redis server的sys cpu使用率
used_cpu_user:0.12          # redis server的user cpu使用率
used_cpu_sys_children:0.00  # 后台进程的sys cpu使用率
used_cpu_user_children:0.00 # 后台进程的user cpu使用率

# Keyspace
db0:keys=2,expires=0
db1:keys=1,expires=0

2. config(可以查看redis配置属性值)

语法:[config get xxx]
例如:

//查看timeout配置
127.0.0.1:6379> config get timeout
1) "timeout"
2) "600"
127.0.0.1:6379>

同样的还有config set [属性] [属性值] ,给指定属性值设置参数。

3. client list(实时查看已经建立的连接)

127.0.0.1:6379> client list
id=13636 addr=10.1.60.25:57398 fd=106 name= age=28543 idle=6274 flags=N db=1 sub=0 psub=3 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=psubscribe
id=14071 addr=10.1.60.25:36923 fd=150 name= age=6342 idle=6 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=ping
id=14116 addr=127.0.0.1:37037 fd=6 name= age=28 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client
127.0.0.1:6379>

列一下client list中对应的字段含义:

以下是域的含义：
addr ： 客户端的地址和端口
fd ： 套接字所使用的文件描述符
age ： 以秒计算的已连接时长
idle ： 【以秒计算的空闲时长】
flags ： 客户端 flag
db ： 该客户端正在使用的数据库 ID
sub ： 已订阅频道的数量
psub ： 已订阅模式的数量
multi ： 在事务中被执行的命令数量
qbuf ： 查询缓冲区的长度（字节为单位， 0 表示没有分配查询缓冲区）
qbuf-free ： 查询缓冲区剩余空间的长度（字节为单位， 0 表示没有剩余空间）
obl ： 输出缓冲区的长度（字节为单位， 0 表示没有分配输出缓冲区）
oll ： 输出列表包含的对象数量（当输出缓冲区没有剩余空间时，命令回复会以字符串对象的形式被入队到这个队列里）
omem ： 输出缓冲区和输出列表占用的内存总量
events ： 文件描述符事件
cmd ： 最近一次执行的命令
客户端 flag 可以由以下部分组成：
O ： 客户端是 MONITOR 模式下的附属节点（slave）
S ： 客户端是一般模式下（normal）的附属节点
M ： 客户端是主节点（master）
x ： 客户端正在执行事务
b ： 客户端正在等待阻塞事件
i ： 客户端正在等待 VM I/O 操作（已废弃）
d ： 一个受监视（watched）的键已被修改， EXEC 命令将失败
c : 在将回复完整地写出之后，关闭链接
u : 客户端未被阻塞（unblocked）
A : 尽可能快地关闭连接
N : 未设置任何 flag
文件描述符事件可以是：
r : 客户端套接字（在事件 loop 中）是可读的（readable）
w : 客户端套接字（在事件 loop 中）是可写的（writeable）

如果发现idle中对应的值比较高,说明redis的timeout属性设置有问题。结合config get timeout查看一下超时时间,如果timeout为0,说明已经禁用掉该功能,就有可能导致redis连接数不释放的问题。

4. client kill（杀掉某个连接）

CLIENT KILL 127.0.0.1:43501

5. slowlog（查看redis慢查询）

Slow log 的行为由两个配置参数(configuration parameter)指定，可以通过改写 redis.conf 文件或者用 CONFIG GET 和 CONFIG SET 命令对它们动态地进行修改。
第一个选项是 slowlog-log-slower-than ，它决定要对执行时间大于多少微秒(microsecond，1秒 = 1,000,000 微秒)的查询进行记录。
比如执行以下命令将让 slow log 记录所有查询时间大于等于 100 微秒的查询：
CONFIG SET slowlog-log-slower-than 100
而以下命令记录所有查询时间大于 1000 微秒的查询：
CONFIG SET slowlog-log-slower-than 1000
另一个选项是 slowlog-max-len ，它决定 slow log 最多能保存多少条日志， slow log 本身是一个 FIFO 队列，当队列大小超过 slowlog-max-len 时，最旧的一条日志将被删除，而最新的一条日志加入到 slow log ，以此类推。
以下命令让 slow log 最多保存 1000 条日志：
CONFIG SET slowlog-max-len 1000
使用 CONFIG GET 命令可以查询两个选项的当前值：

redis> CONFIG GET slowlog-log-slower-than
1) "slowlog-log-slower-than"
2) "1000"

redis> CONFIG GET slowlog-max-len
1) "slowlog-max-len"
2) "1000"

查看 slow log
要查看 slow log ，可以使用 SLOWLOG GET 或者 SLOWLOG GET number 命令，前者打印所有 slow log ，最大长度取决于 slowlog-max-len 选项的值，而 SLOWLOG GET number 则只打印指定数量的日志。
最新的日志会最先被打印：

为测试需要，将 slowlog-log-slower-than 设成了 10 微秒

redis> SLOWLOG GET
1) 1) (integer) 12                      # 唯一性(unique)的日志标识符
   2) (integer) 1324097834              # 被记录命令的执行时间点，以 UNIX 时间戳格式表示
   3) (integer) 16                      # 查询执行时间，以微秒为单位
   4) 1) "CONFIG"                       # 执行的命令，以数组的形式排列
      2) "GET"                          # 这里完整的命令是 CONFIG GET slowlog-log-slower-than
      3) "slowlog-log-slower-than"

2) 1) (integer) 11
   2) (integer) 1324097825
   3) (integer) 42
   4) 1) "CONFIG"
      2) "GET"
      3) "*"

3) 1) (integer) 10
   2) (integer) 1324097820
   3) (integer) 11
   4) 1) "CONFIG"
      2) "GET"
      3) "slowlog-log-slower-than"

日志的唯一 id 只有在 Redis 服务器重启的时候才会重置，这样可以避免对日志的重复处理(比如你可能会想在每次发现新的慢查询时发邮件通知你)。
查看当前日志的数量
使用命令 SLOWLOG LEN 可以查看当前日志的数量。
请注意这个值和 slower-max-len 的区别，它们一个是当前日志的数量，一个是允许记录的最大日志的数量。

redis> SLOWLOG LEN
(integer) 14

清空日志
使用命令 SLOWLOG RESET 可以清空 slow log 。

redis> SLOWLOG LEN
(integer) 14
redis> SLOWLOG RESET
OK
redis> SLOWLOG LEN
(integer) 0

6. Redis-benchmark测试Redis性能

Usage: redis-benchmark [-h <host>] [-p <port>] [-c <clients>] [-n <requests]> [-k <boolean>]

 -h <hostname>      Server hostname (default 127.0.0.1)
 -p <port>          Server port (default 6379)
 -s <socket>        Server socket (overrides host and port)
 -c <clients>       Number of parallel connections (default 50)
 -n <requests>      Total number of requests (default 10000)
 -d <size>          Data size of SET/GET value in bytes (default 2)
 -k <boolean>       1=keep alive 0=reconnect (default 1)
 -r <keyspacelen>   Use random keys for SET/GET/INCR, random values for SADD
  Using this option the benchmark will get/set keys
  in the form mykey_rand:000000012456 instead of constant
  keys, the <keyspacelen> argument determines the max
  number of values for the random number. For instance
  if set to 10 only rand:000000000000 - rand:000000000009
  range will be allowed.
 -P <numreq>        Pipeline <numreq> requests. Default 1 (no pipeline).
 -q                 Quiet. Just show query/sec values
 --csv              Output in CSV format
 -l                 Loop. Run the tests forever
 -t <tests>         Only run the comma-separated list of tests. The test
                    names are the same as the ones produced as output.
 -I                 Idle mode. Just open N idle connections and wait.

测试命令事例：
1、redis-benchmark -h 192.168.1.201 -p 6379 -c 100 -n 100000
100个并发连接，100000个请求，检测host为localhost 端口为6379的redis服务器性能
2、redis-benchmark -h 192.168.1.201 -p 6379 -q -d 100
测试存取大小为100字节的数据包的性能
3、redis-benchmark -t set,lpush -n 100000 -q
只测试某些操作的性能
4、redis-benchmark -n 100000 -q script load “redis.call(‘set’,’foo’,’bar’)”
只测试某些数值存取的性能

测试结果分析:

requests completed in 0.30 seconds
parallel clients
bytes payload
  keep alive: 1

0.11% <= 1 milliseconds
86.00% <= 2 milliseconds
90.12% <= 3 milliseconds
96.68% <= 4 milliseconds
99.27% <= 5 milliseconds
99.54% <= 6 milliseconds
99.69% <= 7 milliseconds
99.78% <= 8 milliseconds
99.89% <= 9 milliseconds
100.00% <= 9 milliseconds
33222.59 requests per second

====== PING_BULK ======
requests completed in 0.27 seconds
parallel clients
bytes payload
  keep alive: 1

0.93% <= 1 milliseconds
97.66% <= 2 milliseconds
100.00% <= 2 milliseconds
37174.72 requests per second

====== SET ======
requests completed in 0.32 seconds
parallel clients
bytes payload
  keep alive: 1

0.22% <= 1 milliseconds
91.68% <= 2 milliseconds
97.78% <= 3 milliseconds
98.80% <= 4 milliseconds
99.38% <= 5 milliseconds
99.61% <= 6 milliseconds
99.72% <= 7 milliseconds
99.83% <= 8 milliseconds
99.94% <= 9 milliseconds
100.00% <= 9 milliseconds
30959.75 requests per second

====== GET ======
requests completed in 0.28 seconds
parallel clients
bytes payload
  keep alive: 1

0.55% <= 1 milliseconds
98.86% <= 2 milliseconds
100.00% <= 2 milliseconds
35971.22 requests per second

====== INCR ======
requests completed in 0.14 seconds
parallel clients
bytes payload
  keep alive: 1

95.61% <= 1 milliseconds
100.00% <= 1 milliseconds
69444.45 requests per second

====== LPUSH ======
requests completed in 0.21 seconds
parallel clients
bytes payload
  keep alive: 1

18.33% <= 1 milliseconds
100.00% <= 1 milliseconds
48309.18 requests per second

====== LPOP ======
requests completed in 0.23 seconds
parallel clients
bytes payload
  keep alive: 1

0.29% <= 1 milliseconds
99.76% <= 2 milliseconds
100.00% <= 2 milliseconds
44052.86 requests per second

====== SADD ======
requests completed in 0.22 seconds
parallel clients
bytes payload
  keep alive: 1

2.37% <= 1 milliseconds
99.81% <= 2 milliseconds
100.00% <= 2 milliseconds
44444.45 requests per second

====== SPOP ======
requests completed in 0.22 seconds
parallel clients
bytes payload
  keep alive: 1

4.27% <= 1 milliseconds
99.84% <= 2 milliseconds
100.00% <= 2 milliseconds
44642.86 requests per second

====== LPUSH (needed to benchmark LRANGE) ======
requests completed in 0.22 seconds
parallel clients
bytes payload
  keep alive: 1

12.35% <= 1 milliseconds
99.62% <= 2 milliseconds
100.00% <= 2 milliseconds
46082.95 requests per second

====== LRANGE_100 (first 100 elements) ======
requests completed in 0.48 seconds
parallel clients
bytes payload
  keep alive: 1

0.01% <= 1 milliseconds
3.27% <= 2 milliseconds
98.71% <= 3 milliseconds
99.93% <= 4 milliseconds
100.00% <= 4 milliseconds
20964.36 requests per second

====== LRANGE_300 (first 300 elements) ======
requests completed in 1.26 seconds
parallel clients
bytes payload
  keep alive: 1

0.01% <= 2 milliseconds
0.14% <= 3 milliseconds
0.90% <= 4 milliseconds
7.03% <= 5 milliseconds
31.68% <= 6 milliseconds
78.93% <= 7 milliseconds
98.88% <= 8 milliseconds
99.56% <= 9 milliseconds
99.72% <= 10 milliseconds
99.95% <= 11 milliseconds
100.00% <= 11 milliseconds
7961.78 requests per second

====== LRANGE_500 (first 450 elements) ======
requests completed in 1.82 seconds
parallel clients
bytes payload
  keep alive: 1

0.01% <= 2 milliseconds
0.06% <= 3 milliseconds
0.14% <= 4 milliseconds
0.30% <= 5 milliseconds
0.99% <= 6 milliseconds
2.91% <= 7 milliseconds
8.11% <= 8 milliseconds
43.15% <= 9 milliseconds
88.38% <= 10 milliseconds
97.25% <= 11 milliseconds
98.61% <= 12 milliseconds
99.26% <= 13 milliseconds
99.30% <= 14 milliseconds
99.44% <= 15 milliseconds
99.48% <= 16 milliseconds
99.64% <= 17 milliseconds
99.85% <= 18 milliseconds
99.92% <= 19 milliseconds
99.95% <= 20 milliseconds
99.96% <= 21 milliseconds
99.97% <= 22 milliseconds
100.00% <= 23 milliseconds
5491.49 requests per second

====== LRANGE_600 (first 600 elements) ======
requests completed in 2.29 seconds
parallel clients
bytes payload
  keep alive: 1

0.01% <= 2 milliseconds
0.05% <= 3 milliseconds
0.10% <= 4 milliseconds
0.19% <= 5 milliseconds
0.34% <= 6 milliseconds
0.46% <= 7 milliseconds
0.58% <= 8 milliseconds
4.46% <= 9 milliseconds
21.80% <= 10 milliseconds
40.48% <= 11 milliseconds
60.14% <= 12 milliseconds
79.81% <= 13 milliseconds
93.77% <= 14 milliseconds
97.14% <= 15 milliseconds
98.67% <= 16 milliseconds
99.08% <= 17 milliseconds
99.30% <= 18 milliseconds
99.41% <= 19 milliseconds
99.52% <= 20 milliseconds
99.61% <= 21 milliseconds
99.79% <= 22 milliseconds
99.88% <= 23 milliseconds
99.89% <= 24 milliseconds
99.95% <= 26 milliseconds
99.96% <= 27 milliseconds
99.97% <= 28 milliseconds
99.98% <= 29 milliseconds
100.00% <= 29 milliseconds
4359.20 requests per second

====== MSET (10 keys) ======
requests completed in 0.37 seconds
parallel clients
bytes payload
  keep alive: 1

0.01% <= 1 milliseconds
2.00% <= 2 milliseconds
18.41% <= 3 milliseconds
88.55% <= 4 milliseconds
96.09% <= 5 milliseconds
99.50% <= 6 milliseconds
99.65% <= 7 milliseconds
99.75% <= 8 milliseconds
99.77% <= 9 milliseconds
99.78% <= 11 milliseconds
99.79% <= 12 milliseconds
99.80% <= 13 milliseconds
99.81% <= 15 milliseconds
99.82% <= 16 milliseconds
99.83% <= 17 milliseconds
99.84% <= 19 milliseconds
99.85% <= 21 milliseconds
99.86% <= 23 milliseconds
99.87% <= 24 milliseconds
99.88% <= 25 milliseconds
99.89% <= 27 milliseconds
99.90% <= 28 milliseconds
99.91% <= 30 milliseconds
99.92% <= 32 milliseconds
99.93% <= 34 milliseconds
99.95% <= 35 milliseconds
99.96% <= 36 milliseconds
99.97% <= 37 milliseconds
99.98% <= 39 milliseconds
99.99% <= 41 milliseconds
100.00% <= 41 milliseconds
27173.91 requests per second

参考文档:http://www.cnblogs.com/silent2012/p/4514901.html
http://www.runoob.com/redis/server-client-list.html
http://dba10g.blog.51cto.com/764602/1846068
http://blog.csdn.net/cxhgg/article/details/67640263

    原文作者：jerrik
    原文地址: https://www.jianshu.com/p/1f3b86f46e03
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。