“Redis：常用命令”的版本间差异
跳到导航
跳到搜索
（→基本用法） |
|||
| 第1行： | 第1行： | ||
[[category:Redis]] | [[category:Redis]] | ||
== | == 关于 == | ||
Redis 使用过程中可能用到的命令。 | Redis 使用过程中可能用到的命令。 | ||
2021年10月3日 (日) 00:03的版本
关于
Redis 使用过程中可能用到的命令。
参考：
redis英文版命令大全：“https://redis.io/commands”redis中文版命令大全：“http://redisdoc.com/”- Redis 命令参考：“http://doc.redisfans.com/”
Key（键）
redis 以 key-value 存储数据，所有的操作均为对 key 的操作。
| 命令 | 说明 |
|---|---|
| keys <pattern> | 查找所有符合给定模式( pattern)的 key 。如“keys *”：列出所有的key； |
| type <key> | 查看 key 所储存的值的类型 |
| exists <key> | 检查某个key是否存在 |
| del <key> | 删除 key |
| move <key> db | 将当前库的 key 移动到给定的库db中，比如：“move k1 2” |
| randomkey <key> | 从当前数据库中随机返回一个 key 。 |
| rename <key> <newkey> | 修改 key 的名称为 newkey |
| renamenx <key> <newkey> | 修改 key 的名称为 newkey （仅当 newkey 不存在时）。 |
| expire <key> seconds | 设置 key 的值的过期时间，以秒计。 |
| expireat <key> timestamp | 设置 key 的值的过期时间，时间参数是 UNIX 时间戳（unix timestamp）。 |
| pexpire <key> milliseconds | 设置 key 的过期时间，以毫秒计。 |
| pexpireat <key> milliseconds-timestamp | 设置 key 过期时间的时间戳(unix timestamp) ，以毫秒计。 |
| ttl <key> | 以秒为单位，返回给定 key 的剩余生存时间：-1 永不过期，-2 已过期或 key 不存在。ttl（time to live） |
| pttl <key> | 以毫秒为单位，返回 key 的剩余的过期时间。 |
| presist <key> | 移除 key 的过期时间，key 将持久保持。 |
| dump <key> | 序列化给定 key ，并返回被序列化的值。
|
| restore <key> <ttl> <serialized-value> | 反序列化给定的序列化值，并将它和给定的 key 关联。
|
| object <subcommand> [arguments [arguments]] | OBJECT 命令允许从内部察看给定 key 的 Redis 对象。
|
| migrate <host> <port> <key> <destination-db>
<timeout> [COPY] [REPLACE] |
将 key 原子性地从当前实例传送到目标实例的指定数据库上。（原实例会被删除）
|
| sort <key> [BY pattern] [LIMIT offset count]
[GET pattern [GET pattern ...]] [ASC | DESC] [ALPHA] [STORE destination] |
返回或保存给定列表、集合、有序集合 key 中经过排序的元素。
|
| scan <cursor> [MATCH pattern] [COUNT count] | 迭代数据库中的数据库键。
|
详述：“dump”与“restore”
dump：序列化给定 key ，并返回被序列化的值：
dump <key>
- 使用 “RESTORE” 命令可以将这个值反序列化为 Redis 键。
- 序列化生成的值有以下几个特点：
- 它带有 64 位的校验和，用于检测错误， RESTORE 在进行反序列化之前会先检查校验和。
- 值的编码格式和 RDB 文件保持一致。
- RDB 版本会被编码在序列化值当中，如果因为 Redis 的版本不同造成 RDB 格式不兼容，那么 Redis 会拒绝对这个值进行反序列化操作。
- 序列化的值不包括任何生存时间信息。
restore：反序列化给定的序列化值，并将它和给定的 key 关联：
restore <key> <ttl> <serialized-value>
- 参数 ttl 以毫秒为单位为 key 设置生存时间；如果 ttl 为 0 ，那么不设置生存时间。
- RESTORE 在执行反序列化之前会先对序列化值的 RDB 版本和数据校验和进行检查，如果 RDB 版本不相同或者数据不完整的话，那么 RESTORE 会拒绝进行反序列化，并返回一个错误。
示例：
redis> SET greeting "hello, dumping world!"
OK
redis> DUMP greeting
"\x00\x15hello, dumping world!\x06\x00E\xa0Z\x82\xd8r\xc1\xde"
redis> RESTORE greeting-again 0 "\x00\x15hello, dumping world!\x06\x00E\xa0Z\x82\xd8r\xc1\xde"
OK
redis> GET greeting-again
"hello, dumping world!"
redis> RESTORE fake-message 0 "hello moto moto blah blah" ; 使用错误的值进行反序列化
(error) ERR DUMP payload version or checksum are wrong
详述：“object”
object：OBJECT 命令允许从内部察看给定 key 的 Redis 对象。
object subcommand [arguments [arguments]]
- 它通常用在除错（debugging）或者了解为了节省空间而对 key 使用特殊编码的情况。
- 当将 Redis 用作缓存程序时，你也可以通过 OBJECT 命令中的信息，决定 key 的驱逐策略（eviction policies）。
- OBJECT 命令有多个子命令：
- “OBJECT REFCOUNT <key>”：返回给定 key 引用所储存的值的次数。此命令主要用于除错。
- “OBJECT ENCODING <key>”：返回给定 key 锁储存的值所使用的内部表示（representation）。
- “OBJECT IDLETIME <key>”：返回给定 key 自储存以来的空转时间（idle， 没有被读取也没有被写入），以秒为单位。
- 对象可以以多种方式编码：
- 字符串可以被编码为 raw（一般字符串）或 int（用字符串表示64位数字是为了节约空间）。
- 列表可以被编码为 ziplist 或 linkedlist 。 ziplist 是为节约大小较小的列表空间而作的特殊表示。
- 集合可以被编码为 intset 或者 hashtable 。 intset 是只储存数字的小集合的特殊表示。
- 哈希表可以编码为 zipmap 或者 hashtable 。 zipmap 是小哈希表的特殊表示。
- 有序集合可以被编码为 ziplist 或者 skiplist 格式。 ziplist 用于表示小的有序集合，而 skiplist 则用于表示任何大小的有序集合。
- 假如你做了什么让 Redis 没办法再使用节省空间的编码时（比如将一个只有 1 个元素的集合扩展为一个有 100 万个元素的集合），特殊编码类型（specially encoded types）会自动转换成通用类型（general type）。
示例：
redis> SET game "COD" # 设置一个字符串
OK
redis> OBJECT REFCOUNT game # 只有一个引用
(integer) 1
redis> OBJECT IDLETIME game # 等待一阵。。。然后查看空转时间
(integer) 90
redis> GET game # 提取game， 让它处于活跃(active)状态
"COD"
redis> OBJECT IDLETIME game # 不再处于空转
(integer) 0
redis> OBJECT ENCODING game # 字符串的编码方式
"raw"
redis> SET phone 15820123123 # 大的数字也被编码为字符串
OK
redis> OBJECT ENCODING phone
"raw"
redis> SET age 20 # 短数字被编码为 int
OK
redis> OBJECT ENCODING age
"int"
详述：“migrate”
migrate：将 key 原子性地从当前实例传送到目标实例的指定数据库上。
migrate <host> <port> <key> <destination-db> <timeout> [COPY] [REPLACE]
- 一旦传送成功， key 保证会出现在目标实例上，而当前实例上的 key 会被删除。
- 这个命令是一个原子操作，它在执行的时候会阻塞进行迁移的两个实例，直到以下任意结果发生：迁移成功，迁移失败，等到超时。
内部实现：
migrate 在当前实例对给定 key 执行【DUMP】 命令 ，将它序列化，然后传送到目标实例，目标实例再使用 【RESTORE】 对数据进行反序列化，并将反序列化所得的数据添加到数据库中；当前实例就像目标实例的客户端那样，只要看到 RESTORE 命令返回 OK ，它就会调用 【DEL】 删除自己数据库上的 key 。
- “timeout”参数以毫秒为格式，指定当前实例和目标实例“进行沟通的最大间隔时间”。（即，数据传送的时间不能超过这个 timeout 数，但操作并不一定要在 timeout 毫秒内完成）
- 如果在传送数据时发生 IO 错误，或者达到了超时时间，那么命令会停止执行，并返回一个特殊的错误： IOERR。
- 当 IOERR 出现时，有以下两种可能：
- key 可能存在于两个实例；
- key 可能只存在于当前实例；
- 唯一不可能发生的情况就是丢失 key。因此，如果一个客户端执行 MIGRATE 命令遇上 IOERR 错误，那么这个客户端唯一要做的就是检查自己数据库上的 key 是否已经被正确地删除。【！！！】
- 如果在传送数据时发生 IO 错误，或者达到了超时时间，那么命令会停止执行，并返回一个特殊的错误： IOERR。
- 可选项：
- COPY ：不移除源实例上的 key；
- REPLACE ：替换目标实例上已存在的 key；
示例：
- 先启动两个 Redis 服务实例，一个使用默认的 6379 端口，一个使用 7777 端口。
$ ./redis-server & [1] 3557 ... $ ./redis-server --port 7777 & [2] 3560 ...
- 然后用客户端连上 6379 端口的实例，设置一个键，然后将它迁移到 7777 端口的实例上：
$ ./redis-cli redis 127.0.0.1:6379> flushdb OK redis 127.0.0.1:6379> SET greeting "Hello from 6379 instance" OK redis 127.0.0.1:6379> MIGRATE 127.0.0.1 7777 greeting 0 1000 OK redis 127.0.0.1:6379> EXISTS greeting # 迁移成功后 key 被删除 (integer) 0
- 使用另一个客户端，查看 7777 端口上的实例：
$ ./redis-cli -p 7777 redis 127.0.0.1:7777> GET greeting "Hello from 6379 instance"
详述：“sort”
sort：返回或保存给定列表、集合、有序集合 key 中经过排序的元素。
sort <key> [BY pattern] [LIMIT offset count] [GET pattern [GET pattern ...]] [ASC | DESC] [ALPHA] [STORE destination]
- 排序默认以数字作为对象，值被解释为双精度浮点数，然后进行比较。
用法如下：
一般排序
一般用法：“SORT key”和“SORT key DESC”分别返回键值“从小到大”和“从大到小”排序的结果；
redis> LPUSH today_cost 30 1.5 10 8 (integer) 4 redis> SORT today_cost 1) "1.5" 2) "8" 3) "10" 4) "30" redis 127.0.0.1:6379> SORT today_cost DESC 1) "30" 2) "10" 3) "8" 4) "1.5"
对字符串排序
需要对字符串进行排序时， 需要显式地在 SORT 命令之后添加 ALPHA 修饰符；
redis> LPUSH website "www.reddit.com" (integer) 1 redis> LPUSH website "www.slashdot.com" (integer) 2 redis> LPUSH website "www.infoq.com" (integer) 3 redis> SORT website 1) "www.infoq.com" 2) "www.slashdot.com" 3) "www.reddit.com" redis> SORT website ALPHA 1) "www.infoq.com" 2) "www.reddit.com" 3) "www.slashdot.com"
- 如果系统正确地设置了 LC_COLLATE 环境变量的话，Redis能识别 UTF-8 编码。【！】
限制排序结果
排序之后返回元素的数量可以通过 LIMIT 修饰符进行限制， 修饰符可接受两个参数：
- offset：指定要跳过的元素数量；
- count：指定跳过 offset 个指定的元素之后，要返回多少个对象；
redis 127.0.0.1:6379> RPUSH rank 1 3 5 7 9 (integer) 5 redis 127.0.0.1:6379> RPUSH rank 2 4 6 8 10 (integer) 10 redis 127.0.0.1:6379> SORT rank LIMIT 0 5 1) "1" 2) "2" 3) "3" 4) "4" 5) "5" redis 127.0.0.1:6379> SORT rank LIMIT 0 5 DESC 1) "10" 2) "9" 3) "8" 4) "7" 5) "6"
使用外部 key 进行排序
可以使用外部 key 的数据作为权重，代替默认的直接对比键值的方式来进行排序；【！！！】
- 假设现在有用户数据如下：
uid user_name_{uid} user_level_{uid} 1 admin 9999 2 jack 10 3 peter 25 4 mary 70
- 输入到 Redis 中：【如下，保存信息的不同类型 key 之间是有关系的：“uid”的值，可以替换“user_name_{uid}”、“user_level_{uid}”的占位符】
# admin redis 127.0.0.1:6379> LPUSH uid 1 (integer) 1 redis 127.0.0.1:6379> SET user_name_1 admin OK redis 127.0.0.1:6379> SET user_level_1 9999 OK # jack redis 127.0.0.1:6379> LPUSH uid 2 (integer) 2 redis 127.0.0.1:6379> SET user_name_2 jack OK redis 127.0.0.1:6379> SET user_level_2 10 OK # peter redis 127.0.0.1:6379> LPUSH uid 3 (integer) 3 redis 127.0.0.1:6379> SET user_name_3 peter OK redis 127.0.0.1:6379> SET user_level_3 25 OK # mary redis 127.0.0.1:6379> LPUSH uid 4 (integer) 4 redis 127.0.0.1:6379> SET user_name_4 mary OK redis 127.0.0.1:6379> SET user_level_4 70 OK
- 默认情况下， SORT uid 直接按 uid 中的值排序：
redis 127.0.0.1:6379> SORT uid 1) "1" # admin 2) "2" # jack 3) "3" # peter 4) "4" # mary
- 使用 BY 选项，可以让 uid 按其他键的元素来排序：
# 让 uid 键按照 user_level_{uid} 的大小来排序 redis 127.0.0.1:6379> SORT uid BY user_level_* 1) "2" # jack , level = 10 2) "3" # peter, level = 25 3) "4" # mary, level = 70 4) "1" # admin, level = 9999
- 【上例中“user_level_*”是一个占位符， 它先取出 uid 中的值， 然后再用这个值来查找相应的键】
- 【如：先取出 uid 的值 1、2、3、4 ，然后使用 user_level_1、user_level_2、user_level_3、user_level_4 的值作为排序 uid 的权重】
- 使用 GET 选项，可以根据排序的结果来取出相应的键值：
# 先排序 uid ， 再取出键 user_name_{uid} 的值 redis 127.0.0.1:6379> SORT uid GET user_name_* 1) "admin" 2) "jack" 3) "peter" 4) "mary"
- 组合使用 BY 和 GET，可以让排序结果以更直观的方式显示出来：
# 先按 user_level_{uid} 来排序 uid 列表， 再取出相应的 user_name_{uid} 的值 redis 127.0.0.1:6379> SORT uid BY user_level_* GET user_name_* 1) "jack" # level = 10 2) "peter" # level = 25 3) "mary" # level = 70 4) "admin" # level = 9999
- 同时使用多个 GET 选项， 获取多个外部键的值：
# 按 uid 分别获取 user_level_{uid} 和 user_name_{uid} redis 127.0.0.1:6379> SORT uid GET user_level_* GET user_name_* 1) "9999" # level 2) "admin" # name 3) "10" 4) "jack" 5) "25" 6) "peter" 7) "70" 8) "mary"
- GET 选项可以用 “#” 获取被排序键的值：
redis 127.0.0.1:6379> SORT uid GET # GET user_level_* GET user_name_* 1) "1" # uid 2) "9999" # level 3) "admin" # name 4) "2" 5) "10" 6) "jack" 7) "3" 8) "25" 9) "peter" 10) "4" 11) "70" 12) "mary"
- 通过将一个不存在的键作为参数传给 BY 选项， 可以让 SORT 跳过排序操作， 直接返回结果：【获取外部键，但不进行排序】
redis 127.0.0.1:6379> SORT uid BY not-exists-key 1) "4" 2) "3" 3) "2" 4) "1"
- 【这种用法在单独使用时，没什么实际用处。——不过，将其与 GET 选项配合，就可以在不排序的情况下，获取多个外部键，相当于执行一个整合的获取操作（类似于 SQL 数据库的 “join” 关键字）】
redis 127.0.0.1:6379> SORT uid BY not-exists-key GET # GET user_level_* GET user_name_* 1) "4" # id 2) "70" # level 3) "mary" # name 4) "3" 5) "25" 6) "peter" 7) "2" 8) "10" 9) "jack" 10) "1" 11) "9999" 12) "admin"
- 除了可以将字符串键之外， 哈希表也可以作为 GET 或 BY 选项的参数来使用：【将哈希表作为 GET 或 BY 的参数】
- 对于上述数据，用一个带有 “name” 域和 “level” 域的哈希表 “user_info_{uid}” 来保存用户的名字和级别信息：
redis 127.0.0.1:6379> LPUSH uid 1 (integer) 1 redis 127.0.0.1:6379> LPUSH uid 2 (integer) 1 redis 127.0.0.1:6379> LPUSH uid 3 (integer) 1 redis 127.0.0.1:6379> LPUSH uid 4 (integer) 1 redis 127.0.0.1:6379> HMSET user_info_1 name admin level 9999 OK redis 127.0.0.1:6379> HMSET user_info_2 name jack level 10 OK redis 127.0.0.1:6379> HMSET user_info_3 name peter level 25 OK redis 127.0.0.1:6379> HMSET user_info_4 name mary level 70 OK
- 则，BY 和 GET 选项都可以用 key->field 的格式来获取哈希表中的域的值， 其中 key 表示哈希表键， 而 field 则表示哈希表的域：
redis 127.0.0.1:6379> SORT uid BY user_info_*->level 1) "2" 2) "3" 3) "4" 4) "1" redis 127.0.0.1:6379> SORT uid BY user_info_*->level GET user_info_*->name 1) "jack" 2) "peter" 3) "mary" 4) "admin"
保存排序结果
通过给 STORE 选项指定一个 key 参数，可以将排序结果保存到给定的键上：
- 默认情况下， SORT 操作只是简单地返回排序结果，并不进行任何保存操作；
- 如果被指定的 key 已存在，那么原有的值将被排序结果覆盖；
redis 127.0.0.1:6379> RPUSH numbers 1 3 5 7 9 (integer) 5 redis 127.0.0.1:6379> RPUSH numbers 2 4 6 8 10 (integer) 10 redis 127.0.0.1:6379> LRANGE numbers 0 -1 1) "1" 2) "3" 3) "5" 4) "7" 5) "9" 6) "2" 7) "4" 8) "6" 9) "8" 10) "10" redis 127.0.0.1:6379> SORT numbers STORE sorted-numbers (integer) 10 redis 127.0.0.1:6379> LRANGE sorted-numbers 0 -1 1) "1" 2) "2" 3) "3" 4) "4" 5) "5" 6) "6" 7) "7" 8) "8" 9) "9" 10) "10"
- 【可以通过将 SORT 命令的执行结果保存，并用 EXPIRE 为结果设置生存时间，以此来产生一个 SORT 操作的结果缓存。】？？？
- （这样就可以避免对 SORT 操作的频繁调用：只有当结果集过期时，才需要再调用一次 SORT 操作）
- 【为了正确实现这一用法，可能需要加锁以避免多个客户端同时进行缓存重建（也就是多个客户端，同一时间进行 SORT 操作，并保存为结果集），具体参见 SETNX 命令】？？？
详述：“scan”
scan：SCAN 命令及其相关的 SSCAN 命令、 HSCAN 命令和 ZSCAN 命令都用于增量地迭代（incrementally iterate）一集元素（a collection of elements）：
- “SCAN”：用于迭代当前数据库中的数据库键；
- “HSCAN”：用于迭代哈希（“hash”）键中的键值对；
- “SSCAN”：用于迭代集合（“set”）键中的元素；
- “ZSCAN”：用于迭代有序集合（“zset”）中的元素（包括元素成员和元素分值）。
四者的区别：
- 参数：
- HSCAN、SSCAN、ZSCAN 命令的第一个参数总是一个数据库键；
- 而 SCAN 命令则不需要在第一个参数提供任何数据库键，因为它迭代的是当前数据库中的所有键。
- 返回值：
- SCAN 返回的每个元素都是一个数据库键。
- HSCAN 返回的每个元素都是一个键值对，一个键值对由一个键和一个值组成。
- SSCAN 返回的每个元素都是一个集合成员。
- ZSCAN 返回的每个元素都是一个有序集合元素，一个有序集合元素由一个成员（member）和一个分值（score）组成。
以上列出的四个命令都支持增量式迭代， 它们每次执行都只会返回少量元素， 所以这些命令可以用于生产环境， 而不会出现像 “KEYS” 命令、 “SMEMBERS” 命令带来的问题 —— 当 KEYS 命令被用于处理一个大的数据库时， 又或者 SMEMBERS 命令被用于处理一个大的集合键时， 它们可能会阻塞服务器达数秒之久。 不过， 增量式迭代命令也不是没有缺点的：举个例子，使用 SMEMBERS 命令可以返回集合键当前包含的所有元素，但是对于 SCAN 这类增量式迭代命令来说，因为在对键进行增量式迭代的过程中，键可能会被修改，所以增量式迭代命令【只能对被返回的元素提供有限的保证（offer limited guarantees about the returned elements）】。
基本用法
scan <cursor> [MATCH <pattern>] [COUNT <count>]
SCAN 命令是一个基于游标的迭代器（cursor based iterator）：
SCAN 命令每次被调用之后，都会向用户返回一个新的【游标】，用户在下次迭代时需要使用这个新游标作为 SCAN 命令的游标参数，以此来延续之前的迭代过程。
- 当 SCAN 命令的游标参数被设置为 0 时， 服务器将开始一次新的迭代， 而当服务器向用户返回值为 0 的游标时， 表示迭代已结束；
- 以 0 作为游标开始一次新的迭代， 一直调用 SCAN 命令， 直到命令返回游标 0 ， 我们称这个过程为一次完整遍历（full iteration）。
- SCAN 命令的回复是一个包含两个元素的数组：
- 第一个数组元素：用于进行下一次迭代的新游标；
- 第二个数组元素：数组，包含了所有被迭代的元素。
示例：
redis 127.0.0.1:6379> scan 0 1) "17" 2) 1) "key:12" 2) "key:8" 3) "key:4" 4) "key:14" 5) "key:16" 6) "key:17" 7) "key:15" 8) "key:10" 9) "key:3" 10) "key:7" 11) "key:1" redis 127.0.0.1:6379> scan 17 1) "0" 2) 1) "key:5" 2) "key:18" 3) "key:0" 4) "key:2" 5) "key:19" 6) "key:13" 7) "key:6" 8) "key:9" 9) "key:11"
- 第一次迭代使用 0 作为游标， 表示开始一次新的迭代；
- 第二次迭代使用的是第一次迭代时返回的游标， 也即是命令回复第一个元素的值 —— 17。
迭代的保证
迭代命令的保证：
SCAN 命令，以及其他增量式迭代命令，在进行完整遍历的情况下可以为用户带来以下保证：
从完整遍历开始直到完整遍历结束期间，一直存在于数据集内的所有元素都会被完整遍历返回； 【这意味着：如果有一个元素，它从遍历开始直到遍历结束期间都存在于被遍历的数据集当中，那么 SCAN 命令总会在某次迭代中将这个元素返回给用户。】
然而因为增量式命令仅仅使用游标来记录迭代状态， 所以这些命令带有以下缺点：
1、【同一个元素可能会被返回多次】。——处理重复元素的工作交由应用程序负责，比如说，可以考虑将迭代返回的元素仅仅用于可以安全地重复执行多次的操作上。 2、【如果一个元素是在迭代过程中被添加到数据集的，又或者是在迭代过程中从数据集中被删除的，那么这个元素可能会被返回，也可能不会，这是未定义的（undefined）】。
迭代终结的保证：
增量式迭代命令所使用的算法只保证【在数据集的大小有界（bounded）的情况下，迭代才会停止】，换句话说，如果被迭代数据集的大小不断地增长的话，增量式迭代命令可能永远也无法完成一次完整迭代。
从直觉上可以看出， 当一个数据集不断地变大时， 想要访问这个数据集中的所有元素就需要做越来越多的工作， 能否结束一个迭代取决于用户执行迭代的速度是否比数据集增长的速度更快。
每次执行返回的元素数量
1、增量式迭代命令【并不保证每次执行都返回某个给定数量的元素】。
2、增量式命令甚至可能会返回零个元素，但【只要命令返回的游标不是 0，应用程序就不应该将迭代视作结束】。
不过命令返回的元素数量总是符合一定规则的， 在实际中：
1、对于一个大数据集来说， 增量式迭代命令每次最多可能会返回数十个元素；
2、对于一个足够小的数据集来说，如果这个数据集的底层表示为编码数据结构（encoded data structure，适用于是小集合键、小哈希键和小有序集合键），那么增量迭代命令将在一次调用中返回数据集中的所有元素。
最后， 用户可以通过增量式迭代命令提供的 【“COUNT” 选项，来指定每次迭代返回元素的最大值】。
COUNT 选项
COUNT选项：用于告知命令在每次迭代中应该从数据集里返回多少元素。
- COUNT 参数的默认值为 10；
- COUNT 选项只是对增量式迭代命令的一种提示（hint），但是在大多数情况下，这种提示都是有效的：
- 在迭代一个足够大的、由哈希表实现的数据库、集合键、哈希键或者有序集合键时，如果用户没有使用MATCH选项，那么命令返回的元素数量通常和 COUNT 选项指定的一样，或者比 COUNT 选项指定的数量稍多一些。
- 在迭代一个编码为整数集合（intset，一个只由整数值构成的小集合）、 或者编码为压缩列表（ziplist，由不同值构成的一个小哈希或者一个小有序集合）时， 增量式迭代命令通常会无视 COUNT 选项指定的值， 在第一次迭代就将数据集包含的所有元素都返回给用户。
- 并非每次迭代都要使用相同的 COUNT 值：用户可以在每次迭代中按自己的需要随意改变 COUNT 值， 只要记得将上次迭代返回的游标用到下次迭代里面就可以了。
MATCH 选项
MATCH选项：用于让命令只返回和给定模式相匹配的元素。
示例：
redis 127.0.0.1:6379> sadd myset 1 2 3 foo foobar feelsgood (integer) 6 redis 127.0.0.1:6379> sscan myset 0 match f* 1) "0" 2) 1) "foo" 2) "feelsgood" 3) "foobar"
- 对元素的模式匹配工作是在命令从数据集中取出元素之后，向客户端返回元素之前的这段时间内进行的，所以如果被迭代的数据集中只有少量元素和模式相匹配，那么迭代命令或许会在多次执行中都不返回任何元素。
redis 127.0.0.1:6379> scan 0 MATCH *11* 1) "288" 2) 1) "key:911" redis 127.0.0.1:6379> scan 288 MATCH *11* 1) "224" 2) (empty list or set) redis 127.0.0.1:6379> scan 224 MATCH *11* 1) "80" 2) (empty list or set) redis 127.0.0.1:6379> scan 80 MATCH *11* 1) "176" 2) (empty list or set) redis 127.0.0.1:6379> scan 176 MATCH *11* COUNT 1000 1) "0" 2) 1) "key:611" 2) "key:711" 3) "key:118" 4) "key:117" 5) "key:311" 6) "key:112" 7) "key:111" 8) "key:110" 9) "key:113" 10) "key:211" 11) "key:411" 12) "key:115" 13) "key:116" 14) "key:114" 15) "key:119" 16) "key:811" 17) "key:511" 18) "key:11"
并发执行、终止迭代
客户端每次执行迭代都需要传入一个游标，并在迭代执行之后获得一个新的游标，而这个游标就包含了迭代的所有状态，所以，【服务器无须为迭代记录任何状态】。 正因如此： 1、【在同一时间，可以有任意多个客户端对同一数据集进行迭代】。 2、【客户端可以在中途停止一个迭代，而无须对服务器进行任何通知】，即使有任意数量的迭代在中途停止， 也不会产生任何问题。
使用错误的游标进行增量式迭代
使用间断的（broken）、负数、超出范围或者其他“非正常的游标”来执行增量式迭代并【不会造成服务器崩溃，但可能会让命令产生“未定义的行为”（增量式命令对返回值所做的保证可能会不再为真）】。 只有两种游标是合法的： 1、在开始一个新的迭代时，游标必须为 0。 2、增量式迭代命令在执行之后返回的，用于延续（continue）迭代过程的游标。
数据类型
- 见：
Pub/Sub（发布/订阅）
- 见：“Redis：发布/订阅”
Transaction（事务）
- 见：“Redis：事务”
Script（脚本）
Redis 脚本使用 Lua 解释器来执行脚本。 Redis 2.6 版本通过内嵌支持 Lua 环境。执行脚本的常用命令为 EVAL。
Eval 命令的基本语法如下：
redis 127.0.0.1:6379> EVAL script numkeys key [key ...] arg [arg ...]
下表列出了 redis 脚本常用命令：
| 命令 | 描述 |
|---|---|
| EVAL <script> numkeys <key> [<key>] <arg> [<arg>] | 执行 Lua 脚本。 |
| EVALSHA sha1 numkeys <key> [<key>] <arg> [<arg>] | 执行 Lua 脚本。【？】 |
| SCRIPT LOAD <script> | 将脚本 script 添加到脚本缓存中，但并不立即执行这个脚本。 |
| SCRIPT EXISTS <script> [<script>] | 查看指定的脚本是否已经被保存在缓存当中。 |
| SCRIPT FLUSH | 从脚本缓存中移除所有脚本。 |
| SCRIPT KILL | 杀死当前正在运行的 Lua 脚本。 |
示例：
redis 127.0.0.1:6379> EVAL "return {KEYS[1],KEYS[2],ARGV[1],ARGV[2]}" 2 key1 key2 first second
1) "key1"
2) "key2"
3) "first"
4) "second"
Connection（连接）
Redis 连接命令主要是用于连接 redis 服务：
| 命令 | 描述 |
|---|---|
| AUTH <password> | 验证密码是否正确 |
| ECHO <message> | 打印字符串 |
| PING | 查看服务是否运行 |
| QUIT | 关闭当前连接 |
| SELECT <index> | 切换到指定的数据库 |
示例：
redis 127.0.0.1:6379> AUTH "password"
OK
redis 127.0.0.1:6379> PING
PONG
Server（服务器）
Redis 服务器命令主要是用于管理 redis 服务：
| 命令 | 描述 |
|---|---|
| INFO [section] | 获取 Redis 服务器的各种信息和统计数值 |
| MONITOR | 实时打印出 Redis 服务器接收到的命令，调试用 |
| DBSIZE | 返回当前数据库的 key 的数量 |
| FLUSHALL | 删除所有数据库的所有key |
| FLUSHDB | 删除当前数据库的所有key |
| TIME | 返回当前服务器时间 |
| LASTSAVE | 返回最近一次 Redis 成功将数据保存到磁盘上的时间，以 UNIX 时间戳格式表示 |
| SAVE | 同步保存数据到硬盘 |
| BGSAVE | 在后台异步保存当前数据库的数据到磁盘 |
| BGREWRITEAOF | 异步执行一个 AOF（AppendOnly File） 文件重写操作 |
| SHUTDOWN [NOSAVE] [SAVE] | 异步保存数据到硬盘，并关闭服务器 |
| COMMAND | 获取 Redis 命令详情数组 |
| COMMAND COUNT | 获取 Redis 命令总数 |
| COMMAND GETKEYS | 获取给定命令的所有键 |
| COMMAND INFO <command-name> [<command-name>] | 获取指定 Redis 命令描述的数组 |
| CLIENT LIST | 获取连接到服务器的客户端连接列表 |
| CLIENT GETNAME | 获取连接的名称 |
| CLIENT PAUSE <timeout> | 在指定时间内终止运行来自客户端的命令 |
| CLIENT SETNAME <connection-name> | 设置当前连接的名称 |
| CLIENT KILL [ip:port] [ID client-id] | 关闭客户端连接 |
| CONFIG GET <parameter> | 获取指定配置参数的值 |
| CONFIG REWRITE | 对启动 Redis 服务器时所指定的 redis.conf 配置文件进行改写 |
| CONFIG SET <parameter> <value> | 修改 redis 配置参数，无需重启 |
| CONFIG RESETSTAT | 重置 INFO 命令中的某些统计数据 |
| DEBUG OBJECT <key> | 获取 key 的调试信息 |
| DEBUG SEGFAULT | 让 Redis 服务崩溃【？？？】 |
| SLOWLOG <subcommand> [argument] | 管理 redis 的慢日志 |
| CLUSTER SLOTS | 获取集群节点的映射数组 |
| ROLE | 返回主从实例所属的角色 |
| SLAVEOF <host> <port> | 将当前服务器转变为指定服务器的从属服务器(slave server) |
| SYNC | 用于复制功能（replication）的内部命令 |
以下实例演示了如何获取 redis 服务器的统计信息：
redis 127.0.0.1:6379> INFO
# Server
redis_version:2.8.13
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:c2238b38b1edb0e2
redis_mode:standalone
os:Linux 3.5.0-48-generic x86_64
arch_bits:64
multiplexing_api:epoll
gcc_version:4.7.2
process_id:3856
run_id:0e61abd297771de3fe812a3c21027732ac9f41fe
tcp_port:6379
uptime_in_seconds:11554
uptime_in_days:0
hz:10
lru_clock:16651447
config_file:
# Clients
connected_clients:1
client-longest_output_list:0
client-biggest_input_buf:0
blocked_clients:0
# Memory
used_memory:589016
used_memory_human:575.21K
used_memory_rss:2461696
used_memory_peak:667312
used_memory_peak_human:651.67K
used_memory_lua:33792
mem_fragmentation_ratio:4.18
mem_allocator:jemalloc-3.6.0
# Persistence
loading:0
rdb_changes_since_last_save:3
rdb_bgsave_in_progress:0
rdb_last_save_time:1409158561
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:0
rdb_current_bgsave_time_sec:-1
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
# Stats
total_connections_received:24
total_commands_processed:294
instantaneous_ops_per_sec:0
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:0
evicted_keys:0
keyspace_hits:41
keyspace_misses:82
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:264
# Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
# CPU
used_cpu_sys:10.49
used_cpu_user:4.96
used_cpu_sys_children:0.00
used_cpu_user_children:0.01
# Keyspace
db0:keys=94,expires=1,avg_ttl=41638810
db1:keys=1,expires=0,avg_ttl=0
db3:keys=1,expires=0,avg_ttl=0