Redis 中文文档

目錄

介紹							0
Redis 文档							1
	键空间通知（keyspace notification）					1.1
	事务（transaction）		1.2
	发布与订阅（pub/sub）		1.3
	复制（Replication）		1.4
	通信协议（protocol）		1.5
	持久化（persistence）					1.6
	Sentinel		1.7
	集群教程		1.8
	Redis 集群规范		1.9
Redis 命令参考			2
	Key（键）					2.1
		DEL	2.1.1
		DUMP	2.1.2
		EXISTS	2.1.3
		EXPIRE	2.1.4
		EXPIREAT			2.1.5
		KEYS	2.1.6
		MIGRATE	2.1.7
		MOVE	2.1.8
		OBJECT	2.1.9
		PERSIST	2.1.10
		PEXPIRE	2.1.11
		PEXPIREAT	2.1.12
		PTTL	2.1.13
		RANDOMKEY	2.1.14
		RENAME	2.1.15
		RENAMENX	2.1.16
		RESTORE	2.1.17

2

Redis 中文文档

		SORT	2.1.18
		TYPE	2.1.19
		SCAN	2.1.20
String（字符串）			2.2
		APPEND	2.2.1
		BITCOUNT			2.2.2
		BITOP	2.2.3
		DECR	2.2.4
		DECRBY	2.2.5
		GET	2.2.6
		GETBIT			2.2.7
		GETRANGE			2.2.8
		GETSET	2.2.9
		INCR	2.2.10
		INCRBY	2.2.11
		INCRBYFLOAT	2.2.12
		MGET	2.2.13
		MSET	2.2.14
		MSETNX	2.2.15
		PSETEX	2.2.16
		SET	2.2.17
		SETBIT	2.2.18
		SETEX	2.2.19
		SETNX	2.2.20
		SETRANGE	2.2.21
		STRLEN	2.2.22
Hash（哈希表）			2.3
		HDEL	2.3.1
		HEXISTS	2.3.2
		HGET	2.3.3
		HGETALL	2.3.4
		HINCRBY			2.3.5
		HINCRBYFLOAT	2.3.6
		HKEYS	2.3.7

3

Redis 中文文档

	HLEN			2.3.8
	HMGET	2.3.9
	HMSET	2.3.10
	HSET	2.3.11
	HSETNX	2.3.12
	HVALS	2.3.13
	HSCAN	2.3.14
List（列表）		2.4
	BLPOP	2.4.1
	BRPOP			2.4.2
	BRPOPLPUSH			2.4.3
	LINDEX	2.4.4
	LINSERT	2.4.5
	LLEN	2.4.6
	LPOP	2.4.7
	LPUSH			2.4.8
	LRANGE	2.4.9
	LREM	2.4.10
	LSET	2.4.11
	LTRIM	2.4.12
	RPOP	2.4.13
	RPOPLPUSH	2.4.14
	RPUSH	2.4.15
	RPUSHX	2.4.16
Set（集合）		2.5
	SADD			2.5.1
	SCARD	2.5.2
	SDIFF	2.5.3
	SDIFFSTORE	2.5.4
	SINTER	2.5.5
	SINTER			2.5.6
	SINTERSTORE	2.5.7
	SISMEMBER	2.5.8

4

Redis 中文文档

		SMEMBERS			2.5.9
		SMOVE	2.5.10
		SPOP	2.5.11
		SRANDMEMBER	2.5.12
		SREM	2.5.13
		SUNION	2.5.14
		SUNIONSTORE	2.5.15
		SSCAN	2.5.16
	SortedSet（有序集合）		2.6
		ZADD	2.6.1
		ZCARD			2.6.2
		ZCOUNT			2.6.3
		ZINCRBY	2.6.4
		ZRANGE	2.6.5
		ZRANGEBYSCORE	2.6.6
		ZRANK	2.6.7
		ZREM			2.6.8
		ZREMRANGEBYRANK	2.6.9
		ZREMRANGEBYSCORE	2.6.10
		ZREVRANGE	2.6.11
		ZREVRANGEBYSCORE	2.6.12
		ZREVRANK	2.6.13
		ZSCORE	2.6.14
		ZUNIONSTORE	2.6.15
		ZINTERSTORE	2.6.16
		ZSCAN	2.6.17
	Pub/Sub（发布/订阅）					2.7
		PSUBSCRIBE	2.7.1
		PUBLISH	2.7.2
		PUBSUB	2.7.3
		PUNSUBSCRIBE	2.7.4
		SUBSCRIBE			2.7.5
		UNSUBSCRIBE	2.7.6
	Transaction（事务）		2.8

5

Redis 中文文档

	DISCARD				2.8.1
	EXEC	2.8.2
	MULTI	2.8.3
	UNWATCH	2.8.4
	WATCH				2.8.5
Script（脚本）		2.9
	EVAL	2.9.1
	EVALSHA	2.9.2
	SCRIPT EXISTS	2.9.3
	SCRIPT FLUSH				2.9.4
	SCRIPT KILL				2.9.5
	SCRIPT LOAD	2.9.6
Connection（连接）		2.10
	AUTH	2.10.1
	ECHO	2.10.2
	PING			2.10.3
	QUIT	2.10.4
	SELECT	2.10.5
Server（服务器）		2.11
	BGREWRITEAOF	2.11.1
	BGSAVE			2.11.2
	CLIENT GETNAME	2.11.3
	CLIENT KILL	2.11.4
	CLIENT LIST	2.11.5
	CLIENT SETNAME	2.11.6
	CONFIG GET			2.11.7
	CONFIG RESETSTAT	2.11.8
	CONFIG REWRITE	2.11.9
	CONFIG SET	2.11.10
	DBSIZE	2.11.11
	DEBUG OBJECT	2.11.12
	DEBUG SEGFAULT	2.11.13
	FLUSHALL	2.11.14

6

Redis 中文文档

	FLUSHDB		2.11.15
	INFO		2.11.16
	LASTSAVE		2.11.17
	MONITOR		2.11.18
	PSYNC		2.11.19
	SAVE		2.11.20
	SHUTDOWN		2.11.21
	SLAVEOF		2.11.22
	SLOWLOG		2.11.23
	SYNC		2.11.24
	TIME		2.11.25
关于				3

7

Redis 中文文档

Redis 中文文档

译者：黄健宏（huangz）

来源：Redis 命令参考

本文档是 Redis Command Reference 和 Redis Documentation 的中文翻译版， 阅读这个文 档可以帮助你了解 Redis 命令的具体使用方法， 并学会如何使用 Redis 的事务、持久化、复 制、Sentinel、集群等功能。

由本文档译者制作的《Redis命令速查表》正在销售中！ 该表能够与本文档相辅相成， 帮助读者更好地了解和查阅 Redis 命令，有兴趣的读者可以通过访问以下链接来了解更 多信息： https://selfstore.io/products/538

介紹

8

Redis 中文文档

Redis 文档

Redis 文档

9

Redis 中文文档

键空间通知（keyspace notification）)

Note

本文档翻译自： http://redis.io/topics/notifications 。

Warning

键空间通知功能目前仍在开发中，这个文档所描述的内容，以及功能的具体实现，可能会在 未来数周内改变，敬请知悉。

功能概览

键空间通知使得客户端可以通过订阅频道或模式， 来接收那些以某种方式改动了 Redis 数据 集的事件。

以下是一些键空间通知发送的事件的例子：

所有修改键的命令。

所有接收到 LPUSH 命令的键。 0 号数据库中所有已过期的键。

事件通过 Redis 的订阅与发布功能（pub/sub）来进行分发， 因此所有支持订阅与发布功能 的客户端都可以在无须做任何修改的情况下， 直接使用键空间通知功能。

因为 Redis 目前的订阅与发布功能采取的是发送即忘（fire and forget）策略， 所以如果你的 程序需要可靠事件通知（reliable notification of events）， 那么目前的键空间通知可能并不适 合你： 当订阅事件的客户端断线时， 它会丢失所有在断线期间分发给它的事件。

未来将会支持更可靠的事件分发， 这种支持可能会通过让订阅与发布功能本身变得更可靠来 实现， 也可能会在 Lua 脚本中对消息（message）的订阅与发布进行监听， 从而实现类似将 事件推入到列表这样的操作。

事件的类型

对于每个修改数据库的操作，键空间通知都会发送两种不同类型的事件。

比如说，对 0 号数据库的键 mykey 执行 DEL 命令时， 系统将分发两条消息， 相当于执行 以下两个 PUBLISH 命令：

PUBLISH __keyspace@0__:mykey del

PUBLISH __keyevent@0__:del mykey

键空间通知（keyspace notification）

10

Redis 中文文档

订阅第一个频道 __keyspace@0__:mykey 可以接收 0 号数据库中所有修改键 mykey 的事 件， 而订阅第二个频道 __keyevent@0__:del 则可以接收 0 号数据库中所有执行 del 命令

的键。

以keyspace 为前缀的频道被称为键空间通知（key-space notification）， 而以 keyevent 为前缀的频道则被称为键事件通知（key-event notification）。

当del mykey 命令执行时：

键空间频道的订阅者将接收到被执行的事件的名字，在这个例子中，就是 del 。

键事件频道的订阅者将接收到被执行事件的键的名字，在这个例子中，就是 mykey 。

配置

因为开启键空间通知功能需要消耗一些 CPU ， 所以在默认配置下， 该功能处于关闭状态。

可以通过修改 redis.conf 文件， 或者直接使用 CONFIG SET 命令来开启或关闭键空间通知 功能：

当 notify-keyspace-events 选项的参数为空字符串时，功能关闭。

另一方面，当参数不是空字符串时，功能开启。

notify-keyspace-events 的参数可以是以下字符的任意组合， 它指定了服务器该发送哪些类 型的通知：

字符

发送的通知

K键空间通知，所有通知以 __keyspace@<db>__ 为前缀

E键事件通知，所有通知以 __keyevent@<db>__ 为前缀

gDEL 、 EXPIRE 、 RENAME 等类型无关的通用命令的通知

$字符串命令的通知

l列表命令的通知

s集合命令的通知

h哈希命令的通知

z有序集合命令的通知

x过期事件：每当有过期键被删除时发送

e驱逐(evict)事件：每当有键因为 maxmemory 政策而被删除时发送

A参数 g$lshzxe 的别名

输入的参数中至少要有一个 K 或者 E ， 否则的话， 不管其余的参数是什么， 都不会有任 何通知被分发。

键空间通知（keyspace notification）

11

Redis 中文文档

举个例子， 如果只想订阅键空间中和列表相关的通知， 那么参数就应该设为 Kl ， 诸如此 类。

将参数设为字符串 "AKE" 表示发送所有类型的通知。

命令产生的通知

以下列表记录了不同命令所产生的不同通知：

DEL 命令为每个被删除的键产生一个 del 通知。

RENAME 产生两个通知：为来源键（source key）产生一个 rename_from 通知，并为目 标键（destination key）产生一个 rename_to 通知。

EXPIRE 和 EXPIREAT 在键被正确设置过期时间时产生一个 expire 通知。当 EXPIREAT 设置的时间已经过期，或者 EXPIRE 传入的时间为负数值时，键被删除，并 产生一个 del 通知。

SORT 在命令带有 STORE 参数时产生一个 sortstore 事件。如果 STORE 指示的用于保 存排序结果的键已经存在，那么程序还会发送一个 del 事件。

SET 以及它的所有变种（SETEX 、 SETNX 和 GETSET）都产生 set 通知。其中

SETEX 还会产生 expire 通知。

MSET 为每个键产生一个 set 通知。

SETRANGE 产生一个 setrange 通知。

INCR 、 DECR 、 INCRBY 和 DECRBY 都产生 incrby 通知。

INCRBYFLOAT 产生 incrbyfloat 通知。

APPEND 产生 append 通知。

LPUSH 和 LPUSHX 都产生单个 lpush 通知，即使有多个输入元素时，也是如此。 RPUSH 和 RPUSHX 都产生单个 rpush 通知，即使有多个输入元素时，也是如此。 RPOP 产生 rpop 通知。如果被弹出的元素是列表的最后一个元素，那么还会产生一个

del 通知。

LPOP 产生 lpop 通知。如果被弹出的元素是列表的最后一个元素，那么还会产生一个

del 通知。

LINSERT 产生一个 linsert 通知。

LSET 产生一个 lset 通知。

LTRIM 产生一个 ltrim 通知。如果 LTRIM 执行之后，列表键被清空，那么还会产生一

个del 通知。

RPOPLPUSH 和 BRPOPLPUSH 产生一个 rpop 通知，以及一个 lpush 通知。两个命 令都会保证 rpop 的通知在 lpush 的通知之前分发。如果从键弹出元素之后，被弹出 的列表键被清空，那么还会产生一个 del 通知。

HSET 、 HSETNX 和 HMSET 都只产生一个 hset 通知。

HINCRBY 产生一个 hincrby 通知。

HINCRBYFLOAT 产生一个 hincrbyfloat 通知。

HDEL 产生一个 hdel 通知。如果执行 HDEL 之后，哈希键被清空，那么还会产生一个

键空间通知（keyspace notification）

12

Redis 中文文档

del 通知。

SMOVE 为来源键（source key）产生一个 srem 通知，并为目标键（destination key） 产生一个 sadd 事件。

SPOP 产生一个 spop 事件。如果执行 SPOP 之后，集合键被清空，那么还会产生一个

del 通知。

SINTERSTORE 、 SUNIONSTORE 和 SDIFFSTORE 分别产生 sinterstore 、

sunionostore 和 sdiffstore 三种通知。如果用于保存结果的键已经存在，那么还会产

生一个 del 通知。

ZINCRBY 产生一个 zincr 通知。（译注：非对称，请注意。） ZADD 产生一个 zadd 通知，即使有多个输入元素时，也是如此。

ZREM 产生一个 zrem 通知，即使有多个输入元素时，也是如此。如果执行 ZREM 之 后，有序集合键被清空，那么还会产生一个 del 通知。

ZREMRANGEBYSCORE 产生一个 zrembyscore 通知。（译注：非对称，请注意。） 如果用于保存结果的键已经存在，那么还会产生一个 del 通知。 ZREMRANGEBYRANK 产生一个 zrembyrank 通知。（译注：非对称，请注意。）如果 用于保存结果的键已经存在，那么还会产生一个 del 通知。

ZINTERSTORE 和 ZUNIONSTORE 分别产生 zinterstore 和 zunionstore 两种通知。 如果用于保存结果的键已经存在，那么还会产生一个 del 通知。

每当一个键因为过期而被删除时，产生一个 expired 通知。

每当一个键因为 maxmemory 政策而被删除以回收内存时，产生一个 evicted 通知。

Note

所有命令都只在键真的被改动了之后，才会产生通知。

比如说，当 SREM 试图删除不存在于集合的元素时，删除操作会执行失败，因为没有真正的 改动键，所以这一操作不会发送通知。

如果对命令所产生的通知有疑问， 最好还是使用以下命令， 自己来验证一下：

$redis-cli config set notify-keyspace-events KEA

$redis-cli --csv psubscribe '__key*__:*' Reading messages... (press Ctrl-C to quit) "psubscribe","__key*__:*",1

然后， 只要在其他终端里用 Redis 客户端发送命令， 就可以看到产生的通知了：

"pmessage","__key*__:*","__keyspace@0__:foo","set" "pmessage","__key*__:*","__keyevent@0__:set","foo"

...

键空间通知（keyspace notification）

13

Redis 中文文档

过期通知的发送时间

Redis 使用以下两种方式删除过期的键：

当一个键被访问时，程序会对这个键进行检查，如果键已经过期，那么该键将被删除。 底层系统会在后台渐进地查找并删除那些过期的键，从而处理那些已经过期、但是不会 被访问到的键。

当过期键被以上两个程序的任意一个发现、 并且将键从数据库中删除时， Redis 会产生一个

expired 通知。

Redis 并不保证生存时间（TTL）变为 0 的键会立即被删除： 如果程序没有访问这个过期 键， 或者带有生存时间的键非常多的话， 那么在键的生存时间变为 0 ， 直到键真正被删除 这中间， 可能会有一段比较显著的时间间隔。

因此， Redis 产生 expired 通知的时间为过期键被删除的时候， 而不是键的生存时间变为

0的时候。

键空间通知（keyspace notification）

14

Redis 中文文档

事务（transaction）

Note

本文档翻译自： http://redis.io/topics/transactions 。

MULTI 、 EXEC 、 DISCARD 和 WATCH 是 Redis 事务的基础。

事务可以一次执行多个命令， 并且带有以下两个重要的保证：

事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执 行的过程中，不会被其他客户端发送来的命令请求所打断。

事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。

EXEC 命令负责触发并执行事务中的所有命令：

如果客户端在使用 MULTI 开启了一个事务之后，却因为断线而没有成功执行 EXEC

，那么事务中的所有命令都不会被执行。

另一方面，如果客户端成功在开启事务之后执行 EXEC ，那么事务中的所有命令都 会被执行。

当使用 AOF 方式做持久化的时候， Redis 会使用单个 write(2) 命令将事务写入到磁盘 中。

然而，如果 Redis 服务器因为某些原因被管理员杀死，或者遇上某种硬件故障，那么可 能只有部分事务命令会被成功写入到磁盘中。

如果 Redis 在重新启动时发现 AOF 文件出了这样的问题，那么它会退出，并汇报一个错 误。

使用 redis-check-aof 程序可以修复这一问题：它会移除 AOF 文件中不完整事务的信 息，确保服务器可以顺利启动。

从2.2 版本开始，Redis 还可以通过乐观锁（optimistic lock）实现 CAS （check-and-set）操 作，具体信息请参考文档的后半部分。

用法

MULTI 命令用于开启一个事务，它总是返回 OK 。

MULTI 执行之后， 客户端可以继续向服务器发送任意多条命令， 这些命令不会立即被执行， 而是被放到一个队列中， 当 EXEC 命令被调用时， 所有队列中的命令才会被执行。

另一方面， 通过调用 DISCARD ， 客户端可以清空事务队列， 并放弃执行事务。

事务（transaction）

15

Redis 中文文档

以下是一个事务例子， 它原子地增加了 foo 和 bar 两个键的值：

>MULTI OK

>INCR foo

QUEUED

>INCR bar

QUEUED

>EXEC

1)(integer) 1

2)(integer) 1

EXEC 命令的回复是一个数组， 数组中的每个元素都是执行事务中的命令所产生的回复。 其 中， 回复元素的先后顺序和命令发送的先后顺序一致。

当客户端处于事务状态时， 所有传入的命令都会返回一个内容为 QUEUED 的状态回复 （status reply）， 这些被入队的命令将在 EXEC 命令被调用时执行。

事务中的错误

使用事务时可能会遇上以下两种错误：

事务在执行 EXEC 之前，入队的命令可能会出错。比如说，命令可能会产生语法错误 （参数数量错误，参数名错误，等等），或者其他更严重的错误，比如内存不足（如果 服务器使用 maxmemory 设置了最大内存限制的话）。

命令可能在 EXEC 调用之后失败。举个例子，事务中的命令可能处理了错误类型的键， 比如将列表命令用在了字符串键上面，诸如此类。

对于发生在 EXEC 执行之前的错误，客户端以前的做法是检查命令入队所得的返回值：如果 命令入队时返回 QUEUED ，那么入队成功；否则，就是入队失败。如果有命令在入队时失 败，那么大部分客户端都会停止并取消这个事务。

不过，从 Redis 2.6.5 开始，服务器会对命令入队失败的情况进行记录，并在客户端调用 EXEC 命令时，拒绝执行并自动放弃这个事务。

在Redis 2.6.5 以前， Redis 只执行事务中那些入队成功的命令，而忽略那些入队失败的命 令。 而新的处理方式则使得在流水线（pipeline）中包含事务变得简单，因为发送事务和读取 事务的回复都只需要和服务器进行一次通讯。

至于那些在 EXEC 命令执行之后所产生的错误， 并没有对它们进行特别处理： 即使事务中有 某个/某些命令在执行时产生了错误， 事务中的其他命令仍然会继续执行。

从协议的角度来看这个问题，会更容易理解一些。 以下例子中， LPOP 命令的执行将出错， 尽管调用它的语法是正确的：

事务（transaction）

16

Redis 中文文档

Trying 127.0.0.1...

Connected to localhost.

Escape character is '^]'.

MULTI +OK

SET a 3 abc

+QUEUED LPOP a

+QUEUED EXEC

*2

+OK

-ERR Operation against a key holding the wrong kind of value

EXEC 返回两条批量回复（bulk reply）： 第一条是 OK ，而第二条是 -ERR 。 至于怎样用 合适的方法来表示事务中的错误， 则是由客户端自己决定的。

最重要的是记住这样一条， 即使事务中有某条/某些命令执行失败了， 事务队列中的其他命令 仍然会继续执行 —— Redis 不会停止执行事务中的命令。

以下例子展示的是另一种情况， 当命令在入队时产生错误， 错误会立即被返回给客户端：

MULTI +OK

INCR a b c

-ERR wrong number of arguments for 'incr' command

因为调用 INCR 命令的参数格式不正确， 所以这个 INCR 命令入队失败。

为什么 Redis 不支持回滚（roll back）

如果你有使用关系式数据库的经验， 那么 “Redis 在事务失败时不进行回滚，而是继续执行余 下的命令”这种做法可能会让你觉得有点奇怪。

以下是这种做法的优点：

Redis 命令只会因为错误的语法而失败（并且这些问题不能在入队时发现），或是命令用 在了错误类型的键上面：这也就是说，从实用性的角度来说，失败的命令是由编程错误 造成的，而这些错误应该在开发的过程中被发现，而不应该出现在生产环境中。

因为不需要对回滚进行支持，所以 Redis 的内部可以保持简单且快速。

有种观点认为 Redis 处理事务的做法会产生 bug ， 然而需要注意的是， 在通常情况下， 回 滚并不能解决编程错误带来的问题。 举个例子， 如果你本来想通过 INCR 命令将键的值加上 1 ， 却不小心加上了 2 ， 又或者对错误类型的键执行了 INCR ， 回滚是没有办法处理这

事务（transaction）

17

Redis 中文文档

些情况的。

鉴于没有任何机制能避免程序员自己造成的错误， 并且这类错误通常不会在生产环境中出 现， 所以 Redis 选择了更简单、更快速的无回滚方式来处理事务。

放弃事务

当执行 DISCARD 命令时， 事务会被放弃， 事务队列会被清空， 并且客户端会从事务状态中 退出：

redis> SET foo 1

OK

redis> MULTI OK

redis> INCR foo

QUEUED

redis> DISCARD OK

redis> GET foo "1"

使用 check-and-set 操作实现乐观锁

WATCH 命令可以为 Redis 事务提供 check-and-set （CAS）行为。

被WATCH 的键会被监视，并会发觉这些键是否被改动过了。 如果有至少一个被监视的键在 EXEC 执行之前被修改了， 那么整个事务都会被取消， EXEC 返回空多条批量回复（null multi-bulk reply）来表示事务已经失败。

举个例子， 假设我们需要原子性地为某个值进行增 1 操作（假设 INCR 不存在）。

首先我们可能会这样做：

val = GET mykey val = val + 1 SET mykey $val

上面的这个实现在只有一个客户端的时候可以执行得很好。 但是， 当多个客户端同时对同一 个键进行这样的操作时， 就会产生竞争条件。

举个例子， 如果客户端 A 和 B 都读取了键原来的值， 比如 10 ， 那么两个客户端都会将键 的值设为 11 ， 但正确的结果应该是 12 才对。

有了 WATCH ， 我们就可以轻松地解决这类问题了：

事务（transaction）

18

Redis 中文文档

WATCH mykey

val = GET mykey val = val + 1

MULTI

SET mykey $val

EXEC

使用上面的代码， 如果在 WATCH 执行之后， EXEC 执行之前， 有其他客户端修改了

mykey 的值， 那么当前客户端的事务就会失败。 程序需要做的， 就是不断重试这个操作， 直到没有发生碰撞为止。

这种形式的锁被称作乐观锁， 它是一种非常强大的锁机制。 并且因为大多数情况下， 不同的 客户端会访问不同的键， 碰撞的情况一般都很少， 所以通常并不需要进行重试。

了解 WATCH

WATCH 使得 EXEC 命令需要有条件地执行： 事务只能在所有被监视键都没有被修改的前提 下执行， 如果这个前提不能满足的话，事务就不会被执行。

Note

如果你使用 WATCH 监视了一个带过期时间的键， 那么即使这个键过期了， 事务仍然可以正 常执行， 关于这方面的详细情况，请看这个帖子：

http://code.google.com/p/redis/issues/detail?id=270

WATCH 命令可以被调用多次。 对键的监视从 WATCH 执行之后开始生效， 直到调用 EXEC 为止。

用户还可以在单个 WATCH 命令中监视任意多个键， 就像这样：

redis> WATCH key1 key2 key3

OK

当 EXEC 被调用时， 不管事务是否成功执行， 对所有键的监视都会被取消。

另外， 当客户端断开连接时， 该客户端对键的监视也会被取消。

使用无参数的 UNWATCH 命令可以手动取消对所有键的监视。 对于一些需要改动多个键的事 务， 有时候程序需要同时对多个键进行加锁， 然后检查这些键的当前值是否符合程序的要 求。 当值达不到要求时， 就可以使用 UNWATCH 命令来取消目前对键的监视， 中途放弃这 个事务， 并等待事务的下次尝试。

使用 WATCH 实现 ZPOP

事务（transaction）

19

Redis 中文文档

WATCH 可以用于创建 Redis 没有内置的原子操作。

举个例子， 以下代码实现了原创的 ZPOP 命令， 它可以原子地弹出有序集合中分值 （score）最小的元素：

WATCH zset

element = ZRANGE zset 0 0

MULTI

ZREM zset element

EXEC

程序只要重复执行这段代码， 直到 EXEC 的返回值不是空多条回复（null multi-bulk reply） 即可。

Redis 脚本和事务

从定义上来说， Redis 中的脚本本身就是一种事务， 所以任何在事务里可以完成的事， 在脚 本里面也能完成。 并且一般来说， 使用脚本要来得更简单，并且速度更快。

因为脚本功能是 Redis 2.6 才引入的， 而事务功能则更早之前就存在了， 所以 Redis 才会同 时存在两种处理事务的方法。

不过我们并不打算在短时间内就移除事务功能， 因为事务提供了一种即使不使用脚本， 也可 以避免竞争条件的方法， 而且事务本身的实现并不复杂。

不过在不远的将来， 可能所有用户都会只使用脚本来实现事务也说不定。 如果真的发生这种 情况的话， 那么我们将废弃并最终移除事务功能。

事务（transaction）

20

Redis 中文文档

发布与订阅（pub/sub）

Note

本文档翻译自： http://redis.io/topics/pubsub 。

SUBSCRIBE 、 UNSUBSCRIBE 和 PUBLISH 三个命令实现了发布与订阅信息泛型

（Publish/Subscribe messaging paradigm）， 在这个实现中， 发送者（发送信息的客户 端）不是将信息直接发送给特定的接收者（接收信息的客户端）， 而是将信息发送给频道 （channel）， 然后由频道将信息转发给所有对这个频道感兴趣的订阅者。

发送者无须知道任何关于订阅者的信息， 而订阅者也无须知道是那个客户端给它发送信息， 它只要关注自己感兴趣的频道即可。

对发布者和订阅者进行解构（decoupling）， 可以极大地提高系统的扩展性（scalability）， 并得到一个更动态的网络拓扑（network topology）。

比如说， 要订阅频道 foo 和 bar ， 客户端可以使用频道名字作为参数来调用 SUBSCRIBE 命令：

redis> SUBSCRIBE foo bar

当有客户端发送信息到这些频道时， Redis 会将传入的信息推送到所有订阅这些频道的客户 端里面。

正在订阅频道的客户端不应该发送除 SUBSCRIBE 和 UNSUBSCRIBE 之外的其他命令。 其 中， SUBSCRIBE 可以用于订阅更多频道， 而 UNSUBSCRIBE 则可以用于退订已订阅的一 个或多个频道。

SUBSCRIBE 和 UNSUBSCRIBE 的执行结果会以信息的形式返回， 客户端可以通过分析所 接收信息的第一个元素， 从而判断所收到的内容是一条真正的信息， 还是 SUBSCRIBE 或 UNSUBSCRIBE 命令的操作结果。

信息的格式

频道转发的每条信息都是一条带有三个元素的多条批量回复（multi-bulk reply）。

信息的第一个元素标识了信息的类型：

subscribe ： 表示当前客户端成功地订阅了信息第二个元素所指示的频道。 而信息的第 三个元素则记录了目前客户端已订阅频道的总数。

unsubscribe ： 表示当前客户端成功地退订了信息第二个元素所指示的频道。 信息的第

发布与订阅（pub/sub）

21

Redis 中文文档

三个元素记录了客户端目前仍在订阅的频道数量。 当客户端订阅的频道数量降为 0 时， 客户端不再订阅任何频道， 它可以像往常一样， 执行任何 Redis 命令。

message ： 表示这条信息是由某个客户端执行 PUBLISH 命令所发送的， 真正的信息。 信息的第二个元素是信息来源的频道， 而第三个元素则是信息的内容。

举个例子， 如果客户端执行以下命令：

redis> SUBSCRIBE first second

那么它将收到以下回复：

1)"subscribe"

2)"first"

3)(integer) 1

1)"subscribe"

2)"second"

3)(integer) 2

如果在这时， 另一个客户端执行以下 PUBLISH 命令：

redis> PUBLISH second Hello

那么之前订阅了 second 频道的客户端将收到以下信息：

1)"message"

2)"second"

3)"hello"

当订阅者决定退订所有频道时， 它可以执行一个无参数的 UNSUBSCRIBE 命令：

redis> UNSUBSCRIBE

这个命令将接到以下回复：

1)"unsubscribe"

2)"second"

3)(integer) 1

1)"unsubscribe"

2)"first"

3)(integer) 0

订阅模式

发布与订阅（pub/sub）

22

Redis 中文文档

Redis 的发布与订阅实现支持模式匹配（pattern matching）： 客户端可以订阅一个带 * 号 的模式， 如果某个/某些频道的名字和这个模式匹配， 那么当有信息发送给这个/这些频道的 时候， 客户端也会收到这个/这些频道的信息。

比如说，执行命令

redis> PSUBSCRIBE news.*

的客户端将收到来自 news.art.figurative 、 news.music.jazz 等频道的信息。

客户端订阅的模式里面可以包含多个 glob 风格的通配符， 比如 * 、 ? 和 [...] ， 等 等。

执行命令

redis> PUNSUBSCRIBE news.*

将退订 news.* 模式， 其他已订阅的模式不会被影响。

通过订阅模式接收到的信息， 和通过订阅频道接收到的信息， 这两者的格式不太一样：

通过订阅模式而接收到的信息的类型为 pmessage ： 这代表有某个客户端通过 PUBLISH 向某个频道发送了信息， 而这个频道刚好匹配了当前客户端所订阅的某个模式。 信息的 第二个元素记录了被匹配的模式， 第三个元素记录了被匹配的频道的名字， 最后一个元 素则记录了信息的实际内容。

客户端处理 PSUBSCRIBE 和 PUNSUBSCRIBE 返回值的方式， 和客户端处理 SUBSCRIBE

和UNSUBSCRIBE 的方式类似： 通过对信息的第一个元素进行分析， 客户端可以判断接收 到的信息是一个真正的信息， 还是 PSUBSCRIBE 或 PUNSUBSCRIBE 命令的返回值。

通过频道和模式接收同一条信息

如果客户端订阅的多个模式匹配了同一个频道， 或者客户端同时订阅了某个频道、以及匹配 这个频道的某个模式， 那么它可能会多次接收到同一条信息。

举个例子， 如果客户端执行了以下命令：

SUBSCRIBE foo

PSUBSCRIBE f*

那么当有信息发送到频道 foo 时， 客户端将收到两条信息： 一条来自频道 foo ，信息类

型为 message ； 另一条来自模式 f* ，信息类型为 pmessage 。

发布与订阅（pub/sub）

23

Redis 中文文档

订阅总数

在执行 SUBSCRIBE 、 UNSUBSCRIBE 、 PSUBSCRIBE 和 PUNSUBSCRIBE 命令时， 返 回结果的最后一个元素是客户端目前仍在订阅的频道和模式总数。

当客户端退订所有频道和模式， 也即是这个总数值下降为 0 的时候， 客户端将退出订阅与 发布状态。

编程示例

Pieter Noordhuis 提供了一个使用 EventMachine 和 Redis 编写的 高性能多用户网页聊天软 件 ， 这个软件很好地展示了发布与订阅功能的用法。

客户端库实现提示

因为所有接收到的信息都会包含一个信息来源：

当信息来自频道时，来源是某个频道； 当信息来自模式时，来源是某个模式。

因此， 客户端可以用一个哈希表， 将特定来源和处理该来源的回调函数关联起来。 当有新信 息到达时， 程序就可以根据信息的来源， 在 O(1) 复杂度内， 将信息交给正确的回调函数来 处理。

发布与订阅（pub/sub）

24

Redis 中文文档

复制（Replication）

Note

本文档翻译自： http://redis.io/topics/replication 。

Redis 支持简单且易用的主从复制（master-slave replication）功能， 该功能可以让从服务器 (slave server)成为主服务器(master server)的精确复制品。

以下是关于 Redis 复制功能的几个重要方面：

Redis 使用异步复制。 从 Redis 2.8 开始， 从服务器会以每秒一次的频率向主服务器报 告复制流（replication stream）的处理进度。

一个主服务器可以有多个从服务器。

不仅主服务器可以有从服务器， 从服务器也可以有自己的从服务器， 多个从服务器之间 可以构成一个图状结构。

复制功能不会阻塞主服务器： 即使有一个或多个从服务器正在进行初次同步， 主服务器 也可以继续处理命令请求。

复制功能也不会阻塞从服务器： 只要在 redis.conf 文件中进行了相应的设置， 即使从 服务器正在进行初次同步， 服务器也可以使用旧版本的数据集来处理命令查询。

不过， 在从服务器删除旧版本数据集并载入新版本数据集的那段时间内， 连接请求会被 阻塞。

你还可以配置从服务器， 让它在与主服务器之间的连接断开时， 向客户端发送一个错 误。

复制功能可以单纯地用于数据冗余（data redundancy）， 也可以通过让多个从服务器处 理只读命令请求来提升扩展性（scalability）： 比如说， 繁重的 SORT 命令可以交给附 属节点去运行。

可以通过复制功能来让主服务器免于执行持久化操作： 只要关闭主服务器的持久化功 能， 然后由从服务器去执行持久化操作即可。

关闭主服务器持久化时，复制功能的数据安全

当配置Redis复制功能时，强烈建议打开主服务器的持久化功能。 否则的话，由于延迟等问 题，部署的服务应该要避免自动拉起。

复制（Replication）

25

Redis 中文文档

为了帮助理解主服务器关闭持久化时自动拉起的危险性，参考一下以下会导致主从服务器数 据全部丢失的例子：

1.假设节点A为主服务器，并且关闭了持久化。 并且节点B和节点C从节点A复制数据

2.节点A崩溃，然后由自动拉起服务重启了节点A. 由于节点A的持久化被关闭了，所以重启之 后没有任何数据

3.节点B和节点C将从节点A复制数据，但是A的数据是空的， 于是就把自身保存的数据副本 删除。

在关闭主服务器上的持久化，并同时开启自动拉起进程的情况下，即便使用Sentinel来实现 Redis的高可用性，也是非常危险的。 因为主服务器可能拉起得非常快，以至于Sentinel在配 置的心跳时间间隔内没有检测到主服务器已被重启，然后还是会执行上面的数据丢失的流 程。

无论何时，数据安全都是极其重要的，所以应该禁止主服务器关闭持久化的同时自动拉起。

复制功能的运作原理

无论是初次连接还是重新连接， 当建立一个从服务器时， 从服务器都将向主服务器发送一个 SYNC 命令。

接到 SYNC 命令的主服务器将开始执行 BGSAVE ， 并在保存操作执行期间， 将所有新执行 的写入命令都保存到一个缓冲区里面。

当BGSAVE 执行完毕后， 主服务器将执行保存操作所得的 .rdb 文件发送给从服务器， 从 服务器接收这个 .rdb 文件， 并将文件中的数据载入到内存中。

之后主服务器会以 Redis 命令协议的格式， 将写命令缓冲区中积累的所有内容都发送给从服 务器。

你可以通过 telnet 命令来亲自验证这个同步过程： 首先连上一个正在处理命令请求的 Redis 服务器， 然后向它发送 SYNC 命令， 过一阵子， 你将看到 telnet 会话（session）接收到服 务器发来的大段数据（ .rdb 文件）， 之后还会看到， 所有在服务器执行过的写命令， 都会 重新发送到 telnet 会话来。

即使有多个从服务器同时向主服务器发送 SYNC ， 主服务器也只需执行一次 BGSAVE 命 令， 就可以处理所有这些从服务器的同步请求。

从服务器可以在主从服务器之间的连接断开时进行自动重连， 在 Redis 2.8 版本之前， 断线 之后重连的从服务器总要执行一次完整重同步（full resynchronization）操作， 但是从 Redis

2.8版本开始， 从服务器可以根据主服务器的情况来选择执行完整重同步还是部分重同步 （partial resynchronization）。

复制（Replication）

26

Redis 中文文档

部分重同步

从Redis 2.8 开始， 在网络连接短暂性失效之后， 主从服务器可以尝试继续执行原有的复制 进程（process）， 而不一定要执行完整重同步操作。

这个特性需要主服务器为被发送的复制流创建一个内存缓冲区（in-memory backlog）， 并且 主服务器和所有从服务器之间都记录一个复制偏移量（replication offset）和一个主服务器 ID （master run id）， 当出现网络连接断开时， 从服务器会重新连接， 并且向主服务器请求继 续执行原来的复制进程：

如果从服务器记录的主服务器 ID 和当前要连接的主服务器的 ID 相同， 并且从服务器记 录的偏移量所指定的数据仍然保存在主服务器的复制流缓冲区里面， 那么主服务器会向 从服务器发送断线时缺失的那部分数据， 然后复制工作可以继续执行。

否则的话， 从服务器就要执行完整重同步操作。

Redis 2.8 的这个部分重同步特性会用到一个新增的 PSYNC 内部命令， 而 Redis 2.8 以前的 旧版本只有 SYNC 命令， 不过， 只要从服务器是 Redis 2.8 或以上的版本， 它就会根据主 服务器的版本来决定到底是使用 PSYNC 还是 SYNC ：

如果主服务器是 Redis 2.8 或以上版本，那么从服务器使用 PSYNC 命令来进行同步。 如果主服务器是 Redis 2.8 之前的版本，那么从服务器使用 SYNC 命令来进行同步。

配置

配置一个从服务器非常简单， 只要在配置文件中增加以下的这一行就可以了：

slaveof 192.168.1.1 6379

当然， 你需要将代码中的 192.168.1.1 和 6379 替换成你的主服务器的 IP 和端口号。

另外一种方法是调用 SLAVEOF 命令， 输入主服务器的 IP 和端口， 然后同步就会开始：

127.0.0.1:6379> SLAVEOF 192.168.1.1 10086

OK

只读从服务器

从 Redis 2.6 开始， 从服务器支持只读模式， 并且该模式为从服务器的默认模式。

只读模式由 redis.conf 文件中的 slave-read-only 选项控制， 也可以通过 CONFIG SET

命令来开启或关闭这个模式。

复制（Replication）

27

Redis 中文文档

只读从服务器会拒绝执行任何写命令， 所以不会出现因为操作失误而将数据不小心写入到了 从服务器的情况。

即使从服务器是只读的， DEBUG 和 CONFIG 等管理式命令仍然是可以使用的， 所以我们还 是不应该将服务器暴露给互联网或者任何不可信网络。 不过， 使用 redis.conf 中的命令改 名选项， 我们可以通过禁止执行某些命令来提升只读从服务器的安全性。

你可能会感到好奇， 既然从服务器上的写数据会被重同步数据覆盖， 也可能在从服务器重启 时丢失， 那么为什么要让一个从服务器变得可写呢？

原因是， 一些不重要的临时数据， 仍然是可以保存在从服务器上面的。 比如说， 客户端可 以在从服务器上保存主服务器的可达性（reachability）信息， 从而实现故障转移（failover） 策略。

从服务器相关配置

如果主服务器通过 requirepass 选项设置了密码， 那么为了让从服务器的同步操作可以顺利 进行， 我们也必须为从服务器进行相应的身份验证设置。

对于一个正在运行的服务器， 可以使用客户端输入以下命令：

config set masterauth <password>

要永久地设置这个密码， 那么可以将它加入到配置文件中：

masterauth <password>

另外还有几个选项， 它们和主服务器执行部分重同步时所使用的复制流缓冲区有关， 详细的 信息可以参考 Redis 源码中附带的 redis.conf 示例文件。

主服务器只在有至少 N 个从服务器的情况下，才执行 写操作

从Redis 2.8 开始， 为了保证数据的安全性， 可以通过配置， 让主服务器只在有至少 N 个当 前已连接从服务器的情况下， 才执行写命令。

不过， 因为 Redis 使用异步复制， 所以主服务器发送的写数据并不一定会被从服务器接收 到， 因此， 数据丢失的可能性仍然是存在的。

以下是这个特性的运作原理：

从服务器以每秒一次的频率 PING 主服务器一次， 并报告复制流的处理情况。 主服务器会记录各个从服务器最后一次向它发送 PING 的时间。

复制（Replication）

28

Redis 中文文档

用户可以通过配置， 指定网络延迟的最大值 min-slaves-max-lag ， 以及执行写操作所

需的至少从服务器数量 min-slaves-to-write 。

如果至少有 min-slaves-to-write 个从服务器， 并且这些服务器的延迟值都少于

min-slaves-max-lag 秒， 那么主服务器就会执行客户端请求的写操作。

你可以将这个特性看作 CAP 理论中的 C 的条件放宽版本： 尽管不能保证写操作的持久性， 但起码丢失数据的窗口会被严格限制在指定的秒数中。

另一方面， 如果条件达不到 min-slaves-to-write 和 min-slaves-max-lag 所指定的条件，

那么写操作就不会被执行， 主服务器会向请求执行写操作的客户端返回一个错误。

以下是这个特性的两个选项和它们所需的参数：

min-slaves-to-write <number of slaves>

min-slaves-max-lag <number of seconds>

详细的信息可以参考 Redis 源码中附带的 redis.conf 示例文件。

复制（Replication）

29

Redis 中文文档

通信协议（protocol）

Note

本文档翻译自： http://redis.io/topics/protocol 。

Redis 协议在以下三个目标之间进行折中：

易于实现

可以高效地被计算机分析（parse） 可以很容易地被人类读懂

网络层

客户端和服务器通过 TCP 连接来进行数据交互， 服务器默认的端口号为 6379 。 客户端和服务器发送的命令或数据一律以 \r\n （CRLF）结尾。

请求

Redis 服务器接受命令以及命令的参数。

服务器会在接到命令之后，对命令进行处理，并将命令的回复传送回客户端。

新版统一请求协议

新版统一请求协议在 Redis 1.2 版本中引入， 并最终在 Redis 2.0 版本成为 Redis 服务器通信 的标准方式。

你的 Redis 客户端应该按照这个新版协议来进行实现。

在这个协议中， 所有发送至 Redis 服务器的参数都是二进制安全（binary safe）的。

以下是这个协议的一般形式：

*<参数数量> CR LF

$<参数 1 的字节数量> CR LF <参数 1 的数据> CR LF

...

$<参数 N 的字节数量> CR LF <参数 N 的数据> CR LF

Note

通信协议（protocol）

30

Redis 中文文档

译注：命令本身也作为协议的其中一个参数来发送。 举个例子， 以下是一个命令协议的打印版本：

*3 $3

SET $5 mykey $7 myvalue

这个命令的实际协议值如下：

"*3\r\n$3\r\nSET\r\n$5\r\nmykey\r\n$7\r\nmyvalue\r\n"

稍后我们会看到， 这种格式除了用作命令请求协议之外， 也用在命令的回复协议中： 这种只 有一个参数的回复格式被称为批量回复（Bulk Reply）。

统一协议请求原本是用在回复协议中， 用于将列表的多个项返回给客户端的， 这种回复格式 被称为多条批量回复（Multi Bulk Reply）。

一个多条批量回复以 *<argc>\r\n 为前缀， 后跟多条不同的批量回复， 其中 argc 为 这些批量回复的数量。

回复

Redis 命令会返回多种不同类型的回复。

通过检查服务器发回数据的第一个字节， 可以确定这个回复是什么类型：

状态回复（status reply）的第一个字节是 "+" 错误回复（error reply）的第一个字节是 "-" 整数回复（integer reply）的第一个字节是 ":" 批量回复（bulk reply）的第一个字节是 "$"

多条批量回复（multi bulk reply）的第一个字节是 "*"

状态回复

一个状态回复（或者单行回复，single line reply）是一段以 "+" 开始、 "\r\n" 结尾的单行 字符串。

以下是一个状态回复的例子：

+OK

通信协议（protocol）

31

Redis 中文文档

客户端库应该返回 "+" 号之后的所有内容。 比如在在上面的这个例子中， 客户端就应该返 回字符串 "OK" 。

状态回复通常由那些不需要返回数据的命令返回，这种回复不是二进制安全的，它也不能包 含新行。

状态回复的额外开销非常少，只需要三个字节（开头的 "+" 和结尾的 CRLF）。

错误回复

错误回复和状态回复非常相似， 它们之间的唯一区别是， 错误回复的第一个字节是 "-" ， 而状态回复的第一个字节是 "+" 。

错误回复只在某些地方出现问题时发送： 比如说， 当用户对不正确的数据类型执行命令， 或 者执行一个不存在的命令， 等等。

一个客户端库应该在收到错误回复时产生一个异常。

以下是两个错误回复的例子：

-ERR unknown command 'foobar'

-WRONGTYPE Operation against a key holding the wrong kind of value

在 "-" 之后，直到遇到第一个空格或新行为止，这中间的内容表示所返回错误的类型。

ERR 是一个通用错误，而 WRONGTYPE 则是一个更特定的错误。 一个客户端实现可以为不同 类型的错误产生不同类型的异常， 或者提供一种通用的方式， 让调用者可以通过提供字符串 形式的错误名来捕捉（trap）不同的错误。

不过这些特性用得并不多， 所以并不是特别重要， 一个受限的（limited）客户端可以通过简 单地返回一个逻辑假（false）来表示一个通用的错误条件。

整数回复

整数回复就是一个以 ":" 开头， CRLF 结尾的字符串表示的整数。

比如说， ":0\r\n" 和 ":1000\r\n" 都是整数回复。

返回整数回复的其中两个命令是 INCR 和 LASTSAVE 。 被返回的整数没有什么特殊的含义， INCR 返回键的一个自增后的整数值， 而 LASTSAVE 则返回一个 UNIX 时间戳， 返回值的唯 一限制是这些数必须能够用 64 位有符号整数表示。

整数回复也被广泛地用于表示逻辑真和逻辑假： 比如 EXISTS 和 SISMEMBER 都用返回值 1 表示真， 0 表示假。

通信协议（protocol）

32

Redis 中文文档

其他一些命令， 比如 SADD 、 SREM 和 SETNX ， 只在操作真正被执行了的时候， 才返回

1， 否则返回 0 。

以下命令都返回整数回复： SETNX 、 DEL 、 EXISTS 、 INCR 、 INCRBY 、 DECR 、

DECRBY 、 DBSIZE 、 LASTSAVE 、 RENAMENX 、 MOVE 、 LLEN 、 SADD 、 SREM

、SISMEMBER 、 SCARD 。

批量回复

服务器使用批量回复来返回二进制安全的字符串，字符串的最大长度为 512 MB 。

客户端：GET mykey

服务器：foobar

服务器发送的内容中：

第一字节为 "$" 符号

接下来跟着的是表示实际回复长度的数字值 之后跟着一个 CRLF

再后面跟着的是实际回复数据 最末尾是另一个 CRLF

对于前面的 GET 命令，服务器实际发送的内容为：

"$6\r\nfoobar\r\n"

如果被请求的值不存在， 那么批量回复会将特殊值 -1 用作回复的长度值， 就像这样：

客户端：GET non-existing-key

服务器：$-1

这种回复称为空批量回复（NULL Bulk Reply）。

当请求对象不存在时，客户端应该返回空对象，而不是空字符串： 比如 Ruby 库应该返回 nil ， 而 C 库应该返回 NULL （或者在回复对象中设置一个特殊标志）， 诸如此类。

多条批量回复

像 LRANGE 这样的命令需要返回多个值， 这一目标可以通过多条批量回复来完成。

多条批量回复是由多个回复组成的数组， 数组中的每个元素都可以是任意类型的回复， 包括 多条批量回复本身。

通信协议（protocol）

33

Redis 中文文档

多条批量回复的第一个字节为 "*" ， 后跟一个字符串表示的整数值， 这个值记录了多条批 量回复所包含的回复数量， 再后面是一个 CRLF 。

客户端： LRANGE mylist 0 3

服务器： *4

服务器： $3

服务器： foo

服务器： $3

服务器： bar

服务器： $5

服务器： Hello

服务器： $5

服务器： World

在上面的示例中，服务器发送的所有字符串都由 CRLF 结尾。

正如你所见到的那样， 多条批量回复所使用的格式， 和客户端发送命令时使用的统一请求协 议的格式一模一样。 它们之间的唯一区别是：

统一请求协议只发送批量回复。

而服务器应答命令时所发送的多条批量回复，则可以包含任意类型的回复。

以下例子展示了一个多条批量回复， 回复中包含四个整数值， 以及一个二进制安全字符串：

*5\r\n

:1\r\n

:2\r\n

:3\r\n

:4\r\n $6\r\n foobar\r\n

在回复的第一行， 服务器发送 *5\r\n ， 表示这个多条批量回复包含 5 条回复， 再后面跟 着的则是 5 条回复的正文。

多条批量回复也可以是空白的（empty）， 就像这样：

客户端： LRANGE nokey 0 1

服务器： *0\r\n

无内容的多条批量回复（null multi bulk reply）也是存在的， 比如当 BLPOP 命令的阻塞时间 超过最大时限时， 它就返回一个无内容的多条批量回复， 这个回复的计数值为 -1 ：

客户端： BLPOP key 1

服务器： *-1\r\n

客户端库应该区别对待空白多条回复和无内容多条回复： 当 Redis 返回一个无内容多条回复 时， 客户端库应该返回一个 null 对象， 而不是一个空数组。

通信协议（protocol）

34

Redis 中文文档

多条批量回复中的空元素

多条批量回复中的元素可以将自身的长度设置为 -1 ， 从而表示该元素不存在， 并且也不是 一个空白字符串（empty string）。

当SORT 命令使用 GET pattern 选项对一个不存在的键进行操作时， 就会发生多条批量回 复中带有空白元素的情况。

以下例子展示了一个包含空元素的多重批量回复：

服务器： *3

服务器： $3

服务器： foo

服务器： $-1

服务器： $3

服务器： bar

其中， 回复中的第二个元素为空。

对于这个回复， 客户端库应该返回类似于这样的回复：

["foo", nil, "bar"]

多命令和流水线

客户端可以通过流水线， 在一次写入操作中发送多个命令：

在发送新命令之前， 无须阅读前一个命令的回复。 多个命令的回复会在最后一并返回。

内联命令

当你需要和 Redis 服务器进行沟通， 但又找不到 redis-cli ， 而手上只有 telnet 的时 候， 你可以通过 Redis 特别为这种情形而设的内联命令格式来发送命令。

以下是一个客户端和服务器使用内联命令来进行交互的例子：

客户端： PING

服务器： +PONG

以下另一个返回整数值的内联命令的例子：

客户端： EXISTS somekey

服务器： :0

通信协议（protocol）

35

Redis 中文文档

因为没有了统一请求协议中的 "*" 项来声明参数的数量， 所以在 telnet 会话输入命令的 时候， 必须使用空格来分割各个参数， 服务器在接收到数据之后， 会按空格对用户的输入进 行分析（parse）， 并获取其中的命令参数。

高性能 Redis 协议分析器

尽管 Redis 的协议非常利于人类阅读， 定义也很简单， 但这个协议的实现性能仍然可以和二 进制协议一样快。

因为 Redis 协议将数据的长度放在数据正文之前， 所以程序无须像 JSON 那样， 为了寻找某 个特殊字符而扫描整个 payload ， 也无须对发送至服务器的 payload 进行转义（quote）。

程序可以在对协议文本中的各个字符进行处理的同时， 查找 CR 字符， 并计算出批量回复或 多条批量回复的长度， 就像这样：

#include <stdio.h>

int main(void) {

unsigned char *p = "$123\r\n"; int len = 0;

p++;

while(*p != '\r') {

len = (len*10)+(*p - '0'); p++;

}

/* Now p points at '\r', and the len is in bulk_len. */ printf("%d\n", len);

return 0;

}

得到了批量回复或多条批量回复的长度之后， 程序只需调用一次 read 函数， 就可以将回复 的正文数据全部读入到内存中， 而无须对这些数据做任何的处理。

在回复最末尾的 CR 和 LF 不作处理，丢弃它们。

Redis 协议的实现性能可以和二进制协议的实现性能相媲美， 并且由于 Redis 协议的简单

性， 大部分高级语言都可以轻易地实现这个协议， 这使得客户端软件的 bug 数量大大减少。

通信协议（protocol）

36

Redis 中文文档

持久化（persistence）

Note

本文档翻译自 http://redis.io/topics/persistence 。

这篇文章提供了 Redis 持久化的技术性描述， 推荐所有 Redis 用户阅读。

要更广泛地了解 Redis 持久化， 以及这种持久化所保证的耐久性（durability）， 请参考文章 Redis persistence demystified （中文）。

Redis 持久化

Redis 提供了多种不同级别的持久化方式：

RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。

AOF 持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些 命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追 加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写（rewrite），使得 AOF 文 件的体积不会超出保存数据集状态所需的实际大小。

Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下， 当 Redis 重启时， 它会优先使用 AOF 文件来还原数据集， 因为 AOF 文件保存的数据集通常比 RDB 文件 所保存的数据集更完整。

你甚至可以关闭持久化功能，让数据只在服务器运行时存在。

了解 RDB 持久化和 AOF 持久化之间的异同是非常重要的， 以下几个小节将详细地介绍这这 两种持久化功能， 并对它们的相同和不同之处进行说明。

RDB 的优点

RDB 是一个非常紧凑（compact）的文件，它保存了 Redis 在某个时间点上的数据集。 这种文件非常适合用于进行备份： 比如说，你可以在最近的 24 小时内，每小时备份一

次RDB 文件，并且在每个月的每一天，也备份一个 RDB 文件。 这样的话，即使遇上问 题，也可以随时将数据集还原到不同的版本。

RDB 非常适用于灾难恢复（disaster recovery）：它只有一个文件，并且内容都非常紧 凑，可以（在加密后）将它传送到别的数据中心，或者亚马逊 S3 中。

RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一 个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。

持久化（persistence）

37

Redis 中文文档

RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

RDB 的缺点

如果你需要尽量避免在服务器故障时丢失数据，那么 RDB 不适合你。 虽然 Redis 允许 你设置不同的保存点（save point）来控制保存 RDB 文件的频率， 但是， 因为RDB 文 件需要保存整个数据集的状态， 所以它并不是一个轻松的操作。 因此你可能会至少 5 分 钟才保存一次 RDB 文件。 在这种情况下， 一旦发生故障停机， 你就可能会丢失好几分 钟的数据。

每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持 久化工作。 在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内 停止处理客户端； 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止 时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写 的执行间隔有多长，数据的耐久性都不会有任何损失。

AOF 的优点

使用 AOF 持久化会让 Redis 变得非常耐久（much more durable）：你可以设置不同的 fsync 策略，比如无 fsync ，每秒钟一次 fsync ，或者每次执行写入命令时 fsync

。AOF 的默认策略为每秒钟 fsync 一次，在这种配置下，Redis 仍然可以保持良好的 性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据（ fsync 会在后台线程执 行，所以主线程可以继续努力地处理命令请求）。

AOF 文件是一个只进行追加操作的日志文件（append only log）， 因此对 AOF 文件的 写入不需要进行 seek ， 即使日志因为某些原因而包含了未写入完整的命令（比如写入 时磁盘已满，写入中途停机，等等）， redis-check-aof 工具也可以轻易地修复这种问 题。

Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因

为Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即 使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕， Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。

AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格 式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻 松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件 末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前 的状态。

AOF 的缺点

持久化（persistence）

38

Redis 中文文档

对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。

根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒

fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使 在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大 延迟时间（latency）。

AOF 在过去曾经发生过这样的 bug ： 因为个别命令的原因，导致 AOF 文件在重新载入 时，无法将数据集恢复成保存时的原样。 （举个例子，阻塞命令 BRPOPLPUSH 就曾经 引起过这样的 bug 。） 测试套件里为这种情况添加了测试： 它们会自动生成随机的、复 杂的数据集， 并通过重新载入这些数据来确保一切正常。 虽然这种 bug 在 AOF 文件中 并不常见， 但是对比来说， RDB 几乎是不可能出现这种 bug 的。

RDB 和 AOF ，我应该用哪一个？

一般来说， 如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功 能。

如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。

有很多用户都只使用 AOF 持久化， 但我们并不推荐这种方式： 因为定时生成 RDB 快照

（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速 度要快， 除此之外， 使用 RDB 还可以避免之前提到的 AOF 程序的 bug 。

Note

因为以上提到的种种原因， 未来我们可能会将 AOF 和 RDB 整合成单个持久化模型。 （这是 一个长期计划。）

接下来的几个小节将介绍 RDB 和 AOF 的更多细节。

RDB 快照

在默认情况下， Redis 将数据库快照保存在名字为 dump.rdb 的二进制文件中。

你可以对 Redis 进行设置， 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时， 自动保存一次数据集。

你也可以通过调用 SAVE 或者 BGSAVE ， 手动让 Redis 进行数据集保存操作。

比如说， 以下设置会让 Redis 在满足“ 60 秒内有至少有 1000 个键被改动”这一条件时， 自 动保存一次数据集：

save 60 1000

持久化（persistence）

39

Redis 中文文档

这种持久化方式被称为快照（snapshot）。

快照的运作方式

当Redis 需要保存 dump.rdb 文件时， 服务器执行以下操作：

1.Redis 调用 fork() ，同时拥有父进程和子进程。

2.子进程将数据集写入到一个临时 RDB 文件中。

3.当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并 删除旧的 RDB 文件。

这种工作方式使得 Redis 可以从写时复制（copy-on-write）机制中获益。

只进行追加操作的文件（append-only file，AOF）

快照功能并不是非常耐久（durable）： 如果 Redis 因为某些原因而造成故障停机， 那么服 务器将丢失最近写入、且仍未保存到快照中的那些数据。

尽管对于某些程序来说， 数据的耐久性并不是最重要的考虑因素， 但是对于那些追求完全耐 久能力（full durability）的程序来说， 快照功能就不太适用了。

从1.1 版本开始， Redis 增加了一种完全耐久的持久化方式： AOF 持久化。 你可以通过修改配置文件来打开 AOF 功能：

appendonly yes

从现在开始， 每当 Redis 执行一个改变数据集的命令时（比如 SET）， 这个命令就会被追加 到 AOF 文件的末尾。

这样的话， 当 Redis 重新启时， 程序就可以通过重新执行 AOF 文件中的命令来达到重建数 据集的目的。

AOF 重写

因为 AOF 的运作方式是不断地将命令追加到文件的末尾， 所以随着写入命令的不断增加， AOF 文件的体积也会变得越来越大。

举个例子， 如果你对一个计数器调用了 100 次 INCR ， 那么仅仅是为了保存这个计数器的当 前值， AOF 文件就需要使用 100 条记录（entry）。

然而在实际上， 只使用一条 SET 命令已经足以保存计数器的当前值了， 其余 99 条记录实际 上都是多余的。

持久化（persistence）

40

Redis 中文文档

为了处理这种情况， Redis 支持一种有趣的特性： 可以在不打断服务客户端的情况下， 对 AOF 文件进行重建（rebuild）。

执行 BGREWRITEAOF 命令， Redis 将生成一个新的 AOF 文件， 这个文件包含重建当前数 据集所需的最少命令。

Redis 2.2 需要自己手动执行 BGREWRITEAOF 命令； Redis 2.4 则可以自动触发 AOF 重 写， 具体信息请查看 2.4 的示例配置文件。

AOF 的耐久性如何？

你可以配置 Redis 多久才将数据 fsync 到磁盘一次。

有三个选项：

每次有新命令追加到 AOF 文件时就执行一次 fsync ：非常慢，也非常安全。

每秒 fsync 一次：足够快（和使用 RDB 持久化差不多），并且在故障时只会丢失 1 秒 钟的数据。

从不 fsync ：将数据交给操作系统来处理。更快，也更不安全的选择。

推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全 性。

总是 fsync 的策略在实际使用中非常慢， 即使在 Redis 2.0 对相关的程序进行了改进之后仍 是如此 —— 频繁调用 fsync 注定了这种策略不可能快得起来。

如果 AOF 文件出错了，怎么办？

服务器可能在程序正在对 AOF 文件进行写入时停机， 如果停机造成了 AOF 文件出错

（corrupt）， 那么 Redis 在重启时会拒绝载入这个 AOF 文件， 从而确保数据的一致性不会 被破坏。

当发生这种情况时， 可以用以下方法来修复出错的 AOF 文件：

1.为现有的 AOF 文件创建一个备份。

2.使用 Redis 附带的 redis-check-aof 程序，对原来的 AOF 文件进行修复。

>> $ redis-check-aof --fix > >

1.（可选）使用 diff -u 对比修复后的 AOF 文件和原始 AOF 文件的备份，查看两个文件 之间的不同之处。

2.重启 Redis 服务器，等待服务器载入修复后的 AOF 文件，并进行数据恢复。

AOF 的运作方式

持久化（persistence）

41

Redis 中文文档

AOF 重写和 RDB 创建快照一样，都巧妙地利用了写时复制机制。

以下是 AOF 重写的执行步骤：

1.Redis 执行 fork() ，现在同时拥有父进程和子进程。

2.子进程开始将新 AOF 文件的内容写入到临时文件。

3.对于所有新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改 动追加到现有 AOF 文件的末尾： 这样即使在重写的中途发生停机，现有的 AOF 文件也 还是安全的。

4.当子进程完成重写工作时，它给父进程发送一个信号，父进程在接收到信号之后，将内 存缓存中的所有数据追加到新 AOF 文件的末尾。

5.搞定！现在 Redis 原子地用新文件替换旧文件，之后所有命令都会直接追加到新 AOF 文 件的末尾。

怎么从 RDB 持久化切换到 AOF 持久化

在Redis 2.2 或以上版本，可以在不重启的情况下，从 RDB 切换到 AOF ：

1.为最新的 dump.rdb 文件创建一个备份。

2.将备份放到一个安全的地方。

3.执行以下两条命令：

>

> redis-cli> CONFIG SET appendonly yes > > redis-cli> CONFIG SET save "" &g

1.确保命令执行之后，数据库的键的数量没有改变。

2.确保写命令会被正确地追加到 AOF 文件的末尾。

步骤 3 执行的第一条命令开启了 AOF 功能： Redis 会阻塞直到初始 AOF 文件创建完成为 止， 之后 Redis 会继续处理命令请求， 并开始将写入命令追加到 AOF 文件末尾。

步骤 3 执行的第二条命令用于关闭 RDB 功能。 这一步是可选的， 如果你愿意的话， 也可以 同时使用 RDB 和 AOF 这两种持久化功能。

Note

别忘了在 redis.conf 中打开 AOF 功能！ 否则的话， 服务器重启之后， 之前通过 CONFIG SET 设置的配置就会被遗忘， 程序会按原来的配置来启动服务器。

Note

译注： 原文这里还有介绍 2.0 版本的切换方式， 考虑到 2.0 已经很老旧了， 这里省略了对那 部分文档的翻译， 有需要的请参考原文。

RDB 和 AOF 之间的相互作用

持久化（persistence）

42

Redis 中文文档

在版本号大于等于 2.4 的 Redis 中， BGSAVE 执行的过程中， 不可以执行 BGREWRITEAOF 。 反过来说， 在 BGREWRITEAOF 执行的过程中， 也不可以执行

BGSAVE 。

这可以防止两个 Redis 后台进程同时对磁盘进行大量的 I/O 操作。

如果 BGSAVE 正在执行， 并且用户显示地调用 BGREWRITEAOF 命令， 那么服务器将向用 户回复一个 OK 状态， 并告知用户， BGREWRITEAOF 已经被预定执行： 一旦 BGSAVE 执行完毕， BGREWRITEAOF 就会正式开始。

当Redis 启动时， 如果 RDB 持久化和 AOF 持久化都被打开了， 那么程序会优先使用 AOF 文件来恢复数据集， 因为 AOF 文件所保存的数据通常是最完整的。

备份 Redis 数据

在阅读这个小节前， 先将下面这句话铭记于心： 一定要备份你的数据库！

磁盘故障， 节点失效， 诸如此类的问题都可能让你的数据消失不见， 不进行备份是非常危险 的。

Redis 对于数据备份是非常友好的， 因为你可以在服务器运行的时候对 RDB 文件进行复制： RDB 文件一旦被创建， 就不会进行任何修改。 当服务器要创建一个新的 RDB 文件时， 它先 将文件的内容保存在一个临时文件里面， 当临时文件写入完毕时， 程序才使用 rename(2)

原子地用临时文件替换原来的 RDB 文件。

这也就是说， 无论何时， 复制 RDB 文件都是绝对安全的。

以下是我们的建议：

创建一个定期任务（cron job）， 每小时将一个 RDB 文件备份到一个文件夹， 并且每天 将一个 RDB 文件备份到另一个文件夹。

确保快照的备份都带有相应的日期和时间信息， 每次执行定期任务脚本时， 使用 find 命令来删除过期的快照： 比如说， 你可以保留最近 48 小时内的每小时快照， 还可以保 留最近一两个月的每日快照。

至少每天一次， 将 RDB 备份到你的数据中心之外， 或者至少是备份到你运行 Redis 服 务器的物理机器之外。

容灾备份

Redis 的容灾备份基本上就是对数据进行备份， 并将这些备份传送到多个不同的外部数据中 心。

容灾备份可以在 Redis 运行并产生快照的主数据中心发生严重的问题时， 仍然让数据处于安 全状态。

持久化（persistence）

43

Redis 中文文档

因为很多 Redis 用户都是创业者， 他们没有大把大把的钱可以浪费， 所以下面介绍的都是一 些实用又便宜的容灾备份方法：

Amazon S3 ，以及其他类似 S3 的服务，是一个构建灾难备份系统的好地方。 最简单的 方法就是将你的每小时或者每日 RDB 备份加密并传送到 S3 。 对数据的加密可以通过 gpg -c 命令来完成（对称加密模式）。 记得把你的密码放到几个不同的、安全的地方 去（比如你可以把密码复制给你组织里最重要的人物）。 同时使用多个储存服务来保存 数据文件，可以提升数据的安全性。

传送快照可以使用 SCP 来完成（SSH 的组件）。 以下是简单并且安全的传送方法： 买 一个离你的数据中心非常远的 VPS ， 装上 SSH ， 创建一个无口令的 SSH 客户端 key ， 并将这个 key 添加到 VPS 的 authorized_keys 文件中， 这样就可以向这个 VPS 传送 快照备份文件了。 为了达到最好的数据安全性，至少要从两个不同的提供商那里各购买 一个 VPS 来进行数据容灾备份。

需要注意的是， 这类容灾系统如果没有小心地进行处理的话， 是很容易失效的。

最低限度下， 你应该在文件传送完毕之后， 检查所传送备份文件的体积和原始快照文件的体 积是否相同。 如果你使用的是 VPS ， 那么还可以通过比对文件的 SHA1 校验和来确认文件 是否传送完整。

另外， 你还需要一个独立的警报系统， 让它在负责传送备份文件的传送器（transfer）失灵 时通知你。

持久化（persistence）

44

Redis 中文文档

Sentinel

Note

本文档翻译自： http://redis.io/topics/sentinel 。

Redis 的 Sentinel 系统用于管理多个 Redis 服务器（instance）， 该系统执行以下三个任

务：

监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。

提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。

自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会 开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服 务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失 效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服 务器代替失效服务器。

Redis Sentinel 是一个分布式系统， 你可以在一个架构中运行多个 Sentinel 进程

（progress）， 这些进程使用流言协议（gossip protocols)来接收关于主服务器是否下线的信 息， 并使用投票协议（agreement protocols）来决定是否执行自动故障迁移， 以及选择哪个 从服务器作为新的主服务器。

虽然 Redis Sentinel 释出为一个单独的可执行文件 redis-sentinel ， 但实际上它只是一个 运行在特殊模式下的 Redis 服务器， 你可以在启动一个普通 Redis 服务器时通过给定 选项来启动 Redis Sentinel 。

Warning

Redis Sentinel 目前仍在开发中， 这个文档的内容可能随着 Sentinel 实现的修改而变更。

Redis Sentinel 兼容 Redis 2.4.16 或以上版本， 推荐使用 Redis 2.8.0 或以上的版本。

获取 Sentinel

目前 Sentinel 系统是 Redis 的 unstable 分支的一部分， 你必须到 Redis 项目的 Github 页 面 克隆一份 unstable 分值， 然后通过编译来获得 Sentinel 系统。

Sentinel 程序可以在编译后的 src 文档中发现， 它是一个命名为 redis-sentinel 的程序。 你也可以通过下一节介绍的方法， 让 redis-server 程序运行在 Sentinel 模式之下。

另外， 一个新版本的 Sentinel 已经包含在了 Redis 2.8.0 版本的释出文件中。

Sentinel

45

Redis 中文文档

启动 Sentinel

对于 redis-sentinel 程序， 你可以用以下命令来启动 Sentinel 系统：

redis-sentinel /path/to/sentinel.conf

对于 redis-server 程序， 你可以用以下命令来启动一个运行在 Sentinel 模式下的 Redis 服 务器：

redis-server /path/to/sentinel.conf --sentinel

两种方法都可以启动一个 Sentinel 实例。

启动 Sentinel 实例必须指定相应的配置文件， 系统会使用配置文件来保存 Sentinel 的当前状 态， 并在 Sentinel 重启时通过载入配置文件来进行状态还原。

如果启动 Sentinel 时没有指定相应的配置文件， 或者指定的配置文件不可写（not writable）， 那么 Sentinel 会拒绝启动。

配置 Sentinel

Redis 源码中包含了一个名为 sentinel.conf 的文件， 这个文件是一个带有详细注释的 Sentinel 配置文件示例。

运行一个 Sentinel 所需的最少配置如下所示：

sentinel monitor mymaster 127.0.0.1 6379 2 sentinel down-after-milliseconds mymaster 60000 sentinel failover-timeout mymaster 180000 sentinel parallel-syncs mymaster 1

sentinel monitor resque 192.168.1.3 6380 4 sentinel down-after-milliseconds resque 10000 sentinel failover-timeout resque 180000 sentinel parallel-syncs resque 5

第一行配置指示 Sentinel 去监视一个名为 mymaster 的主服务器， 这个主服务器的 IP 地址

为127.0.0.1 ， 端口号为 6379 ， 而将这个主服务器判断为失效至少需要 2 个 Sentinel 同意 （只要同意 Sentinel 的数量不达标，自动故障迁移就不会执行）。

不过要注意， 无论你设置要多少个 Sentinel 同意才能判断一个服务器失效， 一个 Sentinel 都需要获得系统中多数（majority） Sentinel 的支持， 才能发起一次自动故障迁移， 并预留 一个给定的配置纪元 （configuration Epoch ，一个配置纪元就是一个新主服务器配置的版本 号）。

Sentinel

46

Redis 中文文档

换句话说， 在只有少数（minority） Sentinel 进程正常运作的情况下， Sentinel 是不能执 行自动故障迁移的。

其他选项的基本格式如下：

sentinel <选项的名字> <主服务器的名字> <选项的值>

各个选项的功能如下：

down-after-milliseconds 选项指定了 Sentinel 认为服务器已经断线所需的毫秒数。

如果服务器在给定的毫秒数之内， 没有返回 Sentinel 发送的 PING 命令的回复， 或者返 回一个错误， 那么 Sentinel 将这个服务器标记为主观下线（subjectively down，简称

SDOWN ）。

不过只有一个 Sentinel 将服务器标记为主观下线并不一定会引起服务器的自动故障迁

移： 只有在足够数量的 Sentinel 都将一个服务器标记为主观下线之后， 服务器才会被标 记为客观下线（objectively down， 简称 ODOWN ）， 这时自动故障迁移才会执行。

将服务器标记为客观下线所需的 Sentinel 数量由对主服务器的配置决定。

parallel-syncs 选项指定了在执行故障转移时， 最多可以有多少个从服务器同时对新的 主服务器进行同步， 这个数字越小， 完成故障转移所需的时间就越长。

如果从服务器被设置为允许使用过期数据集（参见对 redis.conf 文件中对

slave-serve-stale-data 选项的说明）， 那么你可能不希望所有从服务器都在同一时间

向新的主服务器发送同步请求， 因为尽管复制过程的绝大部分步骤都不会阻塞从服务 器， 但从服务器在载入主服务器发来的 RDB 文件时， 仍然会造成从服务器在一段时间 内不能处理命令请求： 如果全部从服务器一起对新的主服务器进行同步， 那么就可能会 造成所有从服务器在短时间内全部不可用的情况出现。

你可以通过将这个值设为 1 来保证每次只有一个从服务器处于不能处理命令请求的状 态。

本文档剩余的内容将对 Sentinel 系统的其他选项进行介绍， 示例配置文件 sentinel.conf 也 对相关的选项进行了完整的注释。

主观下线和客观下线

前面说过， Redis 的 Sentinel 中关于下线（down）有两个不同的概念：

主观下线（Subjectively Down， 简称 SDOWN）指的是单个 Sentinel 实例对服务器做出

的下线判断。

客观下线（Objectively Down， 简称 ODOWN）指的是多个 Sentinel 实例在对同一个服

务器做出 SDOWN 判断， 并且通过 SENTINEL is-master-down-by-addr 命令互相交流之

Sentinel

47

Redis 中文文档

后， 得出的服务器下线判断。 （一个 Sentinel 可以通过向另一个 Sentinel 发送

SENTINEL is-master-down-by-addr 命令来询问对方是否认为给定的服务器已下线。）

如果一个服务器没有在 master-down-after-milliseconds 选项所指定的时间内， 对向它发送

PING 命令的 Sentinel 返回一个有效回复（valid reply）， 那么 Sentinel 就会将这个服务器标 记为主观下线。

服务器对 PING 命令的有效回复可以是以下三种回复的其中一种：

返回 +PONG 。

返回 -LOADING 错误。 返回 -MASTERDOWN 错误。

如果服务器返回除以上三种回复之外的其他回复， 又或者在指定时间内没有回复 PING 命 令， 那么 Sentinel 认为服务器返回的回复无效（non-valid）。

注意， 一个服务器必须在 master-down-after-milliseconds 毫秒内， 一直返回无效回复才会

被Sentinel 标记为主观下线。

举个例子， 如果 master-down-after-milliseconds 选项的值为 30000 毫秒（ 30 秒）， 那

么只要服务器能在每 29 秒之内返回至少一次有效回复， 这个服务器就仍然会被认为是处于 正常状态的。

从主观下线状态切换到客观下线状态并没有使用严格的法定人数算法（strong quorum algorithm）， 而是使用了流言协议： 如果 Sentinel 在给定的时间范围内， 从其他 Sentinel 那里接收到了足够数量的主服务器下线报告， 那么 Sentinel 就会将主服务器的状态从主观下 线改变为客观下线。 如果之后其他 Sentinel 不再报告主服务器已下线， 那么客观下线状态就 会被移除。

客观下线条件只适用于主服务器： 对于任何其他类型的 Redis 实例， Sentinel 在将它们判断 为下线前不需要进行协商， 所以从服务器或者其他 Sentinel 永远不会达到客观下线条件。

只要一个 Sentinel 发现某个主服务器进入了客观下线状态， 这个 Sentinel 就可能会被其他 Sentinel 推选出， 并对失效的主服务器执行自动故障迁移操作。

每个 Sentinel 都需要定期执行的任务

每个 Sentinel 以每秒钟一次的频率向它所知的主服务器、从服务器以及其他 Sentinel 实 例发送一个 PING 命令。

如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过

down-after-milliseconds 选项所指定的值， 那么这个实例会被 Sentinel 标记为主观下 线。 一个有效回复可以是： +PONG 、 -LOADING 或者 -MASTERDOWN 。

如果一个主服务器被标记为主观下线， 那么正在监视这个主服务器的所有 Sentinel 要以 每秒一次的频率确认主服务器的确进入了主观下线状态。

Sentinel

48

Redis 中文文档

如果一个主服务器被标记为主观下线， 并且有足够数量的 Sentinel （至少要达到配置文 件指定的数量）在指定的时间范围内同意这一判断， 那么这个主服务器被标记为客观下 线。

在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有主服务器和从服 务器发送 INFO 命令。 当一个主服务器被 Sentinel 标记为客观下线时， Sentinel 向下线 主服务器的所有从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。

当没有足够数量的 Sentinel 同意主服务器已经下线， 主服务器的客观下线状态就会被移 除。 当主服务器重新向 Sentinel 的 PING 命令返回有效回复时， 主服务器的主管下线状 态就会被移除。

自动发现 Sentinel 和从服务器

一个 Sentinel 可以与其他多个 Sentinel 进行连接， 各个 Sentinel 之间可以互相检查对方的可 用性， 并进行信息交换。

你无须为运行的每个 Sentinel 分别设置其他 Sentinel 的地址， 因为 Sentinel 可以通过发布与 订阅功能来自动发现正在监视相同主服务器的其他 Sentinel ， 这一功能是通过向频道

发送信息来实现的。

与此类似， 你也不必手动列出主服务器属下的所有从服务器， 因为 Sentinel 可以通过询问主 服务器来获得所有从服务器的信息。

每个 Sentinel 会以每两秒一次的频率， 通过发布与订阅功能， 向被它监视的所有主服务 器和从服务器的 __sentinel__:hello 频道发送一条信息， 信息中包含了 Sentinel 的 IP 地址、端口号和运行 ID （runid）。

每个 Sentinel 都订阅了被它监视的所有主服务器和从服务器的 __sentinel__:hello 频

道， 查找之前未出现过的 sentinel （looking for unknown sentinels）。 当一个 Sentinel 发现一个新的 Sentinel 时， 它会将新的 Sentinel 添加到一个列表中， 这个列表保存了 Sentinel 已知的， 监视同一个主服务器的所有其他 Sentinel 。

Sentinel 发送的信息中还包括完整的主服务器当前配置（configuration）。 如果一个 Sentinel 包含的主服务器配置比另一个 Sentinel 发送的配置要旧， 那么这个 Sentinel 会 立即升级到新配置上。

在将一个新 Sentinel 添加到监视主服务器的列表上面之前， Sentinel 会先检查列表中是 否已经包含了和要添加的 Sentinel 拥有相同运行 ID 或者相同地址（包括 IP 地址和端口 号）的 Sentinel ， 如果是的话， Sentinel 会先移除列表中已有的那些拥有相同运行 ID 或者相同地址的 Sentinel ， 然后再添加新 Sentinel 。

Sentinel API

在默认情况下， Sentinel 使用 TCP 端口 26379 （普通 Redis 服务器使用的是 6379 ）。

Sentinel

49

Redis 中文文档

Sentinel 接受 Redis 协议格式的命令请求， 所以你可以使用 redis-cli 或者任何其他 Redis 客户端来与 Sentinel 进行通讯。

有两种方式可以和 Sentinel 进行通讯：

第一种方法是通过直接发送命令来查询被监视 Redis 服务器的当前状态， 以及 Sentinel 所知道的关于其他 Sentinel 的信息， 诸如此类。

另一种方法是使用发布与订阅功能， 通过接收 Sentinel 发送的通知： 当执行故障转移操 作， 或者某个被监视的服务器被判断为主观下线或者客观下线时， Sentinel 就会发送相 应的信息。

Sentinel 命令

以下列出的是 Sentinel 接受的命令：

PING ：返回 PONG 。

SENTINEL masters ：列出所有被监视的主服务器，以及这些主服务器的当前状态。

SENTINEL slaves <master name> ：列出给定主服务器的所有从服务器，以及这些从

服务器的当前状态。

SENTINEL get-master-addr-by-name <master name> ： 返回给定名字的主服务器的

IP 地址和端口号。 如果这个主服务器正在执行故障转移操作， 或者针对这个主服务器的 故障转移操作已经完成， 那么这个命令返回新的主服务器的 IP 地址和端口号。

SENTINEL reset <pattern> ： 重置所有名字和给定模式 pattern 相匹配的主服务

器。 pattern 参数是一个 Glob 风格的模式。 重置操作清除主服务器目前的所有状态， 包括正在执行中的故障转移， 并移除目前已经发现和关联的， 主服务器的所有从服务器

和Sentinel 。

SENTINEL failover <master name> ： 当主服务器失效时， 在不询问其他 Sentinel

意见的情况下， 强制开始一次自动故障迁移 （不过发起故障转移的 Sentinel 会向其他 Sentinel 发送一个新的配置，其他 Sentinel 会根据这个配置进行相应的更新）。

发布与订阅信息

客户端可以将 Sentinel 看作是一个只提供了订阅功能的 Redis 服务器： 你不可以使用 PUBLISH 命令向这个服务器发送信息， 但你可以用 SUBSCRIBE 命令或者 PSUBSCRIBE 命令， 通过订阅给定的频道来获取相应的事件提醒。

一个频道能够接收和这个频道的名字相同的事件。 比如说， 名为 +sdown 的频道就可以接收 所有实例进入主观下线（SDOWN）状态的事件。

通过执行 PSUBSCRIBE * 命令可以接收所有事件信息。

以下列出的是客户端可以通过订阅来获得的频道和信息的格式： 第一个英文单词是频道/事件 的名字， 其余的是数据的格式。

Sentinel

50

Redis 中文文档

注意， 当格式中包含 instance details 字样时， 表示频道所返回的信息中包含了以下用于 识别目标实例的内容：

<instance-type> <name> <ip> <port> @ <master-name> <master-ip> <master-port>

@字符之后的内容用于指定主服务器， 这些内容是可选的， 它们仅在 @ 字符之前的内容 指定的实例不是主服务器时使用。

+reset-master <instance details> ：主服务器已被重置。

+slave <instance details> ：一个新的从服务器已经被 Sentinel 识别并关联。 +failover-state-reconf-slaves <instance details> ：故障转移状态切换到了

reconf-slaves 状态。

+failover-detected <instance details> ：另一个 Sentinel 开始了一次故障转移操

作，或者一个从服务器转换成了主服务器。

+slave-reconf-sent <instance details> ：领头（leader）的 Sentinel 向实例发送

了 SLAVEOF 命令，为实例设置新的主服务器。

+slave-reconf-inprog <instance details> ：实例正在将自己设置为指定主服务器

的从服务器，但相应的同步过程仍未完成。

+slave-reconf-done <instance details> ：从服务器已经成功完成对新主服务器的

同步。

-dup-sentinel <instance details> ：对给定主服务器进行监视的一个或多个

Sentinel 已经因为重复出现而被移除 —— 当 Sentinel 实例重启的时候，就会出现这种情 况。

+sentinel <instance details> ：一个监视给定主服务器的新 Sentinel 已经被识别

并添加。

+sdown <instance details> ：给定的实例现在处于主观下线状态。

-sdown <instance details> ：给定的实例已经不再处于主观下线状态。

+odown <instance details> ：给定的实例现在处于客观下线状态。

-odown <instance details> ：给定的实例已经不再处于客观下线状态。

+new-epoch <instance details> ：当前的纪元（epoch）已经被更新。

+try-failover <instance details> ：一个新的故障迁移操作正在执行中，等待被

大多数 Sentinel 选中（waiting to be elected by the majority）。

：赢得指定纪元的选举，可以进行故障迁移 操作了。

+failover-state-select-slave <instance details> ：故障转移操作现在处于

select-slave 状态 —— Sentinel 正在寻找可以升级为主服务器的从服务器。

no-good-slave <instance details> ：Sentinel 操作未能找到适合进行升级的从服

务器。Sentinel 会在一段时间之后再次尝试寻找合适的从服务器来进行升级，又或者直接 放弃执行故障转移操作。

selected-slave <instance details> ：Sentinel 顺利找到适合进行升级的从服务

器。

Sentinel

51

Redis 中文文档

：配置变更，主服务器的 IP 和地址已经改变。 这是绝大多数外部用户都关心的信息。

+tilt ：进入 tilt 模式。

-tilt ：退出 tilt 模式。

故障转移

一次故障转移操作由以下步骤组成：

发现主服务器已经进入客观下线状态。

对我们的当前纪元进行自增（详情请参考 Raft leader election ）， 并尝试在这个纪元中 当选。

如果当选失败， 那么在设定的故障迁移超时时间的两倍之后， 重新尝试当选。 如果当选 成功， 那么执行以下步骤。

选出一个从服务器，并将它升级为主服务器。

向被选中的从服务器发送 SLAVEOF NO ONE 命令，让它转变为主服务器。

通过发布与订阅功能， 将更新后的配置传播给所有其他 Sentinel ， 其他 Sentinel 对它们 自己的配置进行更新。

向已下线主服务器的从服务器发送 SLAVEOF 命令， 让它们去复制新的主服务器。 当所有从服务器都已经开始复制新的主服务器时， 领头 Sentinel 终止这次故障迁移操 作。

Note

每当一个 Redis 实例被重新配置（reconfigured） —— 无论是被设置成主服务器、从服务 器、又或者被设置成其他主服务器的从服务器 —— Sentinel 都会向被重新配置的实例发送一

个 命令， 从而确保这些配置会持久化在硬盘里。

Sentinel 使用以下规则来选择新的主服务器：

在失效主服务器属下的从服务器当中， 那些被标记为主观下线、已断线、或者最后一次 回复 PING 命令的时间大于五秒钟的从服务器都会被淘汰。

在失效主服务器属下的从服务器当中， 那些与失效主服务器连接断开的时长超过

down-after 选项指定的时长十倍的从服务器都会被淘汰。

在经历了以上两轮淘汰之后剩下来的从服务器中， 我们选出复制偏移量（replication

Sentinel

52

Redis 中文文档

offset）最大的那个从服务器作为新的主服务器； 如果复制偏移量不可用， 或者从服务 器的复制偏移量相同， 那么带有最小运行 ID 的那个从服务器成为新的主服务器。

Sentinel 自动故障迁移的一致性特质

Sentinel 自动故障迁移使用 Raft 算法来选举领头（leader） Sentinel ， 从而确保在一个给定 的纪元（epoch）里， 只有一个领头产生。

这表示在同一个纪元中， 不会有两个 Sentinel 同时被选中为领头， 并且各个 Sentinel 在同一 个纪元中只会对一个领头进行投票。

更高的配置纪元总是优于较低的纪元， 因此每个 Sentinel 都会主动使用更新的纪元来代替自 己的配置。

简单来说， 我们可以将 Sentinel 配置看作是一个带有版本号的状态。 一个状态会以最后写入 者胜出（last-write-wins）的方式（也即是，最新的配置总是胜出）传播至所有其他 Sentinel

。

举个例子， 当出现网络分割（network partitions）时， 一个 Sentinel 可能会包含了较旧的配 置， 而当这个 Sentinel 接到其他 Sentinel 发来的版本更新的配置时， Sentinel 就会对自己的 配置进行更新。

如果要在网络分割出现的情况下仍然保持一致性， 那么应该使用 min-slaves-to-write 选

项， 让主服务器在连接的从实例少于给定数量时停止执行写操作， 与此同时， 应该在每个运

行Redis 主服务器或从服务器的机器上运行 Redis Sentinel 进程。

Sentinel 状态的持久化

Sentinel 的状态会被持久化在 Sentinel 配置文件里面。

每当 Sentinel 接收到一个新的配置， 或者当领头 Sentinel 为主服务器创建一个新的配置时， 这个配置会与配置纪元一起被保存到磁盘里面。

这意味着停止和重启 Sentinel 进程都是安全的。

Sentinel 在非故障迁移的情况下对实例进行重新配置

即使没有自动故障迁移操作在进行， Sentinel 总会尝试将当前的配置设置到被监视的实例上 面。 特别是：

根据当前的配置， 如果一个从服务器被宣告为主服务器， 那么它会代替原有的主服务 器， 成为新的主服务器， 并且成为原有主服务器的所有从服务器的复制对象。

那些连接了错误主服务器的从服务器会被重新配置， 使得这些从服务器会去复制正确的 主服务器。

Sentinel

53

Redis 中文文档

不过， 在以上这些条件满足之后， Sentinel 在对实例进行重新配置之前仍然会等待一段足够 长的时间， 确保可以接收到其他 Sentinel 发来的配置更新， 从而避免自身因为保存了过期的 配置而对实例进行了不必要的重新配置。

TILT 模式

Redis Sentinel 严重依赖计算机的时间功能： 比如说， 为了判断一个实例是否可用， Sentinel 会记录这个实例最后一次相应 PING 命令的时间， 并将这个时间和当前时间进行对 比， 从而知道这个实例有多长时间没有和 Sentinel 进行任何成功通讯。

不过， 一旦计算机的时间功能出现故障， 或者计算机非常忙碌， 又或者进程因为某些原因而 被阻塞时， Sentinel 可能也会跟着出现故障。

TILT 模式是一种特殊的保护模式： 当 Sentinel 发现系统有些不对劲时， Sentinel 就会进入 TILT 模式。

因为 Sentinel 的时间中断器默认每秒执行 10 次， 所以我们预期时间中断器的两次执行之间 的间隔为 100 毫秒左右。 Sentinel 的做法是， 记录上一次时间中断器执行时的时间， 并将 它和这一次时间中断器执行的时间进行对比：

如果两次调用时间之间的差距为负值， 或者非常大（超过 2 秒钟）， 那么 Sentinel 进入 TILT 模式。

如果 Sentinel 已经进入 TILT 模式， 那么 Sentinel 延迟退出 TILT 模式的时间。

当 Sentinel 进入 TILT 模式时， 它仍然会继续监视所有目标， 但是：

它不再执行任何操作，比如故障转移。

当有实例向这个 Sentinel 发送 SENTINEL is-master-down-by-addr 命令时， Sentinel 返回

负值： 因为这个 Sentinel 所进行的下线判断已经不再准确。

如果 TILT 可以正常维持 30 秒钟， 那么 Sentinel 退出 TILT 模式。

处理 -BUSY 状态

Warning

该功能尚未实现

当 Lua 脚本的运行时间超过指定时限时， Redis 就会返回 -BUSY 错误。

当出现这种情况时， Sentinel 在尝试执行故障转移操作之前， 会先向服务器发送一个 SCRIPT KILL 命令， 如果服务器正在执行的是一个只读脚本的话， 那么这个脚本就会被杀 死， 服务器就会回到正常状态。

Sentinel

54

Redis 中文文档

Sentinel 的客户端实现

关于 Sentinel 客户端的实现信息可以参考 Sentinel 客户端指引手册 。

Sentinel

55

Redis 中文文档

集群教程

Note

本文档翻译自 http://redis.io/topics/cluster-tutorial 。

本文档是 Redis 集群的入门教程， 从用户的角度介绍了设置、测试和操作集群的方法。

本教程不包含晦涩难懂的分布式概念， 也没有像 Redis 集群规范 那样包含 Redis 集群的实现 细节， 如果你打算深入地学习 Redis 集群的部署方法， 那么推荐你在阅读完这个教程之后， 再去看一看集群规范。

Redis 集群目前仍处于 Alpha 测试版本， 如果在使用过程中发现任何问题， 请到 Redis 的 邮件列表 发贴， 或者到 Redis 的 Github 页面 报告错误。

集群简介

Redis 集群是一个可以在多个 Redis 节点之间进行数据共享的设施（installation）。

Redis 集群不支持那些需要同时处理多个键的 Redis 命令， 因为执行这些命令需要在多个 Redis 节点之间移动数据， 并且在高负载的情况下， 这些命令将降低 Redis 集群的性能， 并 导致不可预测的行为。

Redis 集群通过分区（partition）来提供一定程度的可用性（availability）： 即使集群中有一 部分节点失效或者无法进行通讯， 集群也可以继续处理命令请求。

Redis 集群提供了以下两个好处：

将数据自动切分（split）到多个节点的能力。

当集群中的一部分节点失效或者无法进行通讯时， 仍然可以继续处理命令请求的能力。

Redis 集群数据共享

Redis 集群使用数据分片（sharding）而非一致性哈希（consistency hashing）来实现： 一

个Redis 集群包含 16384 个哈希槽（hash slot）， 数据库中的每个键都属于这 16384 个哈 希槽的其中一个， 集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽， 其中

CRC16(key) 语句用于计算键 key 的 CRC16 校验和 。

集群中的每个节点负责处理一部分哈希槽。 举个例子， 一个集群可以有三个哈希槽， 其中：

节点 A 负责处理 0 号至 5500 号哈希槽。

节点 B 负责处理 5501 号至 11000 号哈希槽。

集群教程

56

Redis 中文文档

节点 C 负责处理 11001 号至 16384 号哈希槽。

这种将哈希槽分布到不同节点的做法使得用户可以很容易地向集群中添加或者删除节点。 比 如说：

如果用户将新节点 D 添加到集群中， 那么集群只需要将节点 A 、B 、 C 中的某些槽移 动到节点 D 就可以了。

与此类似， 如果用户要从集群中移除节点 A ， 那么集群只需要将节点 A 中的所有哈希槽 移动到节点 B 和节点 C ， 然后再移除空白（不包含任何哈希槽）的节点 A 就可以了。

因为将一个哈希槽从一个节点移动到另一个节点不会造成节点阻塞， 所以无论是添加新节点 还是移除已存在节点， 又或者改变某个节点包含的哈希槽数量， 都不会造成集群下线。

Redis 集群中的主从复制

为了使得集群在一部分节点下线或者无法与集群的大多数（majority）节点进行通讯的情况 下， 仍然可以正常运作， Redis 集群对节点使用了主从复制功能： 集群中的每个节点都有

1个至 N 个复制品（replica）， 其中一个复制品为主节点（master）， 而其余的 N-1 个 复制品为从节点（slave）。

在之前列举的节点 A 、B 、C 的例子中， 如果节点 B 下线了， 那么集群将无法正常运行， 因为集群找不到节点来处理 5501 号至 11000 号的哈希槽。

另一方面， 假如在创建集群的时候（或者至少在节点 B 下线之前）， 我们为主节点 B 添加 了从节点 B1 ， 那么当主节点 B 下线的时候， 集群就会将 B1 设置为新的主节点， 并让它代 替下线的主节点 B ， 继续处理 5501 号至 11000 号的哈希槽， 这样集群就不会因为主节点

B的下线而无法正常运作了。

不过如果节点 B 和 B1 都下线的话， Redis 集群还是会停止运作。

Redis 集群的一致性保证（guarantee）

Redis 集群不保证数据的强一致性（strong consistency）： 在特定条件下， Redis 集群可能 会丢失已经被执行过的写命令。

使用异步复制（asynchronous replication）是 Redis 集群可能会丢失写命令的其中一个原 因。 考虑以下这个写命令的例子：

客户端向主节点 B 发送一条写命令。

主节点 B 执行写命令，并向客户端返回命令回复。

主节点 B 将刚刚执行的写命令复制给它的从节点 B1 、 B2 和 B3 。

集群教程

57

Redis 中文文档

如你所见， 主节点对命令的复制工作发生在返回命令回复之后， 因为如果每次处理命令请求 都需要等待复制操作完成的话， 那么主节点处理命令请求的速度将极大地降低 —— 我们必须 在性能和一致性之间做出权衡。

Note

如果真的有必要的话， Redis 集群可能会在将来提供同步地（synchronou）执行写命令的方 法。

Redis 集群另外一种可能会丢失命令的情况是， 集群出现网络分裂（network partition）， 并 且一个客户端与至少包括一个主节点在内的少数（minority）实例被孤立。

举个例子， 假设集群包含 A 、 B 、 C 、 A1 、 B1 、 C1 六个节点， 其中 A 、B 、C 为主节 点， 而 A1 、B1 、C1 分别为三个主节点的从节点， 另外还有一个客户端 Z1 。

假设集群中发生网络分裂， 那么集群可能会分裂为两方， 大多数（majority）的一方包含节

点A 、C 、A1 、B1 和 C1 ， 而少数（minority）的一方则包含节点 B 和客户端 Z1 。

在网络分裂期间， 主节点 B 仍然会接受 Z1 发送的写命令：

如果网络分裂出现的时间很短， 那么集群会继续正常运行；

但是， 如果网络分裂出现的时间足够长， 使得大多数一方将从节点 B1 设置为新的主节 点， 并使用 B1 来代替原来的主节点 B ， 那么 Z1 发送给主节点 B 的写命令将丢失。

注意， 在网络分裂出现期间， 客户端 Z1 可以向主节点 B 发送写命令的最大时间是有限制 的， 这一时间限制称为节点超时时间（node timeout）， 是 Redis 集群的一个重要的配置选 项：

对于大多数一方来说， 如果一个主节点未能在节点超时时间所设定的时限内重新联系上 集群， 那么集群会将这个主节点视为下线， 并使用从节点来代替这个主节点继续工作。 对于少数一方， 如果一个主节点未能在节点超时时间所设定的时限内重新联系上集群， 那么它将停止处理写命令， 并向客户端报告错误。

创建并使用 Redis 集群

Redis 集群由多个运行在集群模式（cluster mode）下的 Redis 实例组成， 实例的集群模式 需要通过配置来开启， 开启集群模式的实例将可以使用集群特有的功能和命令。

以下是一个包含了最少选项的集群配置文件示例：

port 7000 cluster-enabled yes cluster-config-file nodes.conf cluster-node-timeout 5000 appendonly yes

集群教程

58

Redis 中文文档

文件中的 cluster-enabled 选项用于开实例的集群模式， 而 cluster-conf-file 选项则设定

了保存节点配置文件的路径， 默认值为 nodes.conf 。

节点配置文件无须人为修改， 它由 Redis 集群在启动时创建， 并在有需要时自动进行更新。

要让集群正常运作至少需要三个主节点， 不过在刚开始试用集群功能时， 强烈建议使用六个 节点： 其中三个为主节点， 而其余三个则是各个主节点的从节点。

首先， 让我们进入一个新目录， 并创建六个以端口号为名字的子目录， 稍后我们在将每个目 录中运行一个 Redis 实例：

mkdir cluster-test cd cluster-test

mkdir 7000 7001 7002 7003 7004 7005

在文件夹 7000 至 7005 中， 各创建一个 redis.conf 文件， 文件的内容可以使用上面的 示例配置文件， 但记得将配置中的端口号从 7000 改为与文件夹名字相同的号码。

现在， 从 Redis Github 页面 的 unstable 分支中取出最新的 Redis 源码， 编译出可执行文

件redis-server ， 并将文件复制到 cluster-test 文件夹， 然后使用类似以下命令， 在每

个标签页中打开一个实例：

cd 7000

../redis-server ./redis.conf

实例打印的日志显示， 因为 nodes.conf 文件不存在， 所以每个节点都为它自身指定了一个 新的 ID ：

[82462] 26 Nov 11:56:55.329 * No cluster configuration found, I'm 97a3a64667477371c447932

实例会一直使用同一个 ID ， 从而在集群中保持一个独一无二（unique）的名字。

每个节点都使用 ID 而不是 IP 或者端口号来记录其他节点， 因为 IP 地址和端口号都可能会改 变， 而这个独一无二的标识符（identifier）则会在节点的整个生命周期中一直保持不变。

我们将这个标识符称为节点 ID。

创建集群

现在我们已经有了六个正在运行中的 Redis 实例， 接下来我们需要使用这些实例来创建集 群， 并为每个节点编写配置文件。

集群教程

59

Redis 中文文档

通过使用 Redis 集群命令行工具 redis-trib ， 编写节点配置文件的工作可以非常容易地完 成： redis-trib 位于 Redis 源码的 src 文件夹中， 它是一个 Ruby 程序， 这个程序通过 向实例发送特殊命令来完成创建新集群， 检查集群， 或者对集群进行重新分片（reshared） 等工作。

我们需要执行以下命令来创建集群：

./redis-trib.rb create --replicas 1 127.0.0.1:7000 127.0.0.1:7001 \ 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005

命令的意义如下：

给定 redis-trib.rb 程序的命令是 create ， 这表示我们希望创建一个新的集群。 选项 --replicas 1 表示我们希望为集群中的每个主节点创建一个从节点。

之后跟着的其他参数则是实例的地址列表， 我们希望程序使用这些地址所指示的实例来 创建新集群。

简单来说， 以上命令的意思就是让 redis-trib 程序创建一个包含三个主节点和三个从节点 的集群。

接着， redis-trib 会打印出一份预想中的配置给你看， 如果你觉得没问题的话， 就可以输 入 yes ， redis-trib 就会将这份配置应用到集群当中：

>>> Creating cluster

Connecting to node 127.0.0.1:7000: OK

Connecting to node 127.0.0.1:7001: OK

Connecting to node 127.0.0.1:7002: OK

Connecting to node 127.0.0.1:7003: OK

Connecting to node 127.0.0.1:7004: OK

Connecting to node 127.0.0.1:7005: OK

>>>Performing hash slots allocation on 6 nodes...

Using 3 masters: 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002

127.0.0.1:7000 replica #1 is 127.0.0.1:7003 127.0.0.1:7001 replica #1 is 127.0.0.1:7004 127.0.0.1:7002 replica #1 is 127.0.0.1:7005

M: 9991306f0e50640a5684f1958fd754b38fa034c9 127.0.0.1:7000 slots:0-5460 (5461 slots) master

M: e68e52cee0550f558b03b342f2f0354d2b8a083b 127.0.0.1:7001 slots:5461-10921 (5461 slots) master

M: 393c6df5eb4b4cec323f0e4ca961c8b256e3460a 127.0.0.1:7002 slots:10922-16383 (5462 slots) master

S: 48b728dbcedff6bf056231eb44990b7d1c35c3e0 127.0.0.1:7003

S: 345ede084ac784a5c030a0387f8aaa9edfc59af3 127.0.0.1:7004

S: 3375be2ccc321932e8853234ffa87ee9fde973ff 127.0.0.1:7005

Can I set the above configuration? (type 'yes' to accept): yes

输入 yes 并按下回车确认之后， 集群就会将配置应用到各个节点， 并连接起（join）各个节 点 —— 也即是， 让各个节点开始互相通讯：

集群教程

60

Redis 中文文档

>>>Nodes configuration updated

>>>Sending CLUSTER MEET messages to join the cluster Waiting for the cluster to join...

>>>Performing Cluster Check (using node 127.0.0.1:7000) M: 9991306f0e50640a5684f1958fd754b38fa034c9 127.0.0.1:7000 slots:0-5460 (5461 slots) master

M: e68e52cee0550f558b03b342f2f0354d2b8a083b 127.0.0.1:7001 slots:5461-10921 (5461 slots) master

M: 393c6df5eb4b4cec323f0e4ca961c8b256e3460a 127.0.0.1:7002 slots:10922-16383 (5462 slots) master

M: 48b728dbcedff6bf056231eb44990b7d1c35c3e0 127.0.0.1:7003

slots: (0 slots) master

M: 345ede084ac784a5c030a0387f8aaa9edfc59af3 127.0.0.1:7004

slots: (0 slots) master

M: 3375be2ccc321932e8853234ffa87ee9fde973ff 127.0.0.1:7005

slots: (0 slots) master

[OK] All nodes agree about slots configuration.

如果一切正常的话， redis-trib 将输出以下信息：

>>>Check for open slots...

>>>Check slots coverage...

[OK] All 16384 slots covered.

这表示集群中的 16384 个槽都有至少一个主节点在处理， 集群运作正常。

集群的客户端

Redis 集群现阶段的一个问题是客户端实现很少。 以下是一些我知道的实现：

redis-rb-cluster 是我（@antirez）编写的 Ruby 实现， 用于作为其他实现的参考。 该

实现是对 redis-rb 的一个简单包装， 高效地实现了与集群进行通讯所需的最少语义 （semantic）。

redis-py-cluster 看上去是 redis-rb-cluster 的一个 Python 版本， 这个项目有一段

时间没有更新了（最后一次提交是在六个月之前）， 不过可以将这个项目用作学习集群 的起点。

流行的 Predis 曾经对早期的 Redis 集群有过一定的支持， 但我不确定它对集群的支持是 否完整， 也不清楚它是否和最新版本的 Redis 集群兼容 （因为新版的 Redis 集群将槽的 数量从 4k 改为 16k 了）。

Redis unstable 分支中的 redis-cli 程序实现了非常基本的集群支持， 可以使用命令

redis-cli -c 来启动。

测试 Redis 集群比较简单的办法就是使用 redis-rb-cluster 或者 redis-cli ， 接下来我们

将使用 redis-cli 为例来进行演示：

集群教程

61

Redis 中文文档

$ redis-cli -c -p 7000

redis 127.0.0.1:7000> set foo bar

-> Redirected to slot [12182] located at 127.0.0.1:7002

OK

redis 127.0.0.1:7002> set hello world

-> Redirected to slot [866] located at 127.0.0.1:7000

OK

redis 127.0.0.1:7000> get foo

-> Redirected to slot [12182] located at 127.0.0.1:7002 "bar"

redis 127.0.0.1:7000> get hello

-> Redirected to slot [866] located at 127.0.0.1:7000 "world"

redis-cli 对集群的支持是非常基本的， 所以它总是依靠 Redis 集群节点来将它转向 （redirect）至正确的节点。

一个真正的（serious）集群客户端应该做得比这更好： 它应该用缓存记录起哈希槽与节点地 址之间的映射（map）， 从而直接将命令发送到正确的节点上面。

这种映射只会在集群的配置出现某些修改时变化， 比如说， 在一次故障转移（failover）之 后， 或者系统管理员通过添加节点或移除节点来修改了集群的布局（layout）之后， 诸如此 类。

使用 redis-rb-cluster 编写一个示例应用

在展示如何使用集群进行故障转移、重新分片等操作之前， 我们需要创建一个示例应用， 了 解一些与 Redis 集群客户端进行交互的基本方法。

在运行示例应用的过程中， 我们会尝试让节点进入失效状态， 又或者开始一次重新分片， 以 此来观察 Redis 集群在真实世界运行时的表现， 并且为了让这个示例尽可能地有用， 我们会 让这个应用向集群进行写操作。

本节将通过两个示例应用来展示 redis-rb-cluster 的基本用法， 以下是本节的第一个示例应 用， 它是一个名为 example.rb 的文件， 包含在redis-rb-cluster 项目里面：

|

集群教程

62

Redis 中文文档

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

26

27

28

29

30

|

require './cluster'

startup_nodes = [

{:host => "127.0.0.1", :port => 7000}, {:host => "127.0.0.1", :port => 7001}

]

rc = RedisCluster.new(startup_nodes,32,:timeout => 0.1)

last = false

while not last begin

last = rc.get("__last__") last = 0 if !last

rescue => e

puts "error #{e.to_s}" sleep 1

end

end

((last.to_i+1)..1000000000).each{|x|

begin rc.set("foo#{x}",x) puts rc.get("foo#{x}") rc.set("__last__",x)

rescue => e

puts "error #{e.to_s}"

end sleep 0.1

}

|

集群教程

63

Redis 中文文档

这个应用所做的工作非常简单： 它不断地以 foo<number> 为键， number 为值， 使用

SET 命令向数据库设置键值对。

如果我们执行这个应用的话， 应用将按顺序执行以下命令：

SET foo0 0

SET foo1 1

SET foo2 2

诸如此类。。。

代码中的每个集群操作都使用一个 begin 和 rescue 代码块（block）包裹着， 因为我们希 望在代码出错时， 将错误打印到终端上面， 而不希望应用因为异常（exception）而退出。

代码的第七行是代码中第一个有趣的地方， 它创建了一个 Redis 集群对象， 其中创建对象所 使用的参数及其意义如下：

第一个参数是记录了启动节点的 startup_nodes 列表， 列表中包含了两个集群节点的地 址。

第二个参数指定了对于集群中的各个不同的节点， Redis 集群对象可以获得（take）的 最大连接数 （maximum number of connections this object is allowed to take）。

第三个参数 timeout 指定了一个命令在执行多久之后， 才会被看作是执行失败。

记住， 启动列表中并不需要包含所有集群节点的地址， 但这些地址中至少要有一个是有效的 （reachable）： 一旦 redis-rb-cluster 成功连接上集群中的某个节点时， 集群节点列表就 会被自动更新， 任何真正的（serious）的集群客户端都应该这样做。

现在， 程序创建的 Redis 集群对象实例被保存到 rc 变量里面， 我们可以将这个对象当作 普通 Redis 对象实例来使用。

在十一至十九行， 我们先尝试阅读计数器中的值， 如果计数器不存在的话， 我们才将计数器 初始化为 0 ： 通过将计数值保存到 Redis 的计数器里面， 我们可以在示例重启之后， 仍然 继续之前的执行过程， 而不必每次重启之后都从 foo0 开始重新设置键值对。

为了让程序在集群下线的情况下， 仍然不断地尝试读取计数器的值， 我们将读取操作包含在 了一个 while 循环里面， 一般的应用程序并不需要如此小心。

二十一至三十行是程序的主循环， 这个循环负责设置键值对， 并在设置出错时打印错误信 息。

程序在主循环的末尾添加了一个 sleep 调用， 让写操作的执行速度变慢， 帮助执行示例的 人更容易看清程序的输出。

执行 example.rb 程序将产生以下输出：

集群教程

64

Redis 中文文档

ruby ./example.rb 1 2 3 4 5 6 7 8 9

...

这个程序并不是十分有趣， 稍后我们就会看到一个更有趣的集群应用示例， 不过在此之前， 让我们先使用这个示例来演示集群的重新分片操作。

对集群进行重新分片

现在， 让我们来试试对集群进行重新分片操作。

在执行重新分片的过程中， 请让你的 example.rb 程序处于运行状态， 这样你就会看到， 重 新分片并不会对正在运行的集群程序产生任何影响， 你也可以考虑将 example.rb 中的 sleep 调用删掉， 从而让重新分片操作在近乎真实的写负载下执行。

重新分片操作基本上就是将某些节点上的哈希槽移动到另外一些节点上面， 和创建集群一 样， 重新分片也可以使用 redis-trib 程序来执行。

执行以下命令可以开始一次重新分片操作：

$ ./redis-trib.rb reshard 127.0.0.1:7000

你只需要指定集群中其中一个节点的地址， redis-trib 就会自动找到集群中的其他节点。

目前 redis-trib 只能在管理员的协助下完成重新分片的工作， 要让 redis-trib 自动将哈 希槽从一个节点移动到另一个节点， 目前来说还做不到 （不过实现这个功能并不难）。

执行 redis-trib 的第一步就是设定你打算移动的哈希槽的数量：

集群教程

65

Redis 中文文档

$./redis-trib.rb reshard 127.0.0.1:7000 Connecting to node 127.0.0.1:7000: OK Connecting to node 127.0.0.1:7002: OK Connecting to node 127.0.0.1:7005: OK Connecting to node 127.0.0.1:7001: OK Connecting to node 127.0.0.1:7003: OK Connecting to node 127.0.0.1:7004: OK

>>> Performing Cluster Check (using node 127.0.0.1:7000) M: 9991306f0e50640a5684f1958fd754b38fa034c9 127.0.0.1:7000 slots:0-5460 (5461 slots) master

M: 393c6df5eb4b4cec323f0e4ca961c8b256e3460a 127.0.0.1:7002 slots:10922-16383 (5462 slots) master

S: 3375be2ccc321932e8853234ffa87ee9fde973ff 127.0.0.1:7005

slots: (0 slots) slave

M: e68e52cee0550f558b03b342f2f0354d2b8a083b 127.0.0.1:7001 slots:5461-10921 (5461 slots) master

S: 48b728dbcedff6bf056231eb44990b7d1c35c3e0 127.0.0.1:7003

slots: (0 slots) slave

S: 345ede084ac784a5c030a0387f8aaa9edfc59af3 127.0.0.1:7004

slots: (0 slots) slave

[OK] All nodes agree about slots configuration.

>>> Check for open slots...

>>> Check slots coverage...

[OK] All 16384 slots covered.

How many slots do you want to move (from 1 to 16384)? 1000

我们将打算移动的槽数量设置为 1000 个， 如果 example.rb 程序一直运行着的话， 现在 1000 个槽里面应该有不少键了。

除了移动的哈希槽数量之外， redis-trib 还需要知道重新分片的目标（target node）， 也 即是， 负责接收这 1000 个哈希槽的节点。

指定目标需要使用节点的 ID ， 而不是 IP 地址和端口。 比如说， 我们打算使用集群的第一个 主节点来作为目标， 它的 IP 地址和端口是 127.0.0.1:7000 ， 而节点 ID 则是

9991306f0e50640a5684f1958fd754b38fa034c9 ， 那么我们应该向 redis-trib 提供节点的 ID ：

$./redis-trib.rb reshard 127.0.0.1:7000

...

What is the receiving node ID? 9991306f0e50640a5684f1958fd754b38fa034c9

Note

redis-trib 会打印出集群中所有节点的 ID ， 并且我们也可以通过执行以下命令来获得节点 的运行 ID ：

$./redis-cli -p 7000 cluster nodes | grep myself 9991306f0e50640a5684f1958fd754b38fa034c9 :0 myself,master - 0 0 0 connected 0-5460

接着， redis-trib 会向你询问重新分片的源节点（source node）， 也即是， 要从哪个节 点中取出 1000 个哈希槽， 并将这些槽移动到目标节点上面。

如果我们不打算从特定的节点上取出指定数量的哈希槽， 那么可以向 redis-trib 输入 all ， 这样的话， 集群中的所有主节点都会成为源节点， redis-trib 将从各个源节点中各取出 一部分哈希槽， 凑够 1000 个， 然后移动到目标节点上面：

集群教程

66

Redis 中文文档

$./redis-trib.rb reshard 127.0.0.1:7000

...

Please enter all the source node IDs.

Type 'all' to use all the nodes as source nodes for the hash slots. Type 'done' once you entered all the source nodes IDs.

Source node #1:all

输入 all 并按下回车之后， redis-trib 将打印出哈希槽的移动计划， 如果你觉得没问题 的话， 就可以输入 yes 并再次按下回车：

$./redis-trib.rb reshard 127.0.0.1:7000

...

Moving slot 11421 from 393c6df5eb4b4cec323f0e4ca961c8b256e3460a Moving slot 11422 from 393c6df5eb4b4cec323f0e4ca961c8b256e3460a Moving slot 5461 from e68e52cee0550f558b03b342f2f0354d2b8a083b Moving slot 5469 from e68e52cee0550f558b03b342f2f0354d2b8a083b

...

Moving slot 5959 from e68e52cee0550f558b03b342f2f0354d2b8a083b

Do you want to proceed with the proposed reshard plan (yes/no)? yes

输入 yes 并使用按下回车之后， 就会正式开始执行重新分片操作， 将指定的 哈希槽从源节点一个个地移动到目标节点上面：

$./redis-trib.rb reshard 127.0.0.1:7000

...

Moving slot 5934 from 127.0.0.1:7001 to 127.0.0.1:7000: Moving slot 5935 from 127.0.0.1:7001 to 127.0.0.1:7000: Moving slot 5936 from 127.0.0.1:7001 to 127.0.0.1:7000: Moving slot 5937 from 127.0.0.1:7001 to 127.0.0.1:7000:

...

Moving slot 5959 from 127.0.0.1:7001 to 127.0.0.1:7000:

在重新分片的过程中， example.rb 应该可以继续正常运行， 不会出现任何问题。 在重新分片操作执行完毕之后， 可以使用以下命令来检查集群是否正常：

集群教程

67

Redis 中文文档

$./redis-trib.rb check 127.0.0.1:7000 Connecting to node 127.0.0.1:7000: OK Connecting to node 127.0.0.1:7002: OK Connecting to node 127.0.0.1:7005: OK Connecting to node 127.0.0.1:7001: OK Connecting to node 127.0.0.1:7003: OK Connecting to node 127.0.0.1:7004: OK

>>> Performing Cluster Check (using node 127.0.0.1:7000) M: 9991306f0e50640a5684f1958fd754b38fa034c9 127.0.0.1:7000 slots:0-5959,10922-11422 (6461 slots) master

M: 393c6df5eb4b4cec323f0e4ca961c8b256e3460a 127.0.0.1:7002 slots:11423-16383 (4961 slots) master

S: 3375be2ccc321932e8853234ffa87ee9fde973ff 127.0.0.1:7005

slots: (0 slots) slave

M: e68e52cee0550f558b03b342f2f0354d2b8a083b 127.0.0.1:7001 slots:5960-10921 (4962 slots) master

S: 48b728dbcedff6bf056231eb44990b7d1c35c3e0 127.0.0.1:7003

slots: (0 slots) slave

S: 345ede084ac784a5c030a0387f8aaa9edfc59af3 127.0.0.1:7004

slots: (0 slots) slave

[OK] All nodes agree about slots configuration.

>>> Check for open slots...

>>> Check slots coverage...

[OK] All 16384 slots covered.

根据检查结果显示， 集群运作正常。

需要注意的就是， 在三个主节点中， 节点 127.0.0.1:7000 包含了 6461 个哈希槽， 而节点

127.0.0.1:7001 和节点 127.0.0.1:7002 都只包含了 4961 个哈希槽， 因为后两者都将自己

的500 个哈希槽移动到了节点 127.0.0.1:7000 。

一个更有趣的示例应用

我们在前面使用的示例程序 example.rb 并不是十分有趣， 因为它只是不断地对集群进行写 入， 但并不检查写入结果是否正确。 比如说， 集群可能会错误地将 example.rb 发送的所有 SET 命令都改成了 SET foo 42 ， 但因为 example.rb 并不检查写入后的值， 所以它不会意 识到集群实际上写入的值是错误的。

因为这个原因， redis-rb-cluster 项目包含了一个名为 consistency-test.rb 的示例应用， 这个 应用比起 example.rb 有趣得多： 它创建了多个计数器（默认为 1000 个）， 并通过发送 INCR 命令来增加这些计数器的值。

在增加计数器值的同时， consistency-test.rb 还执行以下操作：

每次使用 INCR 命令更新一个计数器时， 应用会记录下计数器执行 INCR 命令之后应该 有的值。 举个例子， 如果计数器的起始值为 0 ， 而这次是程序第 50 次向它发送 INCR 命令， 那么计数器的值应该是 50 。

在每次发送 INCR 命令之前， 程序会随机从集群中读取一个计数器的值， 并将它与自己 记录的值进行对比， 看两个值是否相同。

集群教程

68

Redis 中文文档

换句话说， 这个程序是一个一致性检查器（consistency checker）： 如果集群在执行 INCR 命令的过程中， 丢失了某条 INCR 命令， 又或者多执行了某条客户端没有确认到的 INCR 命 令， 那么检查器将察觉到这一点 —— 在前一种情况中， consistency-test.rb 记录的计数器 值将比集群记录的计数器值要大； 而在后一种情况中， consistency-test.rb 记录的计数器 值将比集群记录的计数器值要小。

运行 consistency-test 程序将产生类似以下的输出：

$ ruby consistency-test.rb

925 R (0 err) | 925 W (0 err) | 5030 R (0 err) | 5030 W (0 err) | 9261 R (0 err) | 9261 W (0 err) | 13517 R (0 err) | 13517 W (0 err) | 17780 R (0 err) | 17780 W (0 err) | 22025 R (0 err) | 22025 W (0 err) | 25818 R (0 err) | 25818 W (0 err) |

每行输出都打印了程序执行的读取次数和写入次数， 以及执行操作的过程中因为集群不可用 而产生的错误数。

如果程序察觉了不一致的情况出现， 它将在输出行的末尾显式不一致的详细情况。

比如说， 如果我们在 consistency-test.rb 运行的过程中， 手动修改某个计数器的值：

$redis 127.0.0.1:7000> set key_217 0

OK

那么 consistency-test.rb 将向我们报告不一致情况：

(in the other tab I see...)

94774 R (0 err) | 94774 W (0 err) | 98821 R (0 err) | 98821 W (0 err) |

102886 R (0 err) | 102886 W (0 err) | 114 lost | 107046 R (0 err) | 107046 W (0 err) | 114 lost |

在我们修改计数器值的时候， 计数器的正确值是 114 （执行了 114 次 INCR 命令）， 因

为我们将计数器的值设成了 0 ， 所以 consistency-test.rb 会向我们报告说丢失了 114

个INCR 命令。

因为这个示例程序具有一致性检查功能， 所以我们用它来测试 Redis 集群的故障转移操作。

故障转移测试

Note

在执行本节操作的过程中， 请一直运行 程序。

要触发一次故障转移， 最简单的办法就是令集群中的某个主节点进入下线状态。

集群教程

69

Redis 中文文档

首先用以下命令列出集群中的所有主节点：

$ redis-cli -p 7000 cluster nodes | grep master

3e3a6cb0d9a9a87168e266b0a0b24026c0aae3f0 127.0.0.1:7001 master - 0 1385482984082 0 connec 2938205e12de373867bf38f1ca29d31d0ddb3e46 127.0.0.1:7002 master - 0 1385482983582 0 connec 97a3a64667477371c4479320d683e4c8db5858b1 :0 myself,master - 0 0 0 connected 0-5959 10922-

通过命令输出， 我们知道端口号为 7000 、 7001 和 7002 的节点都是主节点， 然后我们 可以通过向端口号为 7002 的主节点发送 DEBUG SEGFAULT 命令， 让这个主节点崩溃：

$redis-cli -p 7002 debug segfault Error: Server closed the connection

现在， 切换到运行着 consistency-test 的标签页， 可以看到， consistency-test 在 7002

下线之后的一段时间里将产生大量的错误警告信息：

18849	R (0 err) | 18849		W (0 err) |
23151	R (0 err) |	23151	W (0 err) |
27302	R (0 err) |	27302	W (0 err) |

... many error warnings here ...
29659	R	(578	err) | 29660		W	(577 err) |
33749	R	(578	err) | 33750		W	(577	err) |
37918	R	(578	err) |	37919	W	(577	err) |
42077	R	(578	err) |	42078	W	(577	err) |

从consistency-test 的这段输出可以看到， 集群在执行故障转移期间， 总共丢失了 578 个读命令和 577 个写命令， 但是并没有产生任何数据不一致。

这听上去可能有点奇怪， 因为在教程的开头我们提到过， Redis 使用的是异步复制， 在执行 故障转移期间， 集群可能会丢失写命令。

但是在实际上， 丢失命令的情况并不常见， 因为 Redis 几乎是同时执行将命令回复发送给客 户端， 以及将命令复制给从节点这两个操作， 所以实际上造成命令丢失的时间窗口是非常小 的。

不过， 尽管出现的几率不高， 但丢失命令的情况还是有可能会出现的， 所以我们对 Redis 集群不能提供强一致性的这一描述仍然是正确的。

现在， 让我们使用 cluster nodes 命令， 查看集群在执行故障转移操作之后， 主从节点的 布局情况：

集群教程

70

Redis 中文文档

$ redis-cli -p 7000 cluster nodes

3fc783611028b1707fd65345e763befb36454d73 127.0.0.1:7004 slave 3e3a6cb0d9a9a87168e266b0a0b a211e242fc6b22a9427fed61285e85892fa04e08 127.0.0.1:7003 slave 97a3a64667477371c4479320d68 97a3a64667477371c4479320d683e4c8db5858b1 :0 myself,master - 0 0 0 connected 0-5959 10922- 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 127.0.0.1:7005 master - 0 1385503419023 3 connec 3e3a6cb0d9a9a87168e266b0a0b24026c0aae3f0 127.0.0.1:7001 master - 0 1385503417005 0 connec 2938205e12de373867bf38f1ca29d31d0ddb3e46 127.0.0.1:7002 slave 3c3a0c74aae0b56170ccb03a76b

我重启了之前下线的 127.0.0.1:7002 节点， 该节点已经从原来的主节点变成了从节点， 而

现在集群中的三个主节点分别是 127.0.0.1:7000 、 127.0.0.1:7001 和 127.0.0.1:7005 ， 其中 127.0.0.1:7005 就是因为 127.0.0.1:7002 下线而变成主节点的。

cluster nodes 命令的输出有点儿复杂， 它的每一行都是由以下信息组成的：

节点 ID ：例如 3fc783611028b1707fd65345e763befb36454d73 。

ip:port ：节点的 IP 地址和端口号， 例如 127.0.0.1:7000 ， 其中 :0 表示的是客户

端当前连接的 IP 地址和端口号。

flags ：节点的角色（例如 master 、 slave 、 myself ）以及状态（例如 fail ，

等等）。

如果节点是一个从节点的话， 那么跟在 flags 之后的将是主节点的节点 ID ： 例如

127.0.0.1:7002 的主节点的节点 ID 就是 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 。

集群最近一次向节点发送 PING 命令之后， 过去了多长时间还没接到回复。 节点最近一次返回 PONG 回复的时间。

节点的配置纪元（configuration epoch）：详细信息请参考 Redis 集群规范 。

本节点的网络连接情况：例如 connected 。

节点目前包含的槽：例如 127.0.0.1:7001 目前包含号码为 5960 至 10921 的哈希槽。

添加新节点到集群

根据新添加节点的种类， 我们需要用两种方法来将新节点添加到集群里面：

如果要添加的新节点是一个主节点， 那么我们需要创建一个空节点（empty node）， 然 后将某些哈希桶移动到这个空节点里面。

另一方面， 如果要添加的新节点是一个从节点， 那么我们需要将这个新节点设置为集群 中某个节点的复制品（replica）。

本节将对以上两种情况进行介绍， 首先介绍主节点的添加方法， 然后再介绍从节点的添加方 法。

无论添加的是那种节点， 第一步要做的总是添加一个空节点。

我们可以继续使用之前启动 127.0.0.1:7000 、 127.0.0.1:7001 等节点的方法， 创建一个端

口号为 7006 的新节点， 使用的配置文件也和之前一样， 只是记得要将配置中的端口号改为

7000 。