redis-cli,Redis命令行界面
redis-cli是Redis命令行界面，一个简单的程序，允许向Redis发送命令，并直接从终端读取服务器发送的回复。
它有两种主要的模式：一种是交互模式，在这种模式下，用户输入命令并获得回复的REPL（Read Eval Print Loop）另一种模式是将命令作为redis-cli的参数发送，执行并打印在标准输出上。
在交互模式下，redis-cli具有基本的行编辑功能，可以提供良好的打字体验。
但是，redis-cli不只是这一点。有些选项可以用来启动程序，以便将其放入特殊模式，以便redis-cli可以完成更复杂的任务，例如模拟slave并打印从master接收到的复制流，查看复制延迟，并显示统计数据，甚至一个ASCII艺术频谱图的延迟样本和频率，以及许多其他事情。
本指南将涵盖redis-cli的不同方面，由简入繁。
如果您要广泛使用Redis，或者您已经这么做了，那么很可能会碰巧使用redis-cli。花一些时间来熟悉它可能是一个非常好的主意，一旦你知道了命令行界面的所有技巧，你就会看到你将更有效地使用Redis。
命令行用法
如下可以直接非交互模式执行命令并在标准输出获取返回结果1
2redis-cli incr mycounter
(integer) 7
‘()’内为返回结果的类型.当我们需要获取返回结果作为下一个命令的输入,或者希望将结果重定向到文件中时,我们可能不需要显示类型信息.
实际上,redis-cli会自动检测,当它检测到标准输出是一个tty(a terminal basically)时,它会显示类型信息来提升可读性,否则它会启用原始输出模式,如下所示:1
2
3$ redis-cli incr mycounter > /tmp/output.txt
$ cat /tmp/output.txt
8
这一次当CLI检测到输出不在写入terminal后,(integer)被删除了不再显示. 你可以使用--raw选项来强制输出到终端的内容也不显示类型信息1
2$ redis-cli --raw incr mycounter
9
同样的,你也可以使用--no-raw强制非tty输出也显示类型信息1
2
3
4
5
6
7
8
9
10[root@cn_mu_binlog_backup ~]# redis-cli -p 6381 incr no
(integer) 1
[root@cn_mu_binlog_backup ~]# redis-cli -p 6381 --raw incr no
2
[root@cn_mu_binlog_backup ~]# redis-cli -p 6381 incr no > res.txt
[root@cn_mu_binlog_backup ~]# cat res.txt
3
[root@cn_mu_binlog_backup ~]# redis-cli -p 6381 --no-raw incr no > res.txt
[root@cn_mu_binlog_backup ~]# cat res.txt
(integer) 4
Host, port, password and database
redis-cli默认会连接127.0.0.1,6379端口.可以使用-h 和 -p选项更改host和port1
2$ redis-cli -h redis15.localnet.org -p 6390 ping
PONG
如果你的instance设置了密码,可以使用-a选项1
2$ redis-cli -a myUnguessablePazzzzzword123 ping
PONG
可以使用-n选项修改database1
2
3
4
5
6
7
8$ 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
Some or all of this information can also be provided by using the -u 1
2$ redis-cli -u redis://p%40ssw0rd@redis-16379.hosted.com:16379/0 ping
PONG
3.2.9没这个
Getting input from other programs
有两种方法可以使用redis-cli来获得来自其他命令的输入.一种是从标准输入stdin读取最后一个argument.例如,set 一个key的值为/etc/services1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28[root@cn_mu_binlog_backup ~]# less /etc/services
# /etc/services:
# $Id: services,v 1.48 2009/11/11 14:32:31 ovasik Exp $
#
# Network services, Internet style
# IANA services version: last updated 2009-11-10
#
# Note that it is presently the policy of IANA to assign a single well-known
# port number for both TCP and UDP; hence, most entries here have two entries
# even if the protocol doesn't support UDP operations.
# Updated from RFC 1700, ``Assigned Numbers'' (October 1994). Not all ports
# are included, only the more common ones.
#
# The latest IANA port assignments can be gotten from
# http://www.iana.org/assignments/port-numbers
# The Well Known Ports are those from 0 through 1023.
# The Registered Ports are those from 1024 through 49151
# The Dynamic and/or Private Ports are those from 49152 through 65535
#
# Each line describes one service, and is of the form:
#
# service-name port/protocol [aliases ...] [# comment]
tcpmux 1/tcp # TCP port service multiplexer
tcpmux 1/udp # TCP port service multiplexer
rje 5/tcp # Remote Job Entry
rje 5/udp # Remote Job Entry
echo 7/tcp
可以使用-x选项1
2
3
4[root@cn_mu_binlog_backup ~]# redis-cli -p 6381 -x set foo < /etc/services
OK
[root@cn_mu_binlog_backup ~]# redis-cli -p 6381 getrange foo 0 50
"# /etc/services:\n# $Id: services,v 1.48 2009/11/11 "
正如你可以在上面的会话的第一行看到的那样,没有指定SET命令的最后一个参数.
而是指定-x选项,并将文件重定向到CLI的标准输入. 所以输入被读取,并被用作命令的最后一个参数. 这对编写脚本很有用.
一个不同的方法是向redis-cli提供一个写在文本文件中的命令列表:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22$ 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"
$ 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"
中间有错误会继续执行
持续运行相同的命令
-r
Execute specified command N times.
-i
When -r is used, waits
seconds per command.
It is possible to specify sub-second times like -i 0.1.
1 | [root@cn_mu_binlog_backup ~]# redis-cli -p 6381 -r 5 -i 1 ping |
使用redis-cli批量插入数据
使用redis-cli进行批量插入会被分离出来，因为它本身就是一个有价值的话题。 请参阅我们的批量插入指南.
CSV格式输出
--csv
Output in CSV format.
1 | $ redis-cli lpush mylist a b c d |
执行lua脚本
redis-cli对使用Lua脚本的新Lua调试工具提供了广泛的支持，从Redis 3.2开始。 有关此功能，请参阅Redis Lua调试器文档。
但是，即使不使用调试器，与以交互方式将脚本键入到shell或作为参数相比，您可以使用redis-cli以更舒适的方式从文件运行脚本：1
2
3
4
5
6
7
8
9$ cat /tmp/script.lua
return redis.call('set',KEYS[1],ARGV[1])
$ redis-cli --eval /tmp/script.lua foo , bar
OK
[root@cn_mu_binlog_backup ~]# redis-cli -p 6381 --eval ./script.lua foo , bar # foo空格,空格bar
OK
[root@cn_mu_binlog_backup ~]# redis-cli -p 6381 get foo
"bar"
Interactive mode 交互模式
到目前为止，我们探讨了如何使用Redis CLI作为命令行程序。 这对于脚本和某些类型的测试非常有用，但是大多数人将大部分时间都花在使用交互模式的redis-cli上。
在交互模式下，用户在提示符下键入Redis命令。 该命令被发送到服务器，进行处理，回复被解析并呈现为更简单的形式来读取。
在交互模式下运行CLI并不需要什么特别的东西 - 只要在没有任何争论的情况下进行午餐就可以了：
1 | $ redis-cli |
127.0.0.1:6379>是提示符,提示你连接server和database. 当改变server或选择其他非0database时提示符会改变
1 | 127.0.0.1:6379> select 2 |
处理连接和重新连接
connect命令,指定hostname和port即可连接另一个instance1
2
3[root@cn_mu_binlog_backup ~]# redis-cli -p 6381
127.0.0.1:6381> connect 127.0.0.1 6380
127.0.0.1:6380>
正如你所看到的提示相应地改变。 如果用户尝试连接到不可访问的实例，则redis-cli将进入断开连接模式，并尝试在执行每个新命令时重新连接：1
2
3
4
5
6
7127.0.0.1:6380> 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
not connected>
通常在检测到断开连接后，CLI始终尝试重新连接：如果尝试失败，则显示错误并进入断开连接状态。 以下是断开和重新连接的示例：1
2
3
4
5127.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会自动重新选择最后一个选择的数据库编号。 然而，关于连接的所有其他状态都会丢失，例如，如果我们处于中间状态，1
2
3
4
5
6
7
8
9
10$ 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进行测试时，这通常不是问题，但您应该知道这个限制。
Editing, history and completion
由于redis-cli使用linenoise行编辑库，因此它总是具有行编辑功能，而不依赖libreadline或其他可选库。
您可以访问已执行的命令的历史记录，以便通过按方向键（向上和向下）来避免重复输入它们。 在通过HOME环境变量指定的用户主目录内的.rediscli_history文件中，CLI的重新启动之间保存历史记录。 可以通过设置REDISCLI_HISTFILE环境变量来使用不同的历史文件名，并通过将其设置为/dev/null来禁用它。
CLI也可以通过按TAB键执行命令补全，如下例所示：1
2
3127.0.0.1:6379> Z<TAB>
127.0.0.1:6379> ZADD<TAB>
127.0.0.1:6379> ZCARD<TAB>
Running the same command N times
可以通过在命令名前添加一个数字来多次运行相同的命令：1
2
3
4
5
6127.0.0.1:6379> 5 incr mycounter
(integer) 1
(integer) 2
(integer) 3
(integer) 4
(integer) 5
Showing help about Redis commands
Redis has a number of commands and sometimes, as you test things, you may not remember the exact order of arguments. redis-cli provides online help for most Redis commands, using the help command. The command can be used in two forms:
help @
help
For example in order to show help for the PFADD command, use:
127.0.0.1:6379> help PFADD
PFADD key element [element …] summary: Adds the specified elements to the specified HyperLogLog. since: 2.8.9
Note that help supports TAB completion as well.
1 | 127.0.0.1:6381> help @set |
Clearing the terminal screen 清屏
1 | clear |
特殊的操作模式
至此我们见识了redis-cli的两种主要模式
- Redis命令的命令行执行。
- 交互式的“类似REPL”的用法。
However the CLI performs other auxiliary tasks related to Redis that are explained in the next sections:
- Monitoring tool to show continuous stats about a Redis server. 监控工具
- Scanning a Redis database for very large keys. 扫描database找出very large key
- Key space scanner with pattern matching. 模式匹配扫描
- Acting as a Pub/Sub client to subscribe to channels. 作为Pub/Sub client订阅频道
- Monitoring the commands executed into a Redis instance. 监视执行到Redis实例中的命令
- Checking the latency of a Redis server in different ways. 以不同的方式检查Redis服务器的延迟
- Checking the scheduler latency of the local computer. 检查本地计算机的调度程序延迟
- Transferring RDB backups from a remote Redis server locally. 从远程Redis服务器传输RDB备份到本地
- Acting as a Redis slave for showing what a slave receives. 扮演Redis的slave,展示slave所接受的东西
- Simulating LRU workloads for showing stats about keys hits. 模拟LRU工作负载显示有关keys命中的统计信息
- A client for the Lua debugger.
Continuous stats mode
这可能是redis-cli的一个鲜为人知的特性之一，并且为了实时监控Redis实例非常有用。 要启用此模式，使用--stat选项。 在这种模式下，CLI的行为输出内容显而易见：1
2
3
4
5
6
7
8
9
10
11$ 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。 默认是一秒钟。
Scanning for big keys
在这个特殊的模式下，redis-cli作为一个关键的空间分析器。 它扫描大键的数据集，但也提供有关数据集组成的数据类型的信息。 使用--bigkeys选项启用此模式，并生成相当详细的输出：1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25$ 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会减慢程序的执行速度，但也会将服务器上的负载减少到很小的数量。
请注意，摘要还会以更清晰的形式报告每次发现的最大密钥。 如果对一个非常大的数据集运行，最初的输出只是提供一些有趣的信息。
Getting a list of keys
也可以扫描key空间，再次以不阻塞Redis服务器的方式（当您使用诸如KEYS *之类的命令时发生这种情况），打印所有的键名，或者对特定的模式进行过滤。 与-bigkeys选项一样，此模式使用SCAN命令，因此，如果数据集正在更改，可能会多次报告键，但是如果从迭代开始以来存在该键，则不会丢失键。 由于它使用这个选项的命令叫做--scan。
1 | $ redis-cli --scan | head -10 |
--pattern模式匹配1
2
3
4
5
6
7
8
9
10
11
12$ 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
Piping the output through the wc command can be used to count specific kind of objects, by key name:1
2$ redis-cli --scan --pattern 'user:*' | wc -l
3829433
Pub/sub mode
The CLI is able to publish messages in Redis Pub/Sub channels just using the PUBLISH command. This is expected since the PUBLISH command is very similar to any other command. Subscribing to channels in order to receive messages is different - in this case we need to block and wait for messages, so this is implemented as a special mode in redis-cli. Unlike other special modes this mode is not enabled by using a special option, but simply by using the SUBSCRIBE or PSUBSCRIBE command, both in interactive or non interactive mode:
1 | [root@cn_mu_binlog_backup ~]# redis-cli -p 6381 psubscribe '*' |
This is very useful for debugging Pub/Sub issues. To exit the Pub/Sub mode just process CTRL-C.
Monitoring commands executed in Redis
Similarly to the Pub/Sub mode, the monitoring mode is entered automatically once you use the MONITOR mode. It will print all the commands received by a Redis instance:1
2
3
4$ 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"
Monitoring the latency of Redis instances
Redis经常用在延迟非常关键的环境中。 延迟涉及应用程序中的多个移动部分，从客户端库到网络堆栈，直到Redis实例本身。
CLI具有多个工具来研究Redis实例的延迟，并了解延迟的最大值，平均值和分布。
基本的延迟检查工具是–latency选项。 使用此选项，CLI运行一个循环，将PING命令发送到Redis实例，并测量获得答复的时间。 这种情况每秒发生100次，统计信息在控制台中实时更新：1
2$ redis-cli --latency
min: 0, max: 1, avg: 0.19 (427 samples)
统计数据以毫秒提供。 通常，由于运行redis-cli本身的系统的内核调度程序导致延迟，所以一个非常快的实例的平均延迟往往被高估了一点，所以0.19以上的平均延迟可能很容易为0.01或更小。 然而，这通常不是一个大问题，因为我们对几毫秒甚至更长时间的事件感兴趣。
有时研究最大和平均潜伏期如何演变是有用的。 --latency-history选项用于此目的：它的工作方式与–latency完全相同，但是每15秒（默认情况下）将从头开始一个新的采样会话：1
2
3
4$ 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中还有一个非常不寻常的延迟工具。 它不会检查Redis实例的延迟，而是检查运行redis-cli的计算机的延迟。 你可能会问什么延迟？ 内核调度程序固有的延迟，虚拟化实例情况下的管理程序等等。
我们称之为内部延迟，因为大多数程序员对它是不透明的。 如果您的Redis实例的延迟时间很长，而不考虑所有可能的原因，那么通过在运行Redis服务器的系统中直接运行此特殊模式下的redis-cli，可以检查系统的最佳性能。
通过测量内在的延迟，你知道这是基准，Redis不能超越你的系统。 为了在此模式下运行CLI，请使用--intrinsic-latency <test-time>。 测试的时间以秒为单位，并指定redis-cli应该检查当前正在运行的系统的延迟时间。1
2
3
4
5
6
7
8
9
10
11
12
13
14$ 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毫秒的时间内运行。
Remote backups of RDB files
在Redis复制的第一次同步期间，主设备和从设备以RDB文件的形式交换整个数据集。 redis-cli利用此功能来提供远程备份功能，允许从任何Redis实例将RDB文件传输到运行redis-cli的本地计算机。 要使用此模式，请使用--rdb <dest-filename>选项调用CLI：1
2
3$ redis-cli --rdb /tmp/dump.rdb
SYNC sent to master, writing 13256 bytes to '/tmp/dump.rdb'
Transfer finished with success.
这是确保您拥有Redis实例的灾难恢复RDB备份的简单而有效的方法。 但是，在脚本或cron作业中使用此选项时，请确保检查命令的返回值。 如果不为零，则发生如下例所示的错误：1
2
3
4$ redis-cli --rdb /tmp/dump.rdb
SYNC with master failed: -ERR Can't SYNC while not connected with my master
$ echo $?
1
Slave mode
CLI的slave模式是用于Redis开发人员和调试操作的高级功能
1 | 这边跑着,同时主库执行set foo bar |
该命令首先丢弃第一个同步的RDB文件，然后以CSV格式记录每个收到的命令。
如果您认为某些命令在您的从站中没有被正确复制，那么这是检查发生了什么的好方法，也是有用的信息，以便改进错误报告。
Performing an LRU simulation
Redis通常用作LRU驱逐的缓存。根据keys的数量和为缓存分配的内存量（通过maxmemory指令指定），缓存命中和未命中的数量将会改变。有时，模拟命中率对正确设置缓存非常有用。
CLI有一个特殊的模式，它执行GET和SET操作的模拟，在请求模式中使用80-20％的幂律分布。这意味着20％的keys将被请求80％的时间，这是缓存场景中的普遍分布。
从理论上讲，考虑到请求分布和Redis内存开销，应该可以用数学公式分析计算命中率。但是，Redis可以配置不同的LRU设置（样本数量），LRU的实现（在Redis中近似）在不同版本之间会发生很大的变化。类似的，每个内存的数量可能会在不同的版本之间改变。这就是为什么这个工具是建立起来的：它的主要动机是测试Redis的LRU实现的质量，但是现在也可以用来测试一个给定的版本如何与你想要部署的想法一致。
为了使用这种模式，你需要在测试中指定keys的数量。您还需要配置一个有意义的maxmemory设置作为第一次尝试。
重要注意事项：在Redis配置中配置maxmemory设置是至关重要的：如果最大内存使用量没有上限，则最终命中率将为100％，因为所有的keys都可以存储在内存中。或者如果你指定了太多的keys并且没有最大的内存，最终所有的计算机RAM都将被使用。还需要配置一个适当的maxmemory策略，大多数时候你想要的是allkeys-lru。
在下面的例子中，我配置了一个100MB的内存限制和一个1000万keys的LRU模拟。
警告：测试使用流水线并将压力服务器，不要与生产实例一起使用。1
2
3
4
5
6
7
8
9$ ./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%)
该程序每秒显示统计信息。 如您所见，在第一秒钟内缓存开始被填充。 后来的失误率稳定在我们可以预期的实际数字上：1
2
3
4120750 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的内存是不够的。 让我们试试500M。 几分钟后，我们将看到输出稳定到以下数字：1
2
3
4140000 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样式）已经足够好了。