Redis客户端命令

本文为搜集整理，侵权联系删除。

相关链接

redis官方：https://redis.io/documentation

选项：

-c连接集群结点时使用，此选项可防止moved和ask异常

--scan和--pattern 用于扫描指定模式的键，相当于scan命令

--slave 当当前客户端模拟成当前redis节点的从节点，可用来获取当前redis节点的更新操作。合理利用可用于记录当前连接redis节点的一些更新操作，这些更新可能是实开发业务时需要的数据

--rdb 会请求redis实例生成并发送RDB持久化文件，保存在本地。可做定期备份

--pipe 将命令封装成redis通信协议定义的数据格式，批量发送给redis执行

--bigkeys 统计bigkey的分布，使用scan命令对redis的键进行采样，从中找到内存占用比较大的键，这些键可能是系统的瓶颈，也提供有关数据集组成的数据类型的信息

--eval 用于执行lua脚本

--latency 有三个选项，--latency、--latency-history、--latency-dist。它们可检测网络延迟，展现的形式不同

--stat 可实时获取redis的重要统计信息。info命令虽然比较全，但这里可看到一些增加的数据，如requests（每秒请求数），-i 在这种情况下，该选项可用作修改器，以改变发射新线的频率。默认值是一秒。

--raw 和 --no-raw --no-raw 要求返回原始格式。--raw 显示格式化的效果。

--csv 导出CSV数据

一些使用例子:

cat /etc/passwd | redis-cli -x set mypasswd#该SET命令的最后一个参数 未被指定，使用-x选项从文件里面读取最后一个参数

redis-cli --raw get mypasswd#查看数据

$cat /tmp/commands.txt

set foo 100

incr foo

append foo xxx

get foo

$cat /tmp/commands.txt | redis-cli#将命令保存在文件中从命令行直接传递给redis-cli

OK

(integer) 101

(integer) 6

"101xxx"

远程连接redis服务

[root@hd4 src]#redis-cli -h host -p port -a password

172.25.10.13:6379>

远程连接redis服务，并执行命令

[root@hd4 src]#redis-cli -h 172.25.10.13 -p 6379 ping

PONG

[root@hd4 src]#redis-cli -h 172.25.10.13 -p 6379 get hello

"world"

-r代表将命令重复执行多次，ping命令可用于检测redis实例是否存活，如果存活则显示PONG

[root@hd4 src]#redis-cli -r 3 ping

PONG

PONG

PONG

[root@hd4 src]#redis-cli -r 3 -i 5 ping#每隔几秒(如果想用ms，如10ms则写0.01)执行一次命令，必须与-r一起使用

PONG

PONG

PONG

[root@hd4 src]#redis-cli -r 10 -i 1 info|grep used_memory_human#每隔1秒输出内存的使用量，一共输出10次

#导出CSV格式文件

$redis-cli lpush mylist a b c d

(integer) 4

$redis-cli --csv lrange mylist 0 -1

"d","c","b","a"

$cat /tmp/script.lua

return redis.call('set',KEYS[1],ARGV[1])

$redis-cli --eval /tmp/script.lua foo , bar#运行lua脚本

OK

Redis EVAL命令将脚本使用的键列表和其他非键参数作为不同的数组。当EVAL你打电话给你提供数字作为一个数字。但是，使用redis-cli和使用--eval上面的选项时，不需要明确指定键的数量。相反，它使用用逗号分隔键和参数的惯例。这就是为什么你在上面的调用中看到的foo , bar是参数。

所以，foo将填充KEYS数组，bar该ARGV数组。

--eval编写简单脚本时该选项非常有用。对于更复杂的工作，使用Lua调试器肯定更舒适。可以混合使用这两种方法，因为调试器也使用来自外部文件的执行脚本

在这个特殊的模式下，redis-cli作为一个关键的空间分析器。它扫描大键的数据集，但也提供有关数据集组成的数据类型的信息。该模式使用该--bigkeys选项启用，并产生相当详细的输出

$redis-cli --bigkeys

# Scanning the entire keyspace to find biggest keys as well as

# average sizes per key type. You can use -i 0.1 to sleep 0.1 sec

# per 100 SCAN commands (not usually needed).

[00.00%] Biggest string found so far 'key-419' with 3 bytes

[05.14%] Biggest list found so far 'mylist' with 100004 items

[35.77%] Biggest string found so far 'counter:__rand_int__' with 6 bytes

[73.91%] Biggest hash found so far 'myobject' with 3 fields

-------- summary -------

Sampled 506 keys in the keyspace!

Total key length in bytes is 3452 (avg len 6.82)

Biggest string found 'counter:__rand_int__' has 6 bytes

Biggest list found 'mylist' has 100004 items

Biggest hash found 'myobject' has 3 fields

504 strings with 1403 bytes (99.60% of keys, avg size 2.78)

1 lists with 100004 items (00.20% of keys, avg size 100004.00)

0 sets with 0 members (00.00% of keys, avg size 0.00)

1 hashs with 3 fields (00.20% of keys, avg size 3.00)

0 zsets with 0 members (00.00% of keys, avg size 0.00)

在输出的第一部分中，报告每个大于前一个较大键（相同类型）的新键。摘要部分提供有关Redis实例内数据的一般统计信息。

该程序使用该SCAN命令，因此它可以在不影响操作的情况下在繁忙的服务器上执行，但是-i可以使用该选项来限制所请求的每个100个键的指定小数秒的扫描进程。例如，-i 0.1会减慢程序的执行速度，但也会将服务器上的负载减少到很小的数量。

请注意，摘要还会以更清晰的形式报告每次发现的最大键。如果运行在非常大的数据集上，初始输出只是提供一些有趣的信息。

扫描keys空间，以不阻塞Redis服务器的方式进行（当使用类似命令时会发生这种情况KEYS *），并打印所有密钥名称或筛选特定模式。与--bigkeys选项一样，此模式使用该SCAN命令，因此如果数据集正在更改，可能会多次报告密钥，但是如果自从迭代开始以来该密钥存在，则不会丢失任何密钥。由于它使用此选项的命令被调用--scan

$redis-cli --scan | head -10

key-419

key-71

key-236

key-50

key-38

key-458

key-453

key-499

key-446

key-371

扫描能够使用SCAN该--pattern选项的命令的底层模式匹配功能。

$redis-cli --scan --pattern '*-11*'

key-114

key-117

key-118

key-113

key-115

key-112

key-119

key-11

key-111

key-110

key-116

通过wc命令管道输出可用于按键名称来计算特定种类的对象：

$redis-cli --scan --pattern 'user:*' | wc -l

3829433

监控redis实时接收到的命令：

$redis-cli monitor

OK

监控redis延迟涉及应用程序中的多个移动部分，从客户端库到网络堆栈，再到Redis实例本身。CLI有多种功能用于研究Redis实例的延迟并了解延迟的最大值，平均值和分布。

基本的延迟检查工具是--latency可选的。使用此选项，CLI运行一个循环，将PING命令发送到Redis实例，并测量获得答复的时间。这种情况每秒发生100次，统计信息在控制台中实时更新：

$redis-cli --latency

min: 0, max: 1, avg: 0.19 (427 samples)

统计数据以毫秒提供。通常，由于系统的内核调度程序redis-cli 本身导致延迟，所以一个非常快的实例的平均延迟往往会被高估一点，所以0.19以上的平均延迟可能很容易为0.01或更小。然而，这通常不是一个大问题，因为我们对几毫秒或更长时间的事件感兴趣。

有时研究最大和平均潜伏期如何随时间发展是有用的。该--latency-history选项用于此目的：它的工作原理与此类似--latency，但每隔15秒（默认情况下），新的采样会话将从头开始：

$redis-cli --latency-history

min: 0, max: 1, avg: 0.14 (1314 samples) -- 15.01 seconds range

min: 0, max: 1, avg: 0.18 (1299 samples) -- 15.00 seconds range

min: 0, max: 1, avg: 0.20 (113 samples)^C

您可以使用该-i 选项更改采样会话的长度。

最先进的延迟研究工具，对于没有经验的用户来说也有点难解释，是使用彩色终端显示一系列延迟的能力。您会看到一个彩色输出，指示不同百分比的样本，以及指示不同延迟数字的不同ASCII字符。该模式使用以下--latency-dist 选项启用：

$redis-cli --latency-dist

(output not displayed, requires a color terminal, try it!)

里面还有一个非常不寻常的延迟工具redis-cli。它不检查Redis实例的延迟，而是检查正在运行的计算机的延迟redis-cli。你可能会问什么延迟？内核调度程序固有的延迟，虚拟化实例情况下的管理程序等等。

我们称之为内部延迟，因为它对大多数程序员来说是不透明的。如果您的Redis实例的延迟时间很长，无论所有显而易见的事情可能是什么原因造成的，那么通过redis-cli在运行Redis服务器的系统中直接在此特殊模式下运行，可以确保系统能够做到最好。

通过测量内部延迟，您知道这是基准，Redis无法超越您的系统。为了在此模式下运行CLI，请使用--intrinsic-latency 。测试的时间以秒为单位，并指定redis-cli检查当前正在运行的系统的延迟时间。

$redis-cli --intrinsic-latency 5

Max latency so far: 1 microseconds.

Max latency so far: 7 microseconds.

Max latency so far: 9 microseconds.

Max latency so far: 11 microseconds.

Max latency so far: 13 microseconds.

Max latency so far: 15 microseconds.

Max latency so far: 34 microseconds.

Max latency so far: 82 microseconds.

Max latency so far: 586 microseconds.

Max latency so far: 739 microseconds.

65433042 total runs (avg latency: 0.0764 microseconds / 764.14 nanoseconds per run).

Worst run took 9671x longer than the average latency.

重要提示：必须在要运行Redis服务器的计算机上执行此命令，而不是在不同的主机上执行此命令。它甚至不连接到Redis实例，只在本地执行测试。

在上述情况下，我的系统不能比739微妙的最差等待时间做得更好，所以我预计某些查询可能会在不到1毫秒的时间内运行。

执行LRU模拟(命中率测试)

Redis通常用作LRU驱逐的缓存。根据密钥的数量和为缓存分配的内存量（通过maxmemory指令指定），缓存命中和未命中的数量将会改变。有时，模拟命中率对正确配置缓存非常有用。

CLI有一个特殊的模式，它在请求模式中使用80-20％的幂律分布来执行GET和SET操作的模拟。这意味着20％的密钥将被请求80％的时间，这是高速缓存场景中的常见分布。

为了使用此模式，您需要指定测试中的密钥数量。您还需要配置一个maxmemory有意义的设置作为第一次尝试。

重要提示：maxmemory在Redis配置中配置设置至关重要：如果没有最大内存使用限制，则所有密钥都可以存储在内存中，所以命中率最终将为100％。或者，如果您指定的键太多而没有最大内存，则最终将使用所有计算机RAM。还需要配置适当的 maxmemory策略，大部分时间是您想要的allkeys-lru。

在以下示例中，我配置了100MB的内存限制，并使用1000万个密钥对LRU进行了仿真。

警告：测试使用流水线并会给服务器造成压力，请勿将其用于生产实例。

156000 Gets/sec | Hits: 4552 (2.92%) | Misses: 151448 (97.08%)

153750 Gets/sec | Hits: 12906 (8.39%) | Misses: 140844 (91.61%)

159250 Gets/sec | Hits: 21811 (13.70%) | Misses: 137439 (86.30%)

151000 Gets/sec | Hits: 27615 (18.29%) | Misses: 123385 (81.71%)

145000 Gets/sec | Hits: 32791 (22.61%) | Misses: 112209 (77.39%)

157750 Gets/sec | Hits: 42178 (26.74%) | Misses: 115572 (73.26%)

154500 Gets/sec | Hits: 47418 (30.69%) | Misses: 107082 (69.31%)

151250 Gets/sec | Hits: 51636 (34.14%) | Misses: 99614 (65.86%)

该程序每秒显示统计信息。如您所见，在第一秒钟内缓存开始被填充。失败率稍后稳定在我们可以预期的实际数字中：

120750 Gets/sec | Hits: 48774 (40.39%) | Misses: 71976 (59.61%)

122500 Gets/sec | Hits: 49052 (40.04%) | Misses: 73448 (59.96%)

127000 Gets/sec | Hits: 50870 (40.06%) | Misses: 76130 (59.94%)

124250 Gets/sec | Hits: 50147 (40.36%) | Misses: 74103 (59.64%)

对我们的用例来说，59％的愤怒可能是不可接受的。所以我们知道100MB内存是不够的。让我们试试半千兆字节。几分钟后，我们会看到输出稳定到以下数字：

140000 Gets/sec | Hits: 135376 (96.70%) | Misses: 4624 (3.30%)

141250 Gets/sec | Hits: 136523 (96.65%) | Misses: 4727 (3.35%)

140250 Gets/sec | Hits: 135457 (96.58%) | Misses: 4793 (3.42%)

140500 Gets/sec | Hits: 135947 (96.76%) | Misses: 4553 (3.24%)

所以我们知道在500MB的情况下，我们的密钥数量足够多（1000万）和分布（80-20样式）。

======================================================================

连接到redis shell后相关操作命令

·ping：测试连接是否存活如果正常会返回pong

·echo：打印

·select：切换到指定的数据库，数据库索引号index 用数字值指定，以 0 作为起始索引值

·quit：退出

·auth：简单密码认证

·dbsize:查看数据库大小

·flushdb:删除当前数据库里面的所有数据

·flushall:删除所有数据库里面的所有数据，注意不是当前数据库，而是所有数据库

·slowlog:用于配置或查询redis慢日志信息与配置

·time：返回当前服务器时间

·client list: 返回所有连接到服务器的客户端信息和统计数据 参见http://redisdoc.com/server/client_list.html

·client kill ip:port：关闭地址为ip:port的客户端

·client setname为当前连接分配一个名称，限制为字符串类型，最大512M，且不能在名称中使用空格

·client getname返回当前连接由CLIENT SETNAME设置的名字，未设置将恢复“nil”

·client pause阻塞所有客户端一段时间（毫秒计数），重启redis-server会失效

·save：将数据同步保存到磁盘

·bgsave：将数据异步保存到磁盘

·lastsave：执行成功时返回UNIX时间戳。客户端执行BGSAVE 命令时，可以通过每N秒发送一个 LASTSAVE 命令来查看BGSAVE 命令执行的结果，由 LASTSAVE 返回结果的变化可以判断执行结果

·shundown：将数据同步保存到磁盘，然后关闭服务

·info：提供服务器的信息和统计，包括：Server(服务器信息)、Clients(已连接客户端信息)、Memory(内存信息)、Persistence(rdb和aof的持久化相关信息)、Stats(一般统计信息)、Replication(主从信息，master上显示的信息)、Replication(主从信息，slave上显示的信息)、CPU(CPU计算量统计信息)、Commandstats(各种不同类型的命令的执行统计信息)、Cluster(集群相关信息)、Keyspace(数据库相关的统计信息)

·config resetstat：重置info命令中的某些统计数据

·config get：获取配置文件信息

·config set：动态地调整Redis 服务器的配 置(configuration)而无须重启，可以修改的配置参数可以使用命令 CONFIG GET * 来列出

·config rewrite：Redis 服务器时所指定的redis.conf文件进行改写，2.8版本起可用

该CONFIG REWRITE命令重写redis.conf，服务器启动时使用的文件，应用，使其反映当前使用的服务器的配置，比起因为使用的原来这可能是不同所需要的最小的变化CONFIG SET命令。

重写以非常保守的方式执行：

·尽可能保留原始redis.conf的注释和整体结构。

·如果旧的redis.conf文件中已经存在一个选项，它将被重写在相同的位置（行号）。

·如果某个选项尚不存在，但它被设置为其默认值，则不会通过重写过程添加该选项。

·如果某个选项尚不存在，但它被设置为非默认值，则会将其添加到文件末尾。

·未使用的行空白。例如，如果您曾经有过多个save指令，但由于您禁用RDB持久性，当前配置较少或没有，因此所有行将被清空。

·如果由于某种原因原来的配置文件不再存在，CONFIG REWRITE也可以从头重写配置文件。

·但是，如果服务器根本没有配置文件启动（如启动redis-server时，并未指定配置文件），那么CONFIG REWRITE只会返回一个错误“(error) ERR The server is running without a config file”

原子重写过程：为了确保redis.conf文件始终保持一致，即在发生错误或崩溃时始终以旧文件或新文件结尾，重写将使用一次write(2)调用来执行，该调用的内容足以满足至少与旧文件一样大。有时会添加注释形式的附加填充以确保生成的文件足够大，并且稍后会截断文件以删除末尾的填充。

返回值：简单的字符串回复：OK当配置被正确地重写时。否则会返回错误

·monitor：实时转储收到的请求

·slaveof：改变复制策略设置

·client slots命令用于当前的集群状态，以数组形式展示

·command命令用于返回所有的Redis命令的详细信息，以数组形式展示，列表顺序是随机的。

·command count命令用于统计redis 命令的个数

·command getkeys命令用于获取所有key

·command info命令用于获取redis 命令的描述信息

·role命令查看主从实例所属的角色，角色有master, slave, sentinel

·shutdown这个命令执行如下操作:

·停止所有客户端.

·如果配置了save 策略 则执行一个阻塞的save命令.

·如果开启了AOF,则刷新aof文件..

·关闭redis服务进程（redis-server）.

如果配置了持久化策略，那么这个命令将能够保证在关闭redis服务进程的时候数据不会丢失. 如果仅仅在客户端执行SAVE 命令,然后 执行QUIT 命令，那么数据的完整性将不会被保证，因为其他客户端可能在执行这两个命令的期间修改数据库的数据.

注意: 一个没有配置持久化策略的redis实例 (没有aof配置, 没有 “save” 命令) 将不会 在执行SHUTDOWN命令的时候转存一个rdb文件, 通常情况下你不想让一个仅用于缓存的rendis实例宕掉

SAVE 和 NOSAVE 修饰符，通过指定一个可选的修饰符可以改变这个命令的表现形式 比如:

·SHUTDOWN SAVE能够在即使没有配置持久化的情况下强制数据库存储.

·SHUTDOWN NOSAVE 能够在配置一个或者多个持久化策略的情况下阻止数据库存储. (你可以假想它为一个中断服务的 ABORT 命令).

返回值:当发生错误的时候返回状态码 . 当成功的时候不返回任何值，服务退出，链接关闭.

·sync：命令用于同步主从服务器

·bgrewriteaof:执行一个AOF文件 重写操作。重写会创建一个当前 AOF 文件的体积优化版本。

即使BGREWRITEAOF 执行失败，也不会有任何数据丢失，因为旧的 AOF 文件在 BGREWRITEAOF 成功之前不会被修改。

重写操作只会在没有其他持久化工作在后台执行时被触发，也就是说：

·如果 Redis 的子进程正在执行快照的保存工作，那么 AOF 重写的操作会被预定(scheduled)，等到保存工作完成之后再执行 AOF 重写。在这种情况下， BGREWRITEAOF 的返回值仍然是 OK ，但还会加上一条额外的信息，说明 BGREWRITEAOF 要等到保存操作完成之后才能执行。在 Redis 2.6 或以上的版本，可以使用 INFO 命令查看 BGREWRITEAOF 是否被预定。

·如果已经有别的 AOF 文件重写在执行，那么 BGREWRITEAOF 返回一个错误，并且这个新的 BGREWRITEAOF 请求也不会被预定到下次执行。

从Redis 2.4 开始， AOF 重写由 Redis 自行触发， BGREWRITEAOF 仅仅用于手动触发重写操作。