但是redis-cli不仅如此。你可以使用一些选项来启动程序以使其进入特殊模式，以便redis-cli绝对可以执行更复杂的任务，例如模拟从节点并打印从主节点接收的复制流（replication stream），检查延迟。 Redis服务器并显示统计数据，甚至显示延迟样本和频率以及其他许多东西的ASCII频谱图。

本指南将涵盖redis-cli的不同方面，从最简单的开始到以更高级的结尾。

如果你打算广泛使用Redis，或者已经使用Redis，那么你很有可能经常使用redis-cli。花一些时间来熟悉它可能是一个很好的主意，一旦你了解了Redis命令行界面的所有技巧，你就会发现你将更有效地使用Redis。

1.1.命令行用法

仅运行命令并将其回复打印在标准输出上，就像键入命令以将其作为redis-cli的单独参数执行一样简单：

$ redis-cli incr mycounter
(integer) 7

该命令的回复为“7”。由于输入的是Redis回复（它们可以是strings, arrays, integers, NULL, errors等），因此你会在方括号之间看到回复的类型。但是，当必须将redis-cli的输出用作另一个命令的输入时，或者当我们要将其重定向到文件中时，这并不是一个好主意。

实际上，当redis-cli检测到标准输出是tty（基本上是终端）时，它仅显示其他信息，从而提高了可读性。否则，它将自动启用原始输出模式，如以下示例所示：

$ redis-cli incr mycounter > /tmp/output.txt
$ cat /tmp/output.txt
8

由于CLI检测到输出不再写入终端，因此该时间（整数）从输出中省略了。你甚至可以使用--raw选项在终端上强制进行原始输出：

$ redis-cli --raw incr mycounter
9

类似地，当使用--no-raw写入文件或管道中的其他命令时，可以强制使可读的方式输出。

1.2.Host, port, password, database

默认情况下，redis-cli通过127.0.0.1端口6379连接到服务器。你可以猜测，可以使用命令行选项轻松更改此设置。要指定其他主机名或IP地址，请使用-h。为了设置其他端口，请使用-p。

$ redis-cli -h redis15.localnet.org -p 6390 ping
PONG

如果你的实例受密码保护，则-a <password>选项将执行身份验证，从而省去了显式使用AUTH 命令的需要：

$ redis-cli -a myUnguessablePazzzzzword123 ping
PONG

或者，可以通过REDISCLI_AUTH环境变量将密码提供给redis-cli。

最后，可以使用-n <dbnum>选项发送对默认编号为零的数据库编号进行操作的命令：

$ redis-cli flushall
OK
$ redis-cli -n 1 incr a
(integer) 1
$ redis-cli -n 1 incr a
(integer) 2
$ redis-cli -n 2 incr a
(integer) 1

也可以使用-u <uri>选项和有效的URI提供部分或全部此信息：

$ redis-cli -u redis://p%40ssw0rd@redis-16379.hosted.com:16379/0 ping
PONG

1.3.SSL/TLS

默认情况下，redis-cli使用普通TCP连接来连接到Redis。你可以使用--tls选项以及--cacert或--cacertdir来启用SSL/TLS，以配置受信任的根证书捆绑包或目录。

如果目标服务器要求使用客户端证书进行身份验证，则可以使用--cert和--key指定证书和相应的私钥。

1.4.从其他程序获取输入

可以使用两种方式使用redis-cli来从其他命令（基本上是从标准输入）获取输入。一种是将我们从标准输入中读取的有效负载用作最后一个参数。例如，如果要在我的计算机上将Redis密钥设置为文件/etc/services的内容，可以使用-x选项：

$ redis-cli -x set foo < /etc/services
OK
$ redis-cli getrange foo 0 50
"#\n# Network services, Internet style\n#\n# Note that "

正如你在上述会话的第一行中看到的那样，未指定SET 命令的最后一个参数。参数只是SET foo，而没有我想要将键设置为的实际值。

而是指定了-x选项，并将文件重定向到CLI的标准输入。因此读取了输入，并将其用作命令的最终参数。这对于脚本编写很有用。

另一种方法是向redis-cli提供一系列写入文本文件的命令：

$ cat /tmp/commands.txt
set foo 100
incr foo
append foo xxx
get foo
$ cat /tmp/commands.txt | redis-cli
OK
(integer) 101
(integer) 6
"101xxx"

commands.txt中的所有命令都由redis-cli依次执行，就像它们是由用户交互键入的一样。如果需要，可以在文件内用字符串将引号引起来，这样就可以在其中包含空格，换行符或其他特殊字符的单个参数：

$ cat /tmp/commands.txt
set foo "This is a single argument"
strlen foo
$ cat /tmp/commands.txt | redis-cli
OK
(integer) 25

1.5.连续运行相同的命令

用户选择两次执行之间的暂停，可以执行相同的命令指定次数。这在不同的上下文中很有用，例如，当我们要连续监视一些关键内容或INFO字段输出时，或者当我们要模拟一些重复发生的写事件时（例如每5秒将一个新项目推入一个列表）。

此功能由两个选项控制：

-r <count> 说明运行命令的次数
-i <delay> 说明配置不同命令调用之间的延迟（以秒为单位）（可以指定十进制数（如0.1，以表示100毫秒）

默认情况下，间隔（或延迟）设置为0，因此命令会尽快执行：

$ redis-cli -r 5 incr foo
(integer) 1
(integer) 2
(integer) 3
(integer) 4
(integer) 5

要永久运行同一命令，请使用-1作为计数。因此，为了随时间监视RSS内存大小，可以使用如下命令：

$ redis-cli -r -1 -i 1 INFO | grep rss_human
used_memory_rss_human:1.38M
used_memory_rss_human:1.38M
used_memory_rss_human:1.38M
... a new line will be printed each second ...

1.6.使用redis-cli批量插入数据

使用redis-cli进行批量插入在单独的页面中进行了介绍，因为它本身是一个值得讨论的话题。请参考我们的大量插入指南。

1.7.CSV output

有时，你可能想使用redis-cli以便将数据从Redis快速导出到外部程序。这可以使用CSV（逗号分隔值）输出功能来完成：

$ redis-cli lpush mylist a b c d
(integer) 4
$ redis-cli --csv lrange mylist 0 -1
"d","c","b","a"

当前，不可能像这样导出整个数据库，而只能运行带有CSV输出的单个命令。

1.8.运行Lua脚本

redis-cli对使用从Redis 3.2开始可用的Lua脚本的新Lua调试工具提供了广泛的支持。有关此功能，请参阅Redis Lua调试器文档。

但是，即使不使用调试器，你也可以使用redis-cli以比在外壳中交互式输入脚本或作为参数输入脚本更舒适的方式运行文件中的脚本：

$ cat /tmp/script.lua
return redis.call('set',KEYS[1],ARGV[1])
$ redis-cli --eval /tmp/script.lua foo , bar
OK

Redis EVAL 命令将脚本使用的键列表以及其他非键参数作为不同的数组。调用EVAL 时，你将键的数量提供为数字。但是，使用redis-cli并使用上面的--eval选项，无需显式指定键的数量。相反，它使用用逗号分隔键和参数的约定。这就是为什么在上述调用中你将foo和bar作为参数的原因。

因此，foo将填充KEYS 数组，并bar ARGV 数组。

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

1.9.交互模式（Interactive mode）

到目前为止，我们已经探索了如何将Redis CLI用作命令行程序。这对于脚本和某些类型的测试非常有用，但是大多数人会使用其交互模式在redis-cli中花费大部分时间。

在交互模式下，用户在提示符下键入Redis命令。该命令将发送到服务器，进行处理，然后将回复解析并呈现为更简单的形式以供阅读。

在交互模式下运行CLI不需要任何特殊操作-无需任何参数即可启动它：

$ redis-cli
127.0.0.1:6379> ping
PONG

string 127.0.0.1:6379> 是提示符。它提醒你已连接到给定的Redis实例。

当你连接的服务器发生更改时，或者在数据库编号为零以外的数据库上运行时，提示也会更改：

127.0.0.1:6379> select 2
OK
127.0.0.1:6379[2]> dbsize
(integer) 1
127.0.0.1:6379[2]> select 0
OK
127.0.0.1:6379> dbsize
(integer) 503

1.10.处理连接和重新连接

通过以交互方式使用connect命令，可以通过指定我们要连接的主机名和端口来连接到其他实例：

127.0.0.1:6379> connect metal 6379
metal:6379> ping
PONG

如你所见，提示会相应更改。如果用户尝试连接到无法访问的实例，则redis-cli进入断开连接模式，并尝试使用每个新命令重新连接：

127.0.0.1:6379> connect 127.0.0.1 9999
Could not connect to Redis at 127.0.0.1:9999: Connection refused
not connected> ping
Could not connect to Redis at 127.0.0.1:9999: Connection refused
not connected> ping
Could not connect to Redis at 127.0.0.1:9999: Connection refused

通常，在检测到断开连接之后，CLI总是尝试透明地重新连接：如果尝试失败，它将显示错误并进入断开连接状态。以下是断开连接和重新连接的示例：

127.0.0.1:6379> debug restart
Could not connect to Redis at 127.0.0.1:6379: Connection refused
not connected> ping
PONG
127.0.0.1:6379> (now we are connected again)

重新连接后，redis-cli会自动重新选择最后选择的数据库编号。但是，关于连接的所有其他状态都将丢失，例如事务的状态（如果我们处于中间的话）：

$ redis-cli
127.0.0.1:6379> multi
OK
127.0.0.1:6379> ping
QUEUED

( here the server is manually restarted )

127.0.0.1:6379> exec
(error) ERR EXEC without MULTI

在交互式模式下使用CLI进行测试时，通常这不是问题，但是你应该意识到这一限制。

1.11.编辑，历史，完成和提示（Editing, history, completion , hints）

由于redis-cli使用linenoise行编辑库，因此它始终具有行编辑功能，而无需依赖libreadline或其他可选库。

你可以访问已执行命令的历史记录，以免反复按箭头键（上和下）来再次键入它们。历史记录在两次CLI重新启动之间保留在用户主目录内名为.rediscli_history的文件中，该文件由HOME环境变量指定。可以通过设置REDISCLI_HISTFILE环境变量来使用其他历史记录文件名，并通过将其设置为/dev/null来禁用它。

CLI也可以通过按TAB键来完成命令名称，如以下示例所示：

127.0.0.1:6379> Z<TAB>
127.0.0.1:6379> ZADD<TAB>
127.0.0.1:6379> ZCARD<TAB>

在提示符下键入Redis命令名称后，CLI将显示语法提示。可以通过CLI首选项打开和关闭此行为。

1.12.配置

有两种方法可以自定义CLI的行为。 CLI会在启动时加载主目录中的.redisclirc文件。还可以在CLI会话期间设置首选项，在这种情况下，首选项将仅在会话期间持续。

要设置首选项，请使用特殊的：set 命令。可以通过在CLI中键入命令或将其添加到.redisclirc文件来设置以下首选项：

:set hints - enables syntax hints 启用语法提示
:set nohints - disables syntax hints 禁用语法提示

1.13.执行N次相同的命令

通过在命令名称前加上数字前缀，可以多次运行同一命令：

127.0.0.1:6379> 5 incr mycounter
(integer) 1
(integer) 2
(integer) 3
(integer) 4
(integer) 5

1.14.显示有关Redis命令的帮助

Redis有许多命令，在测试时，有时你可能不记得参数的确切顺序。 redis-cli使用help命令为大多数Redis命令提供在线帮助。该命令可以两种形式使用：

help @<category> 显示有关给定类别的所有命令。类别是: @generic, @list, @set, @sorted_set, @hash, @pubsub, @transactions, @connection, @server, @scripting, @hyperloglog.
help <commandname> 显示作为参数给出的命令的特定帮助。

例如，为了显示PFADD命令的帮助，请使用：

127.0.0.1:6379> help PFADD

PFADD key element [element ...] summary: Adds the specified elements to the specified HyperLogLog. since: 2.8.9

请注意，帮助也支持TAB完成。

1.15.清除终端屏幕

在交互模式下使用clear命令可清除终端的屏幕。

2.特殊的操作模式

到目前为止，我们看到了redis-cli的两种主要模式。

Redis命令的命令行执行。
交互式“REPL-like”用法。

但是，CLI执行与Redis相关的其他辅助任务，这些任务将在下一节中介绍：

监视工具，用于显示有关Redis服务器的连续统计信息。
在Redis数据库中扫描非常大的键。
具有模式匹配功能的按键空间扫描仪。
充当Pub/Sub客户端订阅频道。
监视在Redis实例中执行的命令。
以不同的方式检查Redis服务器的延迟。
检查本地计算机的调度程序延迟。
从本地远程Redis服务器传输RDB备份。
充当Redis从节点以显示从节点收到的内容。
模拟LRU工作负载以显示有关按键命中的统计信息。
Lua调试器的客户端。

2.1.连续统计模式（Continuous stats mode）

这可能是redis-cli鲜为人知的功能之一，并且对于实时监视Redis实例非常有用。要启用此模式，请使用--stat选项。在此模式下，输出非常清楚CLI的行为：

$ redis-cli --stat
------- data ------ --------------------- load -------------------- - child -
keys       mem      clients blocked requests            connections
506        1015.00K 1       0       24 (+0)             7
506        1015.00K 1       0       25 (+1)             7
506        3.40M    51      0       60461 (+60436)      57
506        3.40M    51      0       146425 (+85964)     107
507        3.40M    51      0       233844 (+87419)     157
507        3.40M    51      0       321715 (+87871)     207
508        3.40M    51      0       408642 (+86927)     257
508        3.40M    51      0       497038 (+88396)     257

在这种模式下，每秒钟都会打印一条新行，其中包含有用的信息以及旧数据点之间的差异。你可以轻松了解内存使用情况，连接的客户端等情况。

在这种情况下，-i <interval> 选项用作修改器，以更改发出新行的频率。默认值为一秒钟。

2.2.扫描大键

在此特殊模式下，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将大大减慢程序的执行速度，但也将服务器上的负载减少到极少。

请注意，该摘要还以更简洁的形式报告了每次找到的最大键。如果针对非常大的数据集运行，则初始输出只是尽快提供一些有趣的信息。

2.3.获取按键列表

还可以以不阻塞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

请注意，使用头 -10 以便仅打印输出的第一行。

扫描能够使用带有 --pattern 选项的 SCAN 命令的基础模式匹配功能。

$ 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

2.4.Pub/sub模式

CLI只需使用PUBLISH命令就可以在Redis发布/订阅通道中发布消息。因为PUBLISH命令与任何其他命令都非常相似，所以这是可以预期的。订阅频道以接收消息是不同的-在这种情况下，我们需要阻止并等待消息，因此在redis-cli中将其实现为特殊模式。与其他特殊模式不同，此模式不是通过使用特殊选项启用的，而只是通过使用SUBSCRIBE 或PSUBSCRIBE 命令以交互或非交互模式启用的：

$ redis-cli psubscribe '*'
Reading messages... (press Ctrl-C to quit)
1) "psubscribe"
2) "*"
3) (integer) 1

阅读消息消息表明我们已进入发布/订阅模式。当另一个客户端在某个频道中发布某些消息时，就像你可以使用redis-cli PUBLISH mychannel mymessage一样，发布/订阅模式下的CLI将显示以下内容：

1) "pmessage"
2) "*"
3) "mychannel"
4) "mymessage"

这对于调试发布/订阅问题非常有用。要退出发布/订阅模式，只需处理CTRL-C。

2.5.监视在Redis中执行的命令

与发布/订阅模式相似，一旦使用了MONITOR模式，就会自动进入监视模式。它将打印Redis实例收到的所有命令：

$ redis-cli monitor
OK
1460100081.165665 [0 127.0.0.1:51706] "set" "foo" "bar"
1460100083.053365 [0 127.0.0.1:51707] "get" "foo"

请注意，可以使用管道传递输出，因此可以使用诸如grep之类的工具监视特定模式。

2.6.监控Redis实例的延迟

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 <interval>选项更改采样会话的长度。

最先进的延迟研究工具，但对于没有经验的用户而言，也更难解释，它是使用彩色终端显示延迟频谱的功能。你将看到一个彩色输出，指示不同百分比的样本，以及不同的ASCII字符，指示不同的等待时间数字。使用--latency-dist选项启用此模式：

$ redis-cli --latency-dist
(output not displayed, requires a color terminal, try it!)

在redis-cli内部实现了另一个非常不寻常的延迟工具。它不会检查Redis实例的延迟，但会检查你正在运行redis-cli的计算机的延迟。你可能会问什么延迟？内核调度程序，虚拟化实例中的管理程序固有的等待时间，等等。

之所以称其为固有延迟，是因为它对程序员来说是最不透明的。如果你的Redis实例的延迟延迟很长，而不管可能是由何原因引起的所有显而易见的事情，那么有必要检查一下系统的最佳状态，方法是直接在运行Redis服务器的系统中以这种特殊模式运行redis-cli。

通过测量固有延迟，你知道这是基线，Redis无法超越你的系统。为了在此模式下运行CLI，请使用--intrinsic-latency <test-time>。测试的时间以秒为单位，并指定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毫秒的时间内运行。

2.7.RDB文件的远程备份

在Redis复制的第一次同步期间，主节点和从节点以RDB文件的形式交换整个数据集。 redis-cli利用此功能来提供远程备份功能，该功能允许将RDB文件从任何Redis实例传输到运行redis-cli的本地计算机。要使用此模式，请使用 --rdb <dest-filename>选项调用CLI：

$ redis-cli --rdb /tmp/dump.rdb
SYNC sent to master, writing 13256 bytes to '/tmp/dump.rdb'
Transfer finished with success.

这是一种简单但有效的方法，可确保你具有Redis实例的灾难恢复RDB备份。但是，在scripts或cron jobs中使用此选项时，请确保检查命令的返回值。如果它不为零，则发生错误，如以下示例所示：

$ redis-cli --rdb /tmp/dump.rdb
SYNC with master failed: -ERR Can't SYNC while not connected with my master
$ echo $?
1

2.8.从机模式（Slave mode）

CLI的从模式是一项高级功能，对Redis开发人员和调试操作很有用。它允许检查主节点在复制流中发送给其从节点的内容，以便将写入传播到其副本。选项名称就是--slave。它是这样工作的：

$ redis-cli --slave
SYNC with master, discarding 13256 bytes of bulk transfer...
SYNC done. Logging commands from master.
"PING"
"SELECT","0"
"set","foo","bar"
"PING"
"incr","mycounter"

该命令首先丢弃第一次同步的RDB文件，然后将接收到的每个命令记录为CSV格式。

如果你认为某些命令未在从节点中正确复制，则这是检查正在发生的事情的好方法，并且也是改善缺陷报告的有用信息。

2.9.执行LRU模拟

Redis通常用作具有 LRU eviction 的缓存。根据键的数量和为高速缓存分配的内存量（通过maxmemory指令指定），高速缓存的命中和未命中量将发生变化。有时，模拟命中率对于正确配置缓存非常有用。

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

从理论上讲，给定请求的分布和Redis内存开销，应该可以使用数学公式来分析计算命中率。但是，Redis可以配置为具有不同的LRU设置（样本数），并且在Redis中近似的LRU的实现在不同版本之间会发生很大变化。同样，每个键的内存量可能会在版本之间变化。这就是构建该工具的原因：其主要目的是测试Redis LRU实施的质量，但现在也可用于测试给定版本在部署时考虑的设置下的行为。

为了使用此模式，你需要指定测试中的键数。你还需要配置一个maxmemory设置，该设置在初次尝试时很有意义。

重要说明：在Redis配置中配置maxmemory设置至关重要：如果不限制最大内存使用量，则由于所有键都可以存储在内存中，因此命中率最终将为100％。或者，如果你指定的键太多而没有最大内存，则最终将使用所有计算机RAM。在大多数情况下，你还需要配置适当的最大内存策略allkeys-lru。

在以下示例中，我将内存限制配置为100MB，并使用1000万个键进行LRU仿真。

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

$ ./redis-cli --lru-test 10000000
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的内存不足。让我们尝试使用500MB。几分钟后，我们将看到输出稳定到以下数字：

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种样式）已经足够了。

原文链接：https://blog.csdn.net/u012549626/article/details/110446304